The problems with StringBuilders...

[David Daney]

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.