This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: gcj internals documentation
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "Paul Biggar" <paul dot biggar at gmail dot com>, <tromey at redhat dot com>
- Cc: "Andrew Haley" <aph at redhat dot com>, <java at gcc dot gnu dot org>
- Date: Wed, 11 Oct 2006 13:54:02 -0500
- Subject: RE: gcj internals documentation
> From: Paul Biggar
> On 04 Oct 2006 09:14:38 -0600, Tom Tromey <tromey@redhat.com> wrote:
> >
> > 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
> > Paul> when 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.
>
In 1.5, synchronization operations on objects that do not escape the
thread can be removed. Locks have memory visibility implications only
when a lock is released by one thread and then acquired by another. I
believe that was not technically true in 1.4 and earlier, so this
transformation technically isn't valid there. However, the pre-1.5
memory model had enough problems that I don't think anyone really cares
about it.
Hans