HotSpot and IBM's J9 behave quite differently when processing monitorenters and monitorexits

[陈雨亭]

The differences are there with updated JRE versions: 
HotSpot
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

J9, 
java version "1.8.0"
Java(TM) SE Runtime Environment (build pxa6480sr4fp5-20170421_01(SR4 FP5))
IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References
20170419_344392 (JIT enabled, AOT enabled)
J9VM - R28_20170419_1004_B344392
JIT  - tr.r14.java_20170419_344392
GC   - R28_20170419_1004_B344392_CMPRSS
J9CL - 20170419_344392)
JCL - 20170420_01 based on Oracle jdk8u131-b11

主题: HotSpot and IBM's J9 behave quite differently when processing
monitorenters and monitorexits 

I have tested several programs (in Jimple) and found that HotSpot and J9
match monitorenters and monitorexits quite differently. Verifiers should
play more important roles here.

(1) Test the next program (r2 is not initizlied) on HotSpot and J9. 
J9 throw out a verifier error, while HotSpot does not. It seems that
HotSpot's verifier forgets to check whether a monitored object is
initialized.

public class Search extends java.lang.Object { public void <init>()
    {
        Search r0;
        r0 := @this: Search;
        specialinvoke r0.<java.lang.Object: void <init>()>();      
        return;
    }
public void main(java.lang.String[]) throws java.lang.Exception
    {
        Search r0;
        Search r2;
        java.lang.String[] r1;
        r0 := @this: Search;
        r1 := @parameter0: java.lang.String[];
        r2 = new Search;
        
        entermonitor r2;
        entermonitor r0;
        exitmonitor r2;
        exitmonitor r0;
        return;        
    }
}

(2) Test the next program on HotSpot and J9, and both do not report any
errors. However, I guess the order in the program (entermonitor r2; =>
entermonitor r0; =>  exitmonitor r2; => exitmonitor r0;) violates the
situation of "structured locking" (Structured locking is the situation when,
during a method invocation, every exit on a given monitor matches a
preceding entry on that monitor, see the specification
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.11.10)
? 
Actually, the words (every exit on a given monitor matches a preceding entry
on that monitor) are not quite clear as for me. Otherwise the first rule
(The number of monitor entries performed by T on M during a method
invocation must equal the number of monitor exits performed by T on M during
the method invocation whether the method  invocation completes normally or
abruptly.) is sufficient.
        
public class Search extends java.lang.Object {

public void <init>()
    {
        Search r0;
        r0 := @this: Search;
        specialinvoke r0.<java.lang.Object: void <init>()>();      
        return;
    }

public void main(java.lang.String[]) throws java.lang.Exception
    {
        Search r0;
        Search r2;
        java.lang.String[] r1;
        r0 := @this: Search;
        r1 := @parameter0: java.lang.String[];
        r2 = new Search;
        specialinvoke r2.<Search: void <init>()>();
        entermonitor r2;
        entermonitor r0;
        exitmonitor r2;
        exitmonitor r0;
        return;        
    }
}

(3) The next program enters monitor in <init> and exits it in main(). 
HotSpot throws a runtime exception, while J9 does not. Should this  program
be rejected by the verifiers?

public class Search extends java.lang.Object {

public void <init>()
    {
        Search r0;
        r0 := @this: Search;
        specialinvoke r0.<java.lang.Object: void <init>()>();
        entermonitor r0;       
        return;
    }

public void main(java.lang.String[]) throws java.lang.Exception
    {
        Search r0;
        Search r2;
        java.lang.String[] r1;
        r0 := @this: Search;
        r1 := @parameter0: java.lang.String[];
        r2 = new Search;
        specialinvoke r2.<Search: void <init>()>();       
        exitmonitor r2;
        exitmonitor r0;        
        return;        
    }
}