synchronization in gcj

Thu Jan 14 21:27: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.
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.
Tom