Is this a bug? (unexpected IllegalMonitorStateException)
Stefan Ring
stefan at complang.tuwien.ac.at
Thu Apr 24 10:16:33 PDT 2008
Hi,
I'm working on CACAO at the moment and wanted to test how it behaves
when an exception is thrown from a synchronized block for which no
exception handlers have been created. So I built the following test
program. Of course, I wanted to run it on hotspot first to find out how
it should behave, assuming that hotspot is always right.
==%< x.java
class x {
public final static Object l = new Object();
private void test() {
Y y = new Y();
try {
y.dolocked(l, null);
} catch (Exception e) {
System.out.println("expecting NullPointerException");
e.printStackTrace();
}
}
public static void main(String[] args) {
new x().test();
}
}
==%<==
and
==%< Y.java
class Y {
public void dolocked(Object o1, Object o2) {
synchronized (o1) {
synchronized (o2) {
}
}
}
}
==%<==
When compiling class Y, the Java compiler will create implicit exception
handlers, as javap -c will reveal. I then recreated the Y class file
with jasmin, leaving out those exception handlers:
==%< Y.j
.class public Y
.super java/lang/Object
.method public <init>()V
aload_0
invokenonvirtual java/lang/Object/<init>()V
return
.end method
.method public dolocked(Ljava/lang/Object;Ljava/lang/Object;)V
.limit stack 3
.limit locals 5
aload_1
dup
astore_3
monitorenter
aload_2
dup
astore 4
monitorenter
aload 4
monitorexit
aload 3
monitorexit
return
.end method
==%<==
The inner synchronized is supposed to fail because of the null
reference. Much to my surprise, I get this, though:
expecting NullPointerException
java.lang.IllegalMonitorStateException
at Y.dolocked(Y.j)
at x.test(x.java:6)
at x.main(x.java:13)
>From my understanding of things, normal program flow can never result in
an IllegalMonitorStateException for this program. Delving a bit deeper
into this, I found out that Y.dolocked will always be run by the
interpreter in hotspot because the compiler says:
<method_not_compilable/>
<failure reason='cannot parse method'/>
I know that the compiler will not compile methods without properly
block-structured monitorenter and monitorexit instructions. This method
is block-structured, though, but only in the absence of
exceptions. Apparently, that's not good enough for the compiler.
The monitor on x.l is released, though.
More information about the hotspot-runtime-dev
mailing list