The problems with StringBuilders...
Wed Oct 5 16:26:00 GMT 2005
Andrew Haley wrote:
> Bryce McKinlay writes:
> > Adam Megacz wrote:
> > >Andrew Haley <email@example.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...
... 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. Things that come to mind are:
More information about the Java