答复: What is a structured locking in the JVM specification?

[陈雨亭]

I read the specification again and realized that the rules for guaranteeing
the structured locking just correspond to some implementations (e.g.,
athrow, monitorexit, etc. in OpenJDK). It is much safer than expected.
Nothing is wrong here. :)

Sorry for the noise.

Yuting

-----邮件原件-----
发件人: 陈雨亭 [mailto:chenyt at cs.sjtu.edu.cn] 
发送时间: 2017年5月17日 20:07
收件人: 'jls-jvms-spec-comments at openjdk.java.net'
<jls-jvms-spec-comments at openjdk.java.net>
主题: 答复: What is a structured locking in the JVM specification?

David has told me that non-nested locking structures are allowed (really?). 

Now I just have the second question. The first rule seems to provide us with
an extra checking. The second rule is sufficient for guaranteeing structured
locking, is it right?

Regards,
Yuting

-----邮件原件-----
发件人: 陈雨亭 [mailto:chenyt at cs.sjtu.edu.cn] 
发送时间: 2017年5月17日 17:34
收件人: 'jls-jvms-spec-comments at openjdk.java.net'
<jls-jvms-spec-comments at openjdk.java.net>
主题: What is a structured locking in the JVM specification?

Hi, I read the JVM specification and hope to get some clarifications here.

The original explanation about structured locking is given as: "Structured
locking is the situation when, during a method invocation, every exit on a
given monitor matches a preceding entry on that monitor. Since there is no
assurance that all code submitted to the Java Virtual Machine will perform
structured locking, implementations of the Java Virtual Machine are
permitted but not required to enforce both of the following two rules
guaranteeing structured locking. Let T be a thread and M be a monitor. Then:
(1) 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. (2) At no point during a method invocation may the number of
monitor exits performed by T on M since the method invocation exceed the
number of monitor entries performed by T on M since the method invocation."
(https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-2.html#jvms-2.11.10
)

According to the definition, it seems that a structured locking appears
like:  T {...Monitorenter r0; …monitorenter r0; …； monitorexit r0; …
monitorexit r0;...}

Two questions: 
(1) I’m a little curious whether a structured locking can be composed by
the following instructions, as two objects are not nestedly locked:
Monitorenter r0; monitorenter r2; …； monitorexit r0; monitorexit r2;
Should this sequence be accepted or rejected? At runtime or during the
verification time? Will this locking structure cause deadlocks?

(2) Rule 1 is not really used to guaranteeing structured locking, at least
from its definition. 
Besides, I retested some programs on HotSpot and IBM's J9. It seems that
HotSpot takes Rule 1 (rule1 is stricter than rule2, and HotSpot throws out
an IllegalMonitorStateException at runtime), and J9 only takes Rule 2
(accepting the program). As the IllegalMonitorStateException can be caught
(with further exception handlings), some of my programs run quite
differently on the two platforms.

f(){
   monitorenter r0;
}
g(){
   f();
   monitorexit r0;
}

Yuting