gcj internals documentation

Wed Oct 11 16:01:00 GMT 2006

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