This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: The problems with StringBuilders...
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