Re: gcj internals documentation

[Tom Tromey <tromey at redhat dot com>]

Paul> It looks like synchronization removal can simply be done by removing
Paul> these function calls in cases where the object doesnt escape. Does
Paul> this sound right?

Yes.

Paul> How does this all relate the the StringBuilder/StringBuffer problem?
Paul> Assuming I have working inter-procedural escape analysis, how do I go
Paul> about fixing the problems described in
Paul> http://gcc.gnu.org/ml/java/2005-10/msg00006.html?

It all depends on which cases you want to solve.

The simplest case is dealing with StringBuilder.  Suppose you can
determine that a given StringBuilder does not escape from the method
where it is created, and furthermore that the object is no longer used
after toString is called.

In this situation we could replace the call to toString with a call to
some as-yet-unwritten method (or plain old _Jv_something function --
this avoids troublesome access control checks in the BC case).  This
new method would transfer ownership of the StringBuilder's char[] to
the new String, avoiding an allocation.


A more complicated optimization along the same lines would be to
automatically replace StringBuffer with StringBuilder when the same
conditions hold.  This sort of thing is common in 1.4 code (in 1.5 I
think String "+" operations are generally translated to StringBuilder
instead) and also on occasion in hand-written code.

Tom