Re: gcj internals documentation

["Paul Biggar" <paul dot biggar at gmail dot com>]

Tom,

Thanks for the detailed reply.

On 04 Oct 2006 09:14:38 -0600, Tom Tromey <tromey@redhat.com> wrote:
> Paul> How does synchronization work in gcj?
>
> Paul> I've heard there's a hashtable containing the synchronization
> Paul> primitives, that they're added lazily, and that monitorenter and
> Paul> monitorexit are somehow involved. So how does it all work? Where and
> Paul> under what circumstances is the synchronization code inserted by the
> Paul> compiler?
>
> There are 2 cases.  On platforms where the required porting has been
> done, the above is true.  On other platforms, all objects have an
> extra "sync_info" field that points to a lazily-instantiated lock
> structure.
>
> The compiler turns  'synchronized' into calls  to _Jv_MonitorEnter and
> _Jv_MonitorExit.  It also does the obvious transformation here for the
> monitor-related bytecode instructions.

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


> Paul> Is the synchronization model accurate to Java1.4? Will it change when
> Paul> the ecj compiler is put in, and we model Java 1.5?
>
> The spec for synchronization hasn't really changed over the years.
> (The memory model has a bit, I suppose.)  We're ok up to 1.4.


I'll have a think about this. I have Pugh's paper about the 1.4 memory
model, so I'll have to see what he says.

> For 1.5 there are some new things (the various atomic operations) that
> Andrew has worked on.  This is all on the gcj-eclipse branch.  We'll
> be merging this to trunk after 4.2 branches.
>
> Paul> Which Java language documents does gcj try to conform to, and
> Paul> how good a job does it do?
>
> It tries to conform to the latest released version.  It usually does
> an ok job; specific things may have problems.  For instance I think we
> still don't implement strictfp completely.  Also the library is
> typically missing some bits.
>
> 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?
>
> So, there are 2 issues in this area.
>
> One is that StringBuffer is synchronized, and that sucks for uses
> generated by (1.4) compilers for "string +".
>
> The other is that StringBuilder, which is not synchronized, requires a
> second allocation at toString time -- even if the StringBuilder does
> not escape the thread and is dead after the call (since we don't
> detect this).
>
> One way to solve this would be to rewrite these uses into uses of
> gnu.gcj.runtime.StringBuffer -- which is unsynchronized and which
> assumes that after toString the object is dead.

This is a little more complicated then I intended to look at right
now. Ill look at it in the future, hopefully.


Thanks
Paul


--
Paul Biggar
paul.biggar@gmail.com