Re: The problems with StringBuilders...

[David Daney <ddaney at avtrex dot com>]

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.