Reconsidering gcjx

David Daney ddaney@avtrex.com
Mon Jan 30 10:40:00 GMT 2006


Tom Tromey wrote:
>>>>>>"Per" == Per Bothner <per@bothner.com> 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


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /