Is this a bug? (unexpected IllegalMonitorStateException)

[steve goldman]

Tom Rodriguez wrote:
> 
> During dispatch of the NPE, the IMSE is generated and we override the 
> NPE with the IMSE.  If you run a debug JVM with -XX:+TraceExceptions you 
> should be able to see it.  There are some optional rules in section 8.13 
> of the JVMS that basically says the JVM is allowed to verify that a 
> method unlocks all of its locks when exiting a frame.  Rule one says 
> that it's checked whether you exit a frame normally or through 
> exceptions which says to me that any notification would override any 
> existing exception, which is what we do.  It might be nice if our IMSE 
> included the exception which caused it but oh well.
> 
>> The question is: is a conforming JVM implementation required to behave 
>> this way?
>> Or would a NullPointerException be fine? CACAO currently throws NPE. 
>> And it does
>> not unlock the monitor, which is probably not fine.
> 
> No you aren't required to behave this way since it's an optional check. 
>  I believe many other JVMs don't perform these checks.  A major reason 
> that we do it is that our fast locking implementation is based on stack 
> records and our implementation would fail in bad ways if the frame of a 
> stack record went away.  Biased locking also takes advantage of the lock 
> records in our vframe representation to reconstruct the locking state 
> when revoking biases.
> 
> I don't believe there's any language concderning whether the object 
> should be unlocked if this occurs.  Since the check is optional anyway I 
> don't think unlocking would be required.

I've been down this road with Dave Dice a few times. I think the only 
language is wimpy in that same 8.13 section where it says "Normally, a 
compiler for the Java programming language ensures that the lock ... is 
matched by an unlock operation ... whether completion is normal or 
abrupt. This of course says nothing about bytecodes anyway.

If hotspot could rely on all locks being cleaned up by exception handler 
(in this case compiler an invisible handler that rethrows the NPE) then 
some of the exception handling on hotspot would be be simpler. Since 
this would assure us that every frame would catch exceptions and cleanup 
locks then  on the initial exception when we search for the handler we 
could see what frame will catch the exception and if the active frame 
doesn't catch it simply unwind N frames after a single call_VM instead 
of the dance we currently do.

In theory we could do this anyway in the typical case where we see no 
locks between the youngest frame and the target frame but the exception 
paths are complicated enough without more special cases.

-- 
Steve