This is the mail archive of the java-discuss@sourceware.cygnus.com 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]

inlining and string concatenation


Today I spent some time looking at how g++ does tree-level inlining.
It turns out to be pretty simple, I think.  It wouldn't take too much
to do this for the .java part of gcj (the .class part would be harder
because it doesn not represent entire functions as trees yet).

It occurred to me that we could use this tree-based inlining, in
conjunction with a small change to the front end, to make string
concatenation much faster without having to introduce a new
unsynchronized StringBuffer-like class into the runtime.

The idea here is to mark a StringBuffer used for string concatenation
as method-local (later we could contemplate doing escape analysis and
marking other objects this way as well).  Then, when inlining a method
call whose `this' argument had the method-local flag set, we could
eliminate synchronized blocks.

This same idea would let us remove `ensureCapacity_unsynchronized'
from StringBuffer (i.e., we could also notice redundant synchronized
calls when inlining and eliminate the inner ones).

I think this actually wouldn't be very hard to implement, and it
doesn't seem as hacky as the special class approach -- this approach
combines different optimizations that are potentially useful in other
situations.

Tom

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