Is this a bug? (unexpected IllegalMonitorStateException)
Stefan Ring
stefan at complang.tuwien.ac.at
Thu Apr 24 11:44:06 PDT 2008
Tom Rodriguez <Thomas.Rodriguez at ...> writes:
> It's required that no locks are still held when the frame is exited. By
> removing the exception handlers javac generated you are making it
> possible for the frame to return without unlocking the first lock.
> That's why the interpreter throws an illegal monitor state exception
> when you execute it with null. The compiler won't compile it for the
> same reason. We require that's a static analysis will tell us that
> monitor properly pair before we will compile something. This means that
> you could write a complex piece of code which pairs properly dynamically
> but isn't statically provable and we wouldn't compile it but the
> interpreter would run it just fine.
Thanks a lot for your answer.
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...
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.
More information about the hotspot-runtime-dev
mailing list