This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: The problems with StringBuilders...


Andrew Haley wrote:
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...

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


Math.*
System.arraycopy();
java.nio.Buffer.*;
StringBuffer.*
StringBuilder.toString();
.
.
.

David Daney


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]