Re: Non-synchronized StringBuffer

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Tom Tromey wrote:

>This is called "escape analysis", at least in one paper I read.  gcj
>doesn't currently do it.
>
>It isn't as easy as it sounds.  For one thing, a reference is passed
>to any methods invoked on it, and these methods might save `this' (for
>that matter, a constructor might save `this' somewhere).
>

It would be nice to have a generic allocate-on-stack option that can be 
used by string concatenation now, and can also be used to optimize 
"local" allocations later. It ought to be relatively simple to do escape 
analysis if we just consider calls to functions outside the current 
translation unit to have "escaped", along with any calls to virtuals. I 
can imagine this would help loops which allocate small temporary arrays, 
for example.

Hopefully this sort of thing will become easier once there is more of a 
framework in place for tree-based optimizations.

>In general I think you need to do whole-program analysis to get good
>escape analysis.  I haven't done much reading in this area.  I'd be
>interested in finding out about situations where we can do escape
>analysis without reading the whole program (or by perhaps annotating
>class files in the library and elsewhere with analysis we do
>incrementally?).
>

For the most part, whole-program optimizations should only be done when 
generating a static binary, since they introduce binary compatibility 
issues - eg when escape analysis determines that a function in libgcj.so 
does not escape a reference, but later it is changed so that it does, 
for example.

If we are generating a static binary, maybe it makes sense for gcj to 
simply treat the whole program as a single translation unit. That is, 
recompile the java.* classes along with the application code. Lots of 
optimizations become easy if it does that.

regards

Bryce.