RE: Non-synchronized StringBuffer

["Boehm, Hans" <hans_boehm at hp dot com>]

> From: Adam Megacz [mailto:gcj@lists.megacz.com]
> Tom Tromey <tromey@redhat.com> writes:
> > 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).
> 
> Bleh, I forgot about that. At times like this I keep wishing that
> Gosling had been more of a Haskell fan... AFAIK escape analysis should
> be easy in pure functional languages...
> 
I think it would only make things a little easier in this case, in that
local analysis might give you slightly more interesting results.  In
general, you still have to know whether a called function returns its
argument as part of its result.  This requires interprocedural, and ideally
whole-program, analysis.

In general, there's another issue that needs to be considered:  stack
allocating an object may extend its lifetime beyond the point at which the
garbage collector might have reclaimed it.  This is especially true if you
stack allocate objects that are allocated within a loop (or tail recursion),
and only deallocate them on function exit.  See, for example: David Chase,
"Safety Considerations for Storage Allocation Optimizations", PLDI 1988.  (I
think this is also discussed in Appel's book.)  Java rules are sufficiently
weak that this isn't a formal correctness issue, and the conservative
garbage collector aleady takes advanatage of that.  But you do want to be
careful.  There are cases in which this can have much more of an impact than
conservative collection.

Hans