GCJ, StringBuilder & Escape Analysis

Sun has recently introduced the 'StringBuilder' class which is meant to be
an unsynchronized version of the StringBuffer class in JDK 1.5. Whenever there are strings which are going to be used by single thread, you use a StringBuilder rather than a StringBuffer. They claim that StringBuilder is almost always faster than StringBuffer.

Consider this problem : You have lots of code in a Java application ( possibly a ERP web application ) which has uses of StringBuffers one every 10 lines of code ( we know that, don't we with Application Frameworks appending URLs etc , javascript targets ) and what with Threads being a absolute taboo in web applications , would'nt there be a lot to gain if we used StringBuilders instead of StringBuffers ?

Now how exactly do we find StringBuffers that are used which are local to a thread/method and replace them with StringBuilders ? Just think of the millions of lines of code that we need to check to make sure only a single thread/method accesses a StringBuffer.

Here is where Escape Analysis could help. And this is what the GCJ guys are discussing here.
But the one point at which I am not clear is that why should inheritance pose a (big) problem ? Can't we first do a Class Heirarchy Analysis (CHA) / Rapid Type Analysis (RTA) to constrain the list of methods that could be possibly called ?