The problems with StringBuilders...

Wed Oct 5 18:38:00 GMT 2005

Bryce McKinlay wrote:
> David Daney wrote:
>>>> Right, and the JET paper suggests that they know a lot about how all
>>> the system classes behave. That might be the key to most of the
>>> performance improvement -- you're not alowed to replace system
>>> classes, and many of them are final, so...
>>>>>>>> ... Any call to any method in java.* could be inlined or converted 
>> into a call to an equivalent but more effecient implementation. 
>> Further more, code analysis can be done to see if it is safe to use 
>> vastly simpler implementations. 
>>>> You can only do this if you make some closed-world assumptions. 
> Certainly for things like Math.*, the methods are simple enough and 
> well-defined enough that they can be trivially inlined - and we already 
> do this. But for the general case, its not possible to inline java.* 
> methods without breaking binary compatibility rules, and thus 
> disallowing the code from running on a newer version of the runtime.
>
This is a problem with the GCJ approach. We have this nice binary 
compatibility feature, but you have to disallow a wide range of 
optimizations in order to use it. The JIT compilers (like Sun's 
HotSpot) can do these things because they know everything at run/compile 
time (as runtime and compile time are the same thing).
There are a class of applications where throwing binary compatability 
away to achieve better optimization makes a lot of sense (think embedded 
systems). The reality is that current GCJ development is biased more 
and more towards the binay-compatibility system in hopes of making it 
easier to maintain server and workstation applications. So these types 
of optimizations are difficult...
David Daney.