The problems with StringBuilders...

Wed Oct 5 11:09:00 GMT 2005

Bryce McKinlay writes:
 > Adam Megacz wrote:
 > 
 > >Andrew Haley <aph@redhat.com> writes:
 > >
 > >>Mmm yeah, that's much the same as the IBM paper. They don't say much
 > >>about inheritance. I suppose they have to assume that any (non-final)
 > >>method in a (non-private) class may be overridden, and thus every
 > >>object passed to such a method escapes.
 > >
 > >IIRC JET gets to make a closed-world analysis on the pile of bytecode
 > >you put into it to generate the .exe. There might be fallback code
 > >(unoptimized) it reverts back to if you later on load a class which
 > >violates one of the assumptions used in optimization (I have to assume
 > >that they're optimizing for the common case where no new classes are
 > >loaded beyond those compiled into the binary).
 > 
 > This was my assumption too - obviously, far more optimizations become 
 > available when you can assume a closed-world. Escape analysis, for 
 > example, isn't going to be very effective in an environment that allows 
 > complete "binary compatibility", because you can't anything about what 
 > any methods are doing outside the target class. Special cases could, of 
 > course, be made for library classes like StringBuilder.toString() where 
 > e know it isn't going to save a pointer to itself anywhere.
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...
 > However, JET's web site does make various claims about 100% java 
 > compatibility and full implementation of dynamic class loading. It would 
 > be interesting to know how they achieve this - falling back to an 
 > unoptimized copy of the code or a JIT sounds plausable.
Maybe, yes. But it might be that there's enough is the system classes
to make it worth doing.
Andrew.