From chenyt at cs.sjtu.edu.cn Thu May 18 00:34:01 2017 From: chenyt at cs.sjtu.edu.cn (=?gb2312?B?s8LT6s2k?=) Date: Wed, 17 May 2017 17:34:01 -0700 Subject: What is a structured locking in the JVM specification? References: <004c01d2cf51$b4237950$1c6a6bf0$@cs.sjtu.edu.cn> Message-ID: <000501d2cf6e$73def730$5b9ce590$@cs.sjtu.edu.cn> 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 From chenyt at cs.sjtu.edu.cn Thu May 18 03:07:25 2017 From: chenyt at cs.sjtu.edu.cn (=?gb2312?B?s8LT6s2k?=) Date: Wed, 17 May 2017 20:07:25 -0700 Subject: =?gb2312?B?tPC4tDogV2hhdCBpcyBhIHN0cnVjdHVyZWQgbG9ja2luZyBpbiB0aA==?= =?gb2312?B?ZSBKVk0gc3BlY2lmaWNhdGlvbj8=?= References: <004c01d2cf51$b4237950$1c6a6bf0$@cs.sjtu.edu.cn> Message-ID: <000001d2cf83$e29d9810$a7d8c830$@cs.sjtu.edu.cn> 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' ??: 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 From chenyt at cs.sjtu.edu.cn Thu May 18 18:12:34 2017 From: chenyt at cs.sjtu.edu.cn (=?gb2312?B?s8LT6s2k?=) Date: Thu, 18 May 2017 11:12:34 -0700 Subject: =?gb2312?B?tPC4tDogV2hhdCBpcyBhIHN0cnVjdHVyZWQgbG9ja2luZyBpbiB0aA==?= =?gb2312?B?ZSBKVk0gc3BlY2lmaWNhdGlvbj8=?= References: <004c01d2cf51$b4237950$1c6a6bf0$@cs.sjtu.edu.cn> Message-ID: <000001d2d002$546b8410$fd428c30$@cs.sjtu.edu.cn> 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' ??: ??: 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' ??: 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 From korneel at emweb.be Fri May 19 11:10:24 2017 From: korneel at emweb.be (Korneel Dumon) Date: Fri, 19 May 2017 13:10:24 +0200 Subject: JVM spec typo Message-ID: Hi, in the JVM 8 spec, under section 2.3.2 floating point types, I think the following line should read "less than 2^N". *m is a positive integer less than 2N* I downloaded the spec off https://docs.oracle.com/javase/specs/ Regards, Korneel From alex.buckley at oracle.com Mon May 22 17:52:10 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 22 May 2017 10:52:10 -0700 Subject: JVM spec typo In-Reply-To: References: Message-ID: <5923254A.5040500@oracle.com> Many thanks for pointing out this error introduced in the production of JVMS7. It will be corrected in JVMS9. On 5/19/2017 4:10 AM, Korneel Dumon wrote: > Hi, > > in the JVM 8 spec, under section 2.3.2 floating point types, I think the > following line should read "less than 2^N". > > *m is a positive integer less than 2N* > > I downloaded the spec off https://docs.oracle.com/javase/specs/ > > Regards, > Korneel >