synchronization in gcj

Thu Apr 1 00:00:00 GMT 1999

>> >> On the compiler side this basically amounts to getting rid of the
> >> extra field in the object. I believe the compiler doesn't ever
> >> directly reference this field.
>> Godmar> It would certainly be simple to get rid of the field and look
> Godmar> up the lock object every time the lock is entered or left.
>> Godmar> As you probably know, Java's symmetrical use of
> Godmar> synchronization constructs provides the possibility for at
> Godmar> least saving the lookup when a monitor is left. This would
> Godmar> require storing the address of the lock object while it is
> Godmar> held somewhere, presumably on the run-time stack.
>> Godmar> How hard would that be to implement and have you considered
> Godmar> it?
>> I can't claim to be familiar enough with the compiler to say how hard
> this would be to implement.
>> One implementation would be to change _Jv_MonitorEnter to return the
> lock object, which would later be passed to _Jv_MonitorExit. This
> might even be the right thing to do, as it would allow the alternative
> implementation to be faster.

This is what Kaffe does, although it's currently only used in the 
runtime itself. Kaffe can either cache a ref to the lock in the object 
at a cost of one pointer or it will look it up every time.
It's a compile-time option, which I find somewhat inflexible.
In the tradition of gcc extensions, I would imagine annotations like
public /* CACHELOCK */ class A { }
or
public /* CACHECLASSLOCK */ class java.awt.Toolkit { }
that are recognized by gcj's Java source front-end, communicated to
the Runtime/VM either as a class file attribute or a special symbol in 
the .o file.
>> Does the JVM really require monitorenter and monitorexit to be paired
> in a method? I didn't see this restriction in the JVM spec, but I
> didn't look very hard either. If you have a pointer, I'd appreciate
> it.
>> This is an important consideration because the .class reader should
> work with any .class file, not just one that comes from Java source
> code.
>> This isn't a show-stopping problem, however. It just means that a
> third function would have to be introduced to handle the non-paired
> case.
>
Actually, I don't believe it's a constraint that the verifier checks.
It will naturally be true for all methods carrying the ACC_SYNCHRONIZED
attribute, which are likely to account for a large share of uses of synch
in Java. The verifier/compiler should be able to infer if it's true 
for arbitrary MONITOR_ENTER/EXIT pairs.
	- Godmar