Tom Tromey wrote:
"Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> Tom Tromey wrote:
While investigating I realized that we would also lose a small
optimization related to String "+" operations. When translating from
.java we currently use a non-synchronizing variant of StringBuffer to
do this.
Per> In Java-5-mode I would expect ecj to use the unsynchronized
Per> java.lang.StringBuilder. If not, I'd consider it a bug.
Yeah. StringBuilder isn't as nice as our private StringBuffer,
though, because it requires copying the character data when toString
is invoked. IMNSHO this is a design bug, but we're stuck with it.
Per> A desirable optimization would be to convert local (non-escaping)
Per> uses of StringBuffer/StringBuilder to be stack allocated. You
Per> could even stack-allocate the actual buffer up to a limited size,
Per> only heap-allocating when it gets over that size.
Yeah, that would be good. We could fix the toString semantics thing
using the same machinery. I know David Daney was looking in this area
a bit, I don't know what became of it though.
I started looking at it, but decided I was trying to hack it in at the
wrong level (tree-ssa). If we were to use ecj I would do the following:
1a) As Adam Megacz suggested, at the byte code level (between ecj and
jc1) do some code analysis and annotating. I think using something like
BCEL or similar we could analyze the class files and add gcj private
method attributes describing how parameters escaped and if they return
non-null.
1b) Do transformations like converting java.lang.String[Buffer|Builder]
-> gcj.gnu.StringBuffer (or what ever it is called). I was running to
many problems trying to rename classes after the TREEs had been
generated, so I think the proper place to do the transformation is
before the TREEs are generated (like at the classfile level).
2) In jc1 while generating trees from the bytecode we can use attributes
generated in 1a to decide to allocate on the stack instead of the heap.
David Daney
