This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
inlining and string concatenation
- To: Java Discuss List <java-discuss at sourceware dot cygnus dot com>
- Subject: inlining and string concatenation
- From: Tom Tromey <tromey at cygnus dot com>
- Date: 28 Apr 2000 19:47:59 -0600
- Reply-To: tromey at cygnus dot com
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