Re: gcj internals documentation

[Tom Tromey <tromey at redhat dot com>]

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.

All the details of synchronization are handled in these methods.  All
this code is in libjava/java/lang/natObject.cc.

At the very lowest layer, the synchronization code defers to the
platform.  Platforms are organized by "flavor", of which we currently
only have 2: posix and windows.  Each platform flavor has a header
that defines low-level thread primitives (eg include/posix-threads.h)
and an implementation file that has the rest (posix-threads.cc).

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.

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.

Tom