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

[陈雨亭]

Am I wrong? 

The byte code for main() in case 1 is as follows. The strange thing is that
NullPointerException is also not thrown at runtime.

public void main(java.lang.String[]) throws java.lang.Exception;
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=2, args_size=2
         0: new           #2                  // class Search
         3: dup
         4: aload_0
         5: monitorenter
         6: monitorenter
         7: monitorexit
         8: aload_0
         9: monitorexit
        10: return
    Exceptions:
      throws java.lang.Exception

主题: 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;        
    }
}