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

[David Holmes]

Hi,
On 18/05/2017 7:23 AM, 陈雨亭 wrote:
> Am I wrong?

I will look at each situation in detail when I get a chance but 
structured locking enforcement is optional. Also balancing the number of 
locks and unlocks in a frame does not mean they can't be locked and 
unlocked in a non-nested fashion - just that by the end the number of 
unlocks matches the number of locks.

BTW the way you respond to these emails, as if having a conversation 
with yourself, makes it difficult to respond as we can't readily see 
what is the new email and what is the original.

Cheers,
David

> 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;
>     }
> }
>
>