Re: Non-synchronized StringBuffer

[Per Bothner <per at bothner dot com>]

Tom Tromey wrote:

>>>>>>"Adam" == Adam Megacz <gcj@lists.megacz.com> writes:
>>>>>>
>
>Adam> I'm curious -- will gcj stack-allocate an object whose lifetime
>Adam> is obviously no longer than that of the function allocating it?
>Adam> (ie no references to the object are passed to other functions,
>Adam> nor are any returned)?
>
>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).
>
>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?).
>
Yes.  I don't think the extreme simplistic "local" ecsape analysis that Adam
mentions does much good, unless you hardwire in a special case that the
StringBuffer arguments do not "escape" (i.e. do not save the this pointer
in a global).

It might be a nice undergraduate or masters compiler project to add a
section to the .class files where we can asve the information that the
arguments and this pointer of a method do not escape (are not saved
anywhere beyond the lifetime of the method call).

The papers I've glanced at suggest escape analysis (even global analysis )
provides a worthwhile but not huge speedup.

    --Per