The problems with StringBuilders...

Wed Oct 5 00:15:00 GMT 2005

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