Is this a bug? (unexpected IllegalMonitorStateException)

[Tom Rodriguez]

> I already knew the part about the static analysis from the biased locking paper.
> But as long as I'm only concerned with the observed behaviour, I need not care
> if it's compiled or not.
> 
> So the NullPointerException magically disappears -- it must be there at some
> point during execution, briefly at least, because it's the reason why an exit
> from the frame would happen in the first place. And out of nowhere pops the
> IllegalMonitorStateException...

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.

tom

>