synchronization in gcj

Fri Jan 15 05:00:00 GMT 1999

Out of interest, what approach has your runtime taken to freeing up all
monitors acquired during method execution, when an exception goes off ? In
particular, I'm thinking of monitorenter/monitorexit (rather than implicit
acquisition and release for synchronised methods) ...
If the exception handling is badly structured (in terms of mapping of
bytecode ranges to handlers) then it is possible to miss execution of
monitorexit before returning from the method. This bug is present in both
bytecode produced by Sun's javac, and also IBM's jikes.
Obviously, one could, in the interest of robustness, maintain runtime info
about all monitors acquired within a method, and use this as a last resort
to solve the above, with equally obvious performance implications.
cheers, Jerry Kramskoy
-----Original Message-----
From: Tom Tromey <tromey@cygnus.com>
To: Godmar Back <gback@cs.utah.edu>
Cc: java-discuss@cygnus.com <java-discuss@cygnus.com>
Date: Friday, January 15, 1999 7:52 AM
Subject: Re: synchronization in gcj
>>> 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
>