The problems with StringBuilders...

[Andrew Haley]

David Daney writes:
 > Bryce McKinlay wrote:
 > > 
 > > 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).

No, that really isn't true.

In a JIT compiler, when you devirtualize and inline you have to assume
that you know everything about the program, in particular that a
method you just inlined isn't about to be overridden by a subclass.
But you don't, because at any time a ClassLoader can come along and
create a new subclass of one of the classes you just inlined, and your
assumptions are no longer true.  So what do you do?  The ClassLoader
has to signal the runtime that the world has changed, and you have to
fall back to the non-inlined version of the code.  This is *exactly*
the same with ahead of time compilation.  We can do optimistic
optimization in gcj and fall back if we have to, just like a JIT.

So why don't we do this?  Is it because the gcj environment makes this
particularly hard?  No.  Is it because we don't know how to do it?
No.  So why haven't we done it, then?  That's easy: a shortage of time
and people.

Now it's true that a JIT can use profile-directed optimization.  I'm
not going to deny that this approach can be very powerful, but it's
not everything.

 > 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.

No, that's not it at all.  Current GCJ development is biased towards
making gcj work *correctly*.  We haven't done much optimization work
recently because we've been concentrating on that.

Andrew.