synchronization in gcj

Fri Jan 15 11:04:00 GMT 1999

Godmar Back writes:
> > 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.
>> I didn't know about this. Can you give an example of or pointer to code
> that javac or jikes mishandles?

I can't answer for somebody else, but one example of doing this
would be compiling this method:
 public void method(Object f) {
 synchronized (f) {
 ...
 }
 }
The bytecode must have an exception handler (for type "any")
and the handler must do a MONITOREXIT. The compiler could
forget to add this handler.
Contrary to what I said before, there's nothing in "The Java
Virtual Machine Specification" that says the bytecode verifier
must verify there are no "leaks" in monitors.
So the observation that MONITOR_ENTER's are always balanced
with MONITOR_EXIT's (and therefore the locks can be cached on
the stack) is an observation about the Java language, not Java
bytecode.
> what's to prevent a programmer from creating bytecode like :
>> lock() {
> 	 MONITOR_ENTER
> }
> unlock() {
> 	 MONITOR_EXIT
> }

Nothing -- and it will pass the verifier.
Of course, gjc and/or kaffe could choose to implement a stricter verifier
to avoid this situation.
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com