From david.holmes at oracle.com Mon Aug 1 00:17:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2016 10:17:40 +1000 Subject: RFR - JDK-8162524 : src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions In-Reply-To: <0da610b4-5be3-45e5-81fa-344da47d2cca@default> References: <0da610b4-5be3-45e5-81fa-344da47d2cca@default> Message-ID: <04dc2fcc-4756-00fd-7b7d-a8bed2a646fb@oracle.com> Hi Amit, On 29/07/2016 7:05 PM, Amit Sapre wrote: > Hello, > > Please review this small fix. > > Bug Id : https://bugs.openjdk.java.net/browse/JDK-8162524 > > Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162524/webrev.00/ Looks good to me too. David > > > Thanks, > > Amit > From david.holmes at oracle.com Mon Aug 1 00:40:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2016 10:40:12 +1000 Subject: RFR : JDK-8162702 - com.sun.management.internal.GcInfoBuilder.getPoolNames should not return reference of it's private member In-Reply-To: <8fd296d9-57fc-422d-81db-affbcdc8af0a@default> References: <8fd296d9-57fc-422d-81db-affbcdc8af0a@default> Message-ID: <8ea264e9-e3ce-075a-e295-2e5e38fce64b@oracle.com> Hi Amit, On 29/07/2016 6:20 PM, Amit Sapre wrote: > Hello, > > Please review this small fix. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8162702 > > Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162702/webrev.00/ This is good defensive programming practice for exported API's, but in this case isn't this a private API only accessible to trusted code? Thanks, David > > > Amit > From david.holmes at oracle.com Mon Aug 1 00:54:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2016 10:54:35 +1000 Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <1ca9a495-06a4-ecee-9b5e-c609f491d14f@oracle.com> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> <9acdebc0-2056-cacd-bf8d-f502ffa35761@oracle.com> <4e26134e-bba9-a153-8f71-7871ce21c746@oracle.com> <1c3ecf29-aaf0-43f4-a83b-baacc803f643@oracle.com> <1ca9a495-06a4-ecee-9b5e-c609f491d14f@oracle.com> Message-ID: <34c91599-ac76-e76b-4e49-8910890db9be@oracle.com> On 30/07/2016 2:26 AM, Daniel D. Daugherty wrote: > I didn't miss this part: > >> Besides, Page data may be very big - cloning that ever >> constructor and getter may be too costly. > > of what you originally wrote. :-) > > In my opinion, even defense-in-depth security trumps space savings. But in this case you have to explicitly enable module accessibility for this to be an issue. Doesn't seem reasonable to guard against that when it potentially involves a big penalty for well behaved users. It isn't clear to me whether futzing with these byte[]'s is really an issue. David ----- > Dan > > > On 7/29/16 10:16 AM, Sundararajan Athijegannathan wrote: >> >> Agreed that it could be considered as a defense-in-depth fix. But, in >> this case Page data could be huge. I think it was not cloned in first >> place to avoid copying many big byte[] instances around. >> >> -Sundar >> >> On 7/29/2016 9:36 PM, Daniel D. Daugherty wrote: >>> Two points: >>> >>> 1) if Findbugs reports the same issue on JDK9 code, then we want to >>> address such that we reduce any Findbugs noise >>> >>> 2) Fixing it could be considered to be a defense-in-depth change. >>> >>> Dan >>> >>> >>> On 7/29/16 7:19 AM, Sundararajan Athijegannathan wrote: >>>> Well, we can't code for that kind of overrides - Findbugs or any >>>> such tool is about normal mode of execution. With that argument, >>>> people can override classes using -Xpatch option as well! >>>> >>>> -Sundar >>>> >>>> On 7/29/2016 6:05 PM, Jini Susan George wrote: >>>>> >>>>> Thank you, JB and Sundar. Sundar, would that hold true even if >>>>> ?XaddExports is used ? >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Jini. >>>>> >>>>> >>>>> >>>>> *From:*Sundararajan Athijegannathan >>>>> *Sent:* Friday, July 29, 2016 5:11 PM >>>>> *To:* serviceability-dev at openjdk.java.net >>>>> *Subject:* Re: RFR: (XS): JDK-8068004: >>>>> [Findbugs]sun.jvm.hotspot.debugger may expose internal representation >>>>> >>>>> >>>>> >>>>> If cloning is done to avoid exposing byte[] outside SA, this fix is >>>>> not needed in jdk9. In jdk9, none of the SA packages are exposed >>>>> and code outside SA cannot access this. Besides, Page data may be >>>>> very big - cloning that ever constructor and getter may be too costly. >>>>> >>>>> -Sundar >>>>> >>>>> >>>>> >>>>> On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: >>>>> >>>>> Hi Jini, >>>>> >>>>> >>>>> >>>>> 'null' seems to be a valid value for 'data' field in both of >>>>> the places you are using 'data.clone()' - you should guard for >>>>> null and call 'clone()' only if the passed in value is non-null. >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> -JB- >>>>> >>>>> >>>>> >>>>> On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George >>>>> > wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please review the fix for the following SA defect (to avoid >>>>> exposing internal representations by storing or returning >>>>> externally mutable objects directly). >>>>> >>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> - Jini Susan George >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > From jini.george at oracle.com Mon Aug 1 04:13:10 2016 From: jini.george at oracle.com (Jini Susan George) Date: Sun, 31 Jul 2016 21:13:10 -0700 (PDT) Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <34c91599-ac76-e76b-4e49-8910890db9be@oracle.com> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> <9acdebc0-2056-cacd-bf8d-f502ffa35761@oracle.com> <4e26134e-bba9-a153-8f71-7871ce21c746@oracle.com> <1c3ecf29-aaf0-43f4-a83b-baacc803f643@oracle.com> <1ca9a495-06a4-ecee-9b5e-c609f491d14f@oracle.com> <34c91599-ac76-e76b-4e49-8910890db9be@oracle.com> Message-ID: <480a7834-70d6-4fff-81e1-79228af7f54f@default> Thank you, Sundar, Dan, David. Shouldn?t performance be of a slightly lesser concern here given that this is a debugging scenario? Thanks, Jini. > -----Original Message----- > From: David Holmes > Sent: Monday, August 01, 2016 6:25 AM > To: Daniel Daugherty; Sundararajan Athijegannathan; Jini Susan George; > serviceability-dev at openjdk.java.net > Subject: Re: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger > may expose internal representation > > On 30/07/2016 2:26 AM, Daniel D. Daugherty wrote: > > I didn't miss this part: > > > >> Besides, Page data may be very big - cloning that ever > >> constructor and getter may be too costly. > > > > of what you originally wrote. :-) > > > > In my opinion, even defense-in-depth security trumps space savings. > > But in this case you have to explicitly enable module accessibility for > this to be an issue. Doesn't seem reasonable to guard against that when > it potentially involves a big penalty for well behaved users. It isn't > clear to me whether futzing with these byte[]'s is really an issue. > > David > ----- > > > Dan > > > > > > On 7/29/16 10:16 AM, Sundararajan Athijegannathan wrote: > >> > >> Agreed that it could be considered as a defense-in-depth fix. But, in > >> this case Page data could be huge. I think it was not cloned in first > >> place to avoid copying many big byte[] instances around. > >> > >> -Sundar > >> > >> On 7/29/2016 9:36 PM, Daniel D. Daugherty wrote: > >>> Two points: > >>> > >>> 1) if Findbugs reports the same issue on JDK9 code, then we want to > >>> address such that we reduce any Findbugs noise > >>> > >>> 2) Fixing it could be considered to be a defense-in-depth change. > >>> > >>> Dan > >>> > >>> > >>> On 7/29/16 7:19 AM, Sundararajan Athijegannathan wrote: > >>>> Well, we can't code for that kind of overrides - Findbugs or any > >>>> such tool is about normal mode of execution. With that argument, > >>>> people can override classes using -Xpatch option as well! > >>>> > >>>> -Sundar > >>>> > >>>> On 7/29/2016 6:05 PM, Jini Susan George wrote: > >>>>> > >>>>> Thank you, JB and Sundar. Sundar, would that hold true even if > >>>>> ?XaddExports is used ? > >>>>> > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> Jini. > >>>>> > >>>>> > >>>>> > >>>>> *From:*Sundararajan Athijegannathan > >>>>> *Sent:* Friday, July 29, 2016 5:11 PM > >>>>> *To:* serviceability-dev at openjdk.java.net > >>>>> *Subject:* Re: RFR: (XS): JDK-8068004: > >>>>> [Findbugs]sun.jvm.hotspot.debugger may expose internal > representation > >>>>> > >>>>> > >>>>> > >>>>> If cloning is done to avoid exposing byte[] outside SA, this fix is > >>>>> not needed in jdk9. In jdk9, none of the SA packages are exposed > >>>>> and code outside SA cannot access this. Besides, Page data may be > >>>>> very big - cloning that ever constructor and getter may be too costly. > >>>>> > >>>>> -Sundar > >>>>> > >>>>> > >>>>> > >>>>> On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: > >>>>> > >>>>> Hi Jini, > >>>>> > >>>>> > >>>>> > >>>>> 'null' seems to be a valid value for 'data' field in both of > >>>>> the places you are using 'data.clone()' - you should guard for > >>>>> null and call 'clone()' only if the passed in value is non-null. > >>>>> > >>>>> > >>>>> > >>>>> Cheers, > >>>>> > >>>>> > >>>>> > >>>>> -JB- > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George > >>>>> > wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> Please review the fix for the following SA defect (to avoid > >>>>> exposing internal representations by storing or returning > >>>>> externally mutable objects directly). > >>>>> > >>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 > >>>>> > >>>>> Webrev: > >>>>> > http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ > >>>>> > > >>>>> > >>>>> Thanks, > >>>>> > >>>>> - Jini Susan George > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >> > > From sundararajan.athijegannathan at oracle.com Mon Aug 1 04:25:15 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Mon, 1 Aug 2016 09:55:15 +0530 Subject: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger may expose internal representation In-Reply-To: <480a7834-70d6-4fff-81e1-79228af7f54f@default> References: <9aa4b6fd-8196-4016-8918-16d52b2730ee@default> <48e32e77-87bc-bbbd-3b7b-877762413a14@oracle.com> <94cb73fd-d8c0-4521-8a93-4f5a3e60b140@default> <9acdebc0-2056-cacd-bf8d-f502ffa35761@oracle.com> <4e26134e-bba9-a153-8f71-7871ce21c746@oracle.com> <1c3ecf29-aaf0-43f4-a83b-baacc803f643@oracle.com> <1ca9a495-06a4-ecee-9b5e-c609f491d14f@oracle.com> <34c91599-ac76-e76b-4e49-8910890db9be@oracle.com> <480a7834-70d6-4fff-81e1-79228af7f54f@default> Message-ID: <24a1800e-ff9e-ae49-c768-0f70e33385d6@oracle.com> Hmm.. not sure. Entire (OS) page data is read and many such pages are read + cached. "find pointer" like memory walking features would suffer with this data cloning. BTW, a very slow debugger against a large core dump is useless at times. As David mentioned, I'm not sure if this is even a bug! sun.* and other package prefixes are listed under "package.access" and so these are not accessible under a security manager even in jdk8 or below. With jdk9, over and above "package.access" security check, we have modular access checks which are done regardless of security manager. Code scanning tools need to be updated for jdk9 - which I'm sure will happen in future. For now, we should just treat these warnings as false positives. -Sundar On 8/1/2016 9:43 AM, Jini Susan George wrote: > Thank you, Sundar, Dan, David. Shouldn?t performance be of a slightly lesser concern here given that this is a debugging scenario? > > Thanks, > Jini. > >> -----Original Message----- >> From: David Holmes >> Sent: Monday, August 01, 2016 6:25 AM >> To: Daniel Daugherty; Sundararajan Athijegannathan; Jini Susan George; >> serviceability-dev at openjdk.java.net >> Subject: Re: RFR: (XS): JDK-8068004: [Findbugs]sun.jvm.hotspot.debugger >> may expose internal representation >> >> On 30/07/2016 2:26 AM, Daniel D. Daugherty wrote: >>> I didn't miss this part: >>> >>>> Besides, Page data may be very big - cloning that ever >>>> constructor and getter may be too costly. >>> of what you originally wrote. :-) >>> >>> In my opinion, even defense-in-depth security trumps space savings. >> But in this case you have to explicitly enable module accessibility for >> this to be an issue. Doesn't seem reasonable to guard against that when >> it potentially involves a big penalty for well behaved users. It isn't >> clear to me whether futzing with these byte[]'s is really an issue. >> >> David >> ----- >> >>> Dan >>> >>> >>> On 7/29/16 10:16 AM, Sundararajan Athijegannathan wrote: >>>> Agreed that it could be considered as a defense-in-depth fix. But, in >>>> this case Page data could be huge. I think it was not cloned in first >>>> place to avoid copying many big byte[] instances around. >>>> >>>> -Sundar >>>> >>>> On 7/29/2016 9:36 PM, Daniel D. Daugherty wrote: >>>>> Two points: >>>>> >>>>> 1) if Findbugs reports the same issue on JDK9 code, then we want to >>>>> address such that we reduce any Findbugs noise >>>>> >>>>> 2) Fixing it could be considered to be a defense-in-depth change. >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 7/29/16 7:19 AM, Sundararajan Athijegannathan wrote: >>>>>> Well, we can't code for that kind of overrides - Findbugs or any >>>>>> such tool is about normal mode of execution. With that argument, >>>>>> people can override classes using -Xpatch option as well! >>>>>> >>>>>> -Sundar >>>>>> >>>>>> On 7/29/2016 6:05 PM, Jini Susan George wrote: >>>>>>> Thank you, JB and Sundar. Sundar, would that hold true even if >>>>>>> ?XaddExports is used ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Jini. >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:*Sundararajan Athijegannathan >>>>>>> *Sent:* Friday, July 29, 2016 5:11 PM >>>>>>> *To:* serviceability-dev at openjdk.java.net >>>>>>> *Subject:* Re: RFR: (XS): JDK-8068004: >>>>>>> [Findbugs]sun.jvm.hotspot.debugger may expose internal >> representation >>>>>>> >>>>>>> >>>>>>> If cloning is done to avoid exposing byte[] outside SA, this fix is >>>>>>> not needed in jdk9. In jdk9, none of the SA packages are exposed >>>>>>> and code outside SA cannot access this. Besides, Page data may be >>>>>>> very big - cloning that ever constructor and getter may be too costly. >>>>>>> >>>>>>> -Sundar >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/29/2016 5:07 PM, Jaroslav Bachorik wrote: >>>>>>> >>>>>>> Hi Jini, >>>>>>> >>>>>>> >>>>>>> >>>>>>> 'null' seems to be a valid value for 'data' field in both of >>>>>>> the places you are using 'data.clone()' - you should guard for >>>>>>> null and call 'clone()' only if the passed in value is non-null. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> >>>>>>> >>>>>>> -JB- >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Jul 29, 2016 at 11:29 AM, Jini Susan George >>>>>>> > wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Please review the fix for the following SA defect (to avoid >>>>>>> exposing internal representations by storing or returning >>>>>>> externally mutable objects directly). >>>>>>> >>>>>>> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8068004 >>>>>>> >>>>>>> Webrev: >>>>>>> >> http://cr.openjdk.java.net/~sballal/sponsorship/8068004/webrev.00/ >> >>>>>>> Thanks, >>>>>>> >>>>>>> - Jini Susan George >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> From amit.sapre at oracle.com Mon Aug 1 06:06:37 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Sun, 31 Jul 2016 23:06:37 -0700 (PDT) Subject: RFR : JDK-8162702 - com.sun.management.internal.GcInfoBuilder.getPoolNames should not return reference of it's private member In-Reply-To: <8ea264e9-e3ce-075a-e295-2e5e38fce64b@oracle.com> References: <8fd296d9-57fc-422d-81db-affbcdc8af0a@default> <8ea264e9-e3ce-075a-e295-2e5e38fce64b@oracle.com> Message-ID: <2edfb94a-81de-43fa-8140-35e1d6d66d63@default> David, Indeed it is a good to have fix. This API is only used by jdk.management package. Findbugs tool reported this could be potential bug. So made changes accordingly. Amit. -----Original Message----- From: David Holmes Sent: Monday, August 01, 2016 6:10 AM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8162702 - com.sun.management.internal.GcInfoBuilder.getPoolNames should not return reference of it's private member Hi Amit, On 29/07/2016 6:20 PM, Amit Sapre wrote: > Hello, > > Please review this small fix. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8162702 > > Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162702/webrev.00/ This is good defensive programming practice for exported API's, but in this case isn't this a private API only accessible to trusted code? Thanks, David > > > Amit > From amit.sapre at oracle.com Mon Aug 1 06:10:44 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Sun, 31 Jul 2016 23:10:44 -0700 (PDT) Subject: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly Message-ID: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> Hello, Please review JNI exception handling related changes. Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Aug 1 06:59:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2016 16:59:46 +1000 Subject: RFR : JDK-8162702 - com.sun.management.internal.GcInfoBuilder.getPoolNames should not return reference of it's private member In-Reply-To: <2edfb94a-81de-43fa-8140-35e1d6d66d63@default> References: <8fd296d9-57fc-422d-81db-affbcdc8af0a@default> <8ea264e9-e3ce-075a-e295-2e5e38fce64b@oracle.com> <2edfb94a-81de-43fa-8140-35e1d6d66d63@default> Message-ID: On 1/08/2016 4:06 PM, Amit Sapre wrote: > David, > Indeed it is a good to have fix. This API is only used by jdk.management package. > Findbugs tool reported this could be potential bug. So made changes accordingly. Yes but Findbugs is not presently module aware so doesn't understand inaccessibility based on module boundaries. But this is a small matter so I'm okay with the fix. Thanks, David > Amit. > > -----Original Message----- > From: David Holmes > Sent: Monday, August 01, 2016 6:10 AM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8162702 - com.sun.management.internal.GcInfoBuilder.getPoolNames should not return reference of it's private member > > Hi Amit, > > On 29/07/2016 6:20 PM, Amit Sapre wrote: >> Hello, >> >> Please review this small fix. >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8162702 >> >> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162702/webrev.00/ > > This is good defensive programming practice for exported API's, but in this case isn't this a private API only accessible to trusted code? > > Thanks, > David > >> >> >> Amit >> From david.holmes at oracle.com Mon Aug 1 07:03:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2016 17:03:22 +1000 Subject: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly In-Reply-To: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> References: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> Message-ID: Hi Amit, On 1/08/2016 4:10 PM, Amit Sapre wrote: > Hello, > > > > Please review JNI exception handling related changes. > > Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 > > Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ Sorry but that's wrong way to fix this. We should never just blindly clear exceptions and continue as if they never happened. If an exception is pending after one of these JNI calls the method should return immediately and allow the exception to propagate to the java code. Thanks, David > > > Thanks, > > Amit > From harsha.wardhana.b at oracle.com Mon Aug 1 07:12:00 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 1 Aug 2016 12:42:00 +0530 Subject: RFR - JDK-8162524 : src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions In-Reply-To: <04dc2fcc-4756-00fd-7b7d-a8bed2a646fb@oracle.com> References: <0da610b4-5be3-45e5-81fa-344da47d2cca@default> <04dc2fcc-4756-00fd-7b7d-a8bed2a646fb@oracle.com> Message-ID: <8c2644c4-7222-8669-9f20-e0f98307ee4e@oracle.com> Hello, Test case is missing. I was under the assumption that test cases are mandatory unless it is not possible to write one. If it not possible to write test case, shouldn't there be a justification for the same? Regards Harsha On Monday 01 August 2016 05:47 AM, David Holmes wrote: > Hi Amit, > > On 29/07/2016 7:05 PM, Amit Sapre wrote: >> Hello, >> >> Please review this small fix. >> >> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8162524 >> >> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162524/webrev.00/ > > Looks good to me too. > > David > >> >> >> Thanks, >> >> Amit >> From david.holmes at oracle.com Mon Aug 1 08:22:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2016 18:22:49 +1000 Subject: RFR - JDK-8162524 : src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions In-Reply-To: <8c2644c4-7222-8669-9f20-e0f98307ee4e@oracle.com> References: <0da610b4-5be3-45e5-81fa-344da47d2cca@default> <04dc2fcc-4756-00fd-7b7d-a8bed2a646fb@oracle.com> <8c2644c4-7222-8669-9f20-e0f98307ee4e@oracle.com> Message-ID: <7705f4c9-4f46-2327-a407-a9b0ae6c501e@oracle.com> On 1/08/2016 5:12 PM, Harsha Wardhana B wrote: > Hello, > > Test case is missing. I was under the assumption that test cases are > mandatory unless it is not possible to write one. If it not possible to > write test case, shouldn't there be a justification for the same? noreg-hard would apply here. Extremely difficult to force an OOME at a specific point to ensure a given error path is followed. David > Regards > > Harsha > > > On Monday 01 August 2016 05:47 AM, David Holmes wrote: >> Hi Amit, >> >> On 29/07/2016 7:05 PM, Amit Sapre wrote: >>> Hello, >>> >>> Please review this small fix. >>> >>> Bug Id : https://bugs.openjdk.java.net/browse/JDK-8162524 >>> >>> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162524/webrev.00/ >> >> Looks good to me too. >> >> David >> >>> >>> >>> Thanks, >>> >>> Amit >>> > From amy.lu at oracle.com Tue Aug 2 05:57:56 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 2 Aug 2016 13:57:56 +0800 Subject: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt Message-ID: <57A03664.1040804@oracle.com> tools/jlink/JLinkOptimTest.java This test has been removed in JDK-8160829 sun/tools/jinfo/JInfoSanityTest.java sun/tools/jinfo/JInfoRunningProcessFlagTest.java sun/tools/jmap/heapconfig/JMapHeapConfigTest.java These tests have been removed in JDK-8155091 Please review the patch to delete these tests from ProblemList.txt. bug: https://bugs.openjdk.java.net/browse/JDK-8161970 https://bugs.openjdk.java.net/browse/JDK-8157664 webrev: http://cr.openjdk.java.net/~amlu/8161970-8157664/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 +++ new/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 @@ -318,7 +318,7 @@ ############################################################################ -# jdk_tools +# core_tools tools/pack200/CommandLineTests.java 7143279,8059906 generic-all @@ -368,20 +368,14 @@ sun/tools/jcmd/TestJcmdSanity.java 8031482 windows-all -sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all - sun/tools/jstatd/TestJstatdExternalRegistry.java 8046285 generic-all sun/tools/jps/TestJpsJar.java 8160923 generic-all sun/tools/jps/TestJpsJarRelative.java 6456333 generic-all -sun/tools/jinfo/JInfoRunningProcessFlagTest.java 6734748 generic-all - sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java 8057732 generic-all -sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all - demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java 8151899 generic-all ############################################################################ @@ -391,9 +385,3 @@ com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all ############################################################################ - -# core_tools - -tools/jlink/JLinkOptimTest.java 8159264 generic-all - -############################################################################ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.sapre at oracle.com Tue Aug 2 09:49:04 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Tue, 2 Aug 2016 02:49:04 -0700 (PDT) Subject: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly In-Reply-To: References: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> Message-ID: Hello, I have made changes as David suggested. Here is the new webrev link. http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ Thanks, Amit -----Original Message----- From: David Holmes Sent: Monday, August 01, 2016 12:33 PM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly Hi Amit, On 1/08/2016 4:10 PM, Amit Sapre wrote: > Hello, > > > > Please review JNI exception handling related changes. > > Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 > > Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ Sorry but that's wrong way to fix this. We should never just blindly clear exceptions and continue as if they never happened. If an exception is pending after one of these JNI calls the method should return immediately and allow the exception to propagate to the java code. Thanks, David > > > Thanks, > > Amit > From sundararajan.athijegannathan at oracle.com Tue Aug 2 11:45:51 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Tue, 2 Aug 2016 17:15:51 +0530 Subject: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt In-Reply-To: <57A03664.1040804@oracle.com> References: <57A03664.1040804@oracle.com> Message-ID: +1 for the jlink test being removed from the problem test. -Sundar On 8/2/2016 11:27 AM, Amy Lu wrote: > tools/jlink/JLinkOptimTest.java > This test has been removed in JDK-8160829 > > sun/tools/jinfo/JInfoSanityTest.java > sun/tools/jinfo/JInfoRunningProcessFlagTest.java > sun/tools/jmap/heapconfig/JMapHeapConfigTest.java > These tests have been removed in JDK-8155091 > > Please review the patch to delete these tests from ProblemList.txt. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8161970 > https://bugs.openjdk.java.net/browse/JDK-8157664 > > webrev: http://cr.openjdk.java.net/~amlu/8161970-8157664/webrev.00/ > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 > +++ new/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 > @@ -318,7 +318,7 @@ > > ############################################################################ > > -# jdk_tools > +# core_tools > > tools/pack200/CommandLineTests.java 7143279,8059906 generic-all > > @@ -368,20 +368,14 @@ > > sun/tools/jcmd/TestJcmdSanity.java 8031482 windows-all > > -sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all > - > sun/tools/jstatd/TestJstatdExternalRegistry.java 8046285 generic-all > > sun/tools/jps/TestJpsJar.java 8160923 generic-all > > sun/tools/jps/TestJpsJarRelative.java 6456333 generic-all > > -sun/tools/jinfo/JInfoRunningProcessFlagTest.java 6734748 generic-all > - > sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java 8057732 generic-all > > -sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all > - > demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java 8151899 generic-all > > ############################################################################ > @@ -391,9 +385,3 @@ > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all > > ############################################################################ > - > -# core_tools > - > -tools/jlink/JLinkOptimTest.java 8159264 generic-all > - > -############################################################################ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Tue Aug 2 11:55:42 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 2 Aug 2016 14:55:42 +0300 Subject: JDK 9 RFR of 8161970, 8157664: Remove 4 tools tests from ProblemList.txt In-Reply-To: <57A03664.1040804@oracle.com> References: <57A03664.1040804@oracle.com> Message-ID: Amy, Looks good for me! -Dmitry On 2016-08-02 08:57, Amy Lu wrote: > tools/jlink/JLinkOptimTest.java > This test has been removed in JDK-8160829 > > sun/tools/jinfo/JInfoSanityTest.java > sun/tools/jinfo/JInfoRunningProcessFlagTest.java > sun/tools/jmap/heapconfig/JMapHeapConfigTest.java > These tests have been removed in JDK-8155091 > > Please review the patch to delete these tests from ProblemList.txt. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8161970 > https://bugs.openjdk.java.net/browse/JDK-8157664 > > webrev: http://cr.openjdk.java.net/~amlu/8161970-8157664/webrev.00/ > > Thanks, > Amy > > --- old/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 > +++ new/test/ProblemList.txt 2016-08-02 13:44:34.000000000 +0800 > @@ -318,7 +318,7 @@ > > ############################################################################ > > -# jdk_tools > +# core_tools > > tools/pack200/CommandLineTests.java 7143279,8059906 generic-all > > @@ -368,20 +368,14 @@ > > sun/tools/jcmd/TestJcmdSanity.java 8031482 windows-all > > -sun/tools/jmap/heapconfig/JMapHeapConfigTest.java 8072131,8132452 generic-all > - > sun/tools/jstatd/TestJstatdExternalRegistry.java 8046285 generic-all > > sun/tools/jps/TestJpsJar.java 8160923 generic-all > > sun/tools/jps/TestJpsJarRelative.java 6456333 generic-all > > -sun/tools/jinfo/JInfoRunningProcessFlagTest.java 6734748 generic-all > - > sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.java 8057732 generic-all > > -sun/tools/jinfo/JInfoSanityTest.java 8059035 generic-all > - > demo/jvmti/compiledMethodLoad/CompiledMethodLoadTest.java 8151899 generic-all > > ############################################################################ > @@ -391,9 +385,3 @@ > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8141370 linux-i586,macosx-all > > ############################################################################ > - > -# core_tools > - > -tools/jlink/JLinkOptimTest.java 8159264 generic-all > - > -############################################################################ > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From markus.gronlund at oracle.com Tue Aug 2 12:58:46 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 2 Aug 2016 05:58:46 -0700 (PDT) Subject: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory Message-ID: Greetings, Please review this small fix to address some new issues seen in testing where OOM is erroneously being reported: Bug: https://bugs.openjdk.java.net/browse/JDK-8162945 Changeset: # HG changeset patch # User mgronlun # Date 1470141649 -7200 # Tue Aug 02 14:40:49 2016 +0200 # Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563 # Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0 [mq]: 8162945 diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c b/src/jdk.management/share/native/libmanagement_ext/Flag.c --- a/src/jdk.management/share/native/libmanagement_ext/Flag.c +++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c @@ -142,7 +142,7 @@ continue; } - if (valueObj == NULL) { + if (valueObj == NULL && !(globals[i].type == JMM_VMGLOBAL_TYPE_JSTRING)) { free(globals); JNU_ThrowOutOfMemoryError(env, 0); return 0; Summary: OOM's have manifested after the following change was integrated: 8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions The following check was then added to jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: if (valueObj == NULL) { free(globals); JNU_ThrowOutOfMemoryError(env, 0); return 0; } However, valueObj is not always the direct result of a failed JNI allocation, for example: case JMM_VMGLOBAL_TYPE_JSTRING: valueObj = globals[i].value.l; The valueObj here (a JSTRING) is coming a VM allocation, more specifically from : services/management.cpp jmm_GetVMGlobals() ... add_global_entry() } else if (flag->is_ccstr()) { Handle str = java_lang_String::create_from_str(flag->get_ccstr(), CHECK_false); <<-- global->value.l = (jobject)JNIHandles::make_local(env, str()); global->type = JMM_VMGLOBAL_TYPE_JSTRING; For certain ccstr flags, such as the "HeapDumpFlag" for example, the ccstr() is NULL (i.e. not set). So returning a NULL is fine here, the JNI NULL check validation needs to take this into account. Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.gahlin at oracle.com Tue Aug 2 13:33:29 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Tue, 2 Aug 2016 15:33:29 +0200 Subject: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory In-Reply-To: References: Message-ID: <57A0A129.8070505@oracle.com> Looks ok (not a reviewer) Erik On 2016-08-02 14:58, Markus Gronlund wrote: > > Greetings, > > Please review this small fix to address some new issues seen in > testing where OOM is erroneously being reported: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8162945 > > Changeset: > > # HG changeset patch > > # User mgronlun > > # Date 1470141649 -7200 > > # Tue Aug 02 14:40:49 2016 +0200 > > # Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563 > > # Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0 > > [mq]: 8162945 > > diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c > b/src/jdk.management/share/native/libmanagement_ext/Flag.c > > --- a/src/jdk.management/share/native/libmanagement_ext/Flag.c > > +++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c > > @@ -142,7 +142,7 @@ > > continue; > > } > > - if (valueObj == NULL) { > > + if (valueObj == NULL && !(globals[i].type == > JMM_VMGLOBAL_TYPE_JSTRING)) { > > free(globals); > > JNU_ThrowOutOfMemoryError(env, 0); > > return 0; > > Summary: > > OOM?s have manifested after the following change was integrated: > > 8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c > doesn't handle JNI exceptions > > The following check was then added to > jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: > > if (valueObj == NULL) { > free(globals); > JNU_ThrowOutOfMemoryError(env, 0); > return 0; > } > > However, valueObj is not always the direct result of a failed JNI > allocation, for example: > > case JMM_VMGLOBAL_TYPE_JSTRING: > valueObj = globals[i].value.l; > > The valueObj here (a JSTRING) is coming a VM allocation, more > specifically from : > > services/management.cpp jmm_GetVMGlobals() > ... > add_global_entry() > > } else if (flag->is_ccstr()) { > Handle str = java_lang_String::create_from_str(flag->get_ccstr(), > CHECK_false); <<-- > global->value.l = (jobject)JNIHandles::make_local(env, str()); > global->type = JMM_VMGLOBAL_TYPE_JSTRING; > > For certain ccstr flags, such as the "HeapDumpFlag" for example, the > ccstr() is NULL (i.e. not set). > > So returning a NULL is fine here, the JNI NULL check validation needs > to take this into account. > > Thanks > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Aug 2 16:29:21 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 2 Aug 2016 10:29:21 -0600 Subject: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory In-Reply-To: References: Message-ID: <265f558d-918f-f9c2-8787-604334d14a1f@oracle.com> On 8/2/16 6:58 AM, Markus Gronlund wrote: > > Greetings, > > Please review this small fix to address some new issues seen in > testing where OOM is erroneously being reported: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8162945 > > Changeset: > > # HG changeset patch > > # User mgronlun > > # Date 1470141649 -7200 > > # Tue Aug 02 14:40:49 2016 +0200 > > # Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563 > > # Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0 > > [mq]: 8162945 > > diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c > b/src/jdk.management/share/native/libmanagement_ext/Flag.c > > --- a/src/jdk.management/share/native/libmanagement_ext/Flag.c > > +++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c > > @@ -142,7 +142,7 @@ > > continue; > > } > > - if (valueObj == NULL) { > > + if (valueObj == NULL && !(globals[i].type == > JMM_VMGLOBAL_TYPE_JSTRING)) { > Might be too late, but I would prefer: if (valueObj == NULL && globals[i].type != JMM_VMGLOBAL_TYPE_JSTRING) { which I think is more clear. Dan > free(globals); > > JNU_ThrowOutOfMemoryError(env, 0); > > return 0; > > Summary: > > OOM?s have manifested after the following change was integrated: > > 8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c > doesn't handle JNI exceptions > > The following check was then added to > jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: > > if (valueObj == NULL) { > free(globals); > JNU_ThrowOutOfMemoryError(env, 0); > return 0; > } > > However, valueObj is not always the direct result of a failed JNI > allocation, for example: > > case JMM_VMGLOBAL_TYPE_JSTRING: > valueObj = globals[i].value.l; > > The valueObj here (a JSTRING) is coming a VM allocation, more > specifically from : > > services/management.cpp jmm_GetVMGlobals() > ... > add_global_entry() > > } else if (flag->is_ccstr()) { > Handle str = java_lang_String::create_from_str(flag->get_ccstr(), > CHECK_false); <<-- > global->value.l = (jobject)JNIHandles::make_local(env, str()); > global->type = JMM_VMGLOBAL_TYPE_JSTRING; > > For certain ccstr flags, such as the "HeapDumpFlag" for example, the > ccstr() is NULL (i.e. not set). > > So returning a NULL is fine here, the JNI NULL check validation needs > to take this into account. > > Thanks > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Tue Aug 2 16:30:15 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 2 Aug 2016 09:30:15 -0700 (PDT) Subject: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory In-Reply-To: <265f558d-918f-f9c2-8787-604334d14a1f@oracle.com> References: <265f558d-918f-f9c2-8787-604334d14a1f@oracle.com> Message-ID: Thanks Dan, not too late at all - I agree with your suggestion and will update accordingly. Thanks again Markus From: Daniel D. Daugherty Sent: den 2 augusti 2016 18:29 To: Markus Gronlund; serviceability-dev at openjdk.java.net Subject: Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory On 8/2/16 6:58 AM, Markus Gronlund wrote: Greetings, Please review this small fix to address some new issues seen in testing where OOM is erroneously being reported: Bug: https://bugs.openjdk.java.net/browse/JDK-8162945 Changeset: # HG changeset patch # User mgronlun # Date 1470141649 -7200 # Tue Aug 02 14:40:49 2016 +0200 # Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563 # Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0 [mq]: 8162945 diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c b/src/jdk.management/share/native/libmanagement_ext/Flag.c --- a/src/jdk.management/share/native/libmanagement_ext/Flag.c +++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c @@ -142,7 +142,7 @@ continue; } - if (valueObj == NULL) { + if (valueObj == NULL && !(globals[i].type == JMM_VMGLOBAL_TYPE_JSTRING)) { Might be too late, but I would prefer: if (valueObj == NULL && globals[i].type != JMM_VMGLOBAL_TYPE_JSTRING) { which I think is more clear. Dan free(globals); JNU_ThrowOutOfMemoryError(env, 0); return 0; Summary: OOM's have manifested after the following change was integrated: 8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions The following check was then added to jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: if (valueObj == NULL) { free(globals); JNU_ThrowOutOfMemoryError(env, 0); return 0; } However, valueObj is not always the direct result of a failed JNI allocation, for example: case JMM_VMGLOBAL_TYPE_JSTRING: valueObj = globals[i].value.l; The valueObj here (a JSTRING) is coming a VM allocation, more specifically from : services/management.cpp jmm_GetVMGlobals() ... add_global_entry() } else if (flag->is_ccstr()) { Handle str = java_lang_String::create_from_str(flag->get_ccstr(), CHECK_false); <<-- global->value.l = (jobject)JNIHandles::make_local(env, str()); global->type = JMM_VMGLOBAL_TYPE_JSTRING; For certain ccstr flags, such as the "HeapDumpFlag" for example, the ccstr() is NULL (i.e. not set). So returning a NULL is fine here, the JNI NULL check validation needs to take this into account. Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Tue Aug 2 16:30:41 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 2 Aug 2016 09:30:41 -0700 (PDT) Subject: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory In-Reply-To: <57A0A129.8070505@oracle.com> References: <57A0A129.8070505@oracle.com> Message-ID: <005a73cf-cbbb-4ce5-badc-b8a602ed796c@default> Thanks Erik! Markus From: Erik Gahlin Sent: den 2 augusti 2016 15:33 To: serviceability-dev at openjdk.java.net Subject: Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory Looks ok (not a reviewer) Erik On 2016-08-02 14:58, Markus Gronlund wrote: Greetings, Please review this small fix to address some new issues seen in testing where OOM is erroneously being reported: Bug: https://bugs.openjdk.java.net/browse/JDK-8162945 Changeset: # HG changeset patch # User mgronlun # Date 1470141649 -7200 # Tue Aug 02 14:40:49 2016 +0200 # Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563 # Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0 [mq]: 8162945 diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c b/src/jdk.management/share/native/libmanagement_ext/Flag.c --- a/src/jdk.management/share/native/libmanagement_ext/Flag.c +++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c @@ -142,7 +142,7 @@ continue; } - if (valueObj == NULL) { + if (valueObj == NULL && !(globals[i].type == JMM_VMGLOBAL_TYPE_JSTRING)) { free(globals); JNU_ThrowOutOfMemoryError(env, 0); return 0; Summary: OOM's have manifested after the following change was integrated: 8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions The following check was then added to jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: if (valueObj == NULL) { free(globals); JNU_ThrowOutOfMemoryError(env, 0); return 0; } However, valueObj is not always the direct result of a failed JNI allocation, for example: case JMM_VMGLOBAL_TYPE_JSTRING: valueObj = globals[i].value.l; The valueObj here (a JSTRING) is coming a VM allocation, more specifically from : services/management.cpp jmm_GetVMGlobals() ... add_global_entry() } else if (flag->is_ccstr()) { Handle str = java_lang_String::create_from_str(flag->get_ccstr(), CHECK_false); <<-- global->value.l = (jobject)JNIHandles::make_local(env, str()); global->type = JMM_VMGLOBAL_TYPE_JSTRING; For certain ccstr flags, such as the "HeapDumpFlag" for example, the ccstr() is NULL (i.e. not set). So returning a NULL is fine here, the JNI NULL check validation needs to take this into account. Thanks Markus -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue Aug 2 19:50:22 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 2 Aug 2016 13:50:22 -0600 Subject: RFR 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip In-Reply-To: <533e8d45-9e5b-9222-e8f6-a56280bd5d7e@oracle.com> References: <533e8d45-9e5b-9222-e8f6-a56280bd5d7e@oracle.com> Message-ID: Adding serviceability-dev at ... alias since these are JDI tests... Dan On 8/2/16 12:49 PM, George Triantafillou wrote: > Please review this small change to fix test failures in two JDI tests: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8160833 > Open webrev: http://cr.openjdk.java.net/~gtriantafill/8160833/webrev/ > > > Thanks to Tim Bell for his assistance. The fix replaces the use of > javax.rmi.CORBA.Util with String.format. See this comment > > for details. > > Tested locally on Linux with latest version of jtreg. > > -George > From david.holmes at oracle.com Wed Aug 3 00:19:57 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 10:19:57 +1000 Subject: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly In-Reply-To: References: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> Message-ID: <0607b181-0227-bb91-4b71-f141ae1798c9@oracle.com> Hi Amit, On 2/08/2016 7:49 PM, Amit Sapre wrote: > Hello, > I have made changes as David suggested. > > Here is the new webrev link. http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ If the changes are required to pass a JNI code checker then you will also need to check for exceptions from SetObjectArrayElement. While ArrayStoreException should not be possible in this code, I can't tell for certain that the passed in arrays are ensured to have the required lengths. Thanks, David > Thanks, > Amit > > -----Original Message----- > From: David Holmes > Sent: Monday, August 01, 2016 12:33 PM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly > > Hi Amit, > > On 1/08/2016 4:10 PM, Amit Sapre wrote: >> Hello, >> >> >> >> Please review JNI exception handling related changes. >> >> Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 >> >> Webrev : http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ > > Sorry but that's wrong way to fix this. We should never just blindly clear exceptions and continue as if they never happened. If an exception is pending after one of these JNI calls the method should return immediately and allow the exception to propagate to the java code. > > Thanks, > David > >> >> >> Thanks, >> >> Amit >> From david.holmes at oracle.com Wed Aug 3 01:13:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 11:13:40 +1000 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread Message-ID: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8159461 The suspend/resume signal (SR_signum) is never sent to a thread once it has started to terminate. On one platform (SuSE 12) we have seen what appears to be a "stuck" signal, which is only delivered when the terminating thread restores its original signal mask (as if pthread_sigmask makes the system realize there is a pending signal - we already check the signal was not blocked). At this point in the thread termination we have freed the osthread, so the the SR_handler would access deallocated memory. In debug builds we first hit an assertion that the current thread is a JavaThread or the VMThread - that assertion fails, even though it is a JavaThread, because we have already executed the ~JavaThread destructor and inside the ~Thread destructor we are a plain Thread not a JavaThread. The fix was to make a small adjustment to the thread termination process so that we delete the SR_lock before calling os::free_thread(). In the SR_handler() we can then use a NULL check of SR_lock() to indicate the thread has terminated and we return. While only seen on Linux I took the opportunity to apply the fix on all platforms and also cleaned up the code where we were using Thread::current() unsafely in a signal-handling context. Testing: regular tier 1 (JPRT) Kitchensink (in progress) As we can't readily reproduce the problem I tested this by having a terminating thread raise SR_signum directly from within the ~Thread destructor. Thanks, David From david.holmes at oracle.com Wed Aug 3 01:49:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 11:49:44 +1000 Subject: RFR 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip In-Reply-To: <533e8d45-9e5b-9222-e8f6-a56280bd5d7e@oracle.com> References: <533e8d45-9e5b-9222-e8f6-a56280bd5d7e@oracle.com> Message-ID: <09a47dd8-c396-78fc-301c-23882322436e@oracle.com> Hi George, On 3/08/2016 4:49 AM, George Triantafillou wrote: > Please review this small change to fix test failures in two JDI tests: There's only one test changed in the webrev ?? > JBS: https://bugs.openjdk.java.net/browse/JDK-8160833 > Open webrev: http://cr.openjdk.java.net/~gtriantafill/8160833/webrev/ > > > Thanks to Tim Bell for his assistance. The fix replaces the use of > javax.rmi.CORBA.Util with String.format. See this comment > > for details. So the assumption is that String.format will load a bunch of classes not already loaded? I assume the problem with javax.rmi.CORBA was module accessibility? Or does the Util class no longer exist? 31 * @modules java.corba Presuambly this can be removed? However this: 56 java.awt.Toolkit tk = java.awt.Toolkit.getDefaultToolkit(); suggests we need @module java.desktop (which limits this test to running on a full JDK). Thanks, David > Tested locally on Linux with latest version of jtreg. > > -George > From david.holmes at oracle.com Wed Aug 3 02:08:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 12:08:47 +1000 Subject: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory In-Reply-To: References: Message-ID: Looks good. Sorry I missed this issue in reviewing 8162524. Thanks, David On 2/08/2016 10:58 PM, Markus Gronlund wrote: > Greetings, > > > > Please review this small fix to address some new issues seen in testing > where OOM is erroneously being reported: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8162945 > > > > Changeset: > > > > # HG changeset patch > > # User mgronlun > > # Date 1470141649 -7200 > > # Tue Aug 02 14:40:49 2016 +0200 > > # Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563 > > # Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0 > > [mq]: 8162945 > > > > diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c > b/src/jdk.management/share/native/libmanagement_ext/Flag.c > > --- a/src/jdk.management/share/native/libmanagement_ext/Flag.c > > +++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c > > @@ -142,7 +142,7 @@ > > continue; > > } > > - if (valueObj == NULL) { > > + if (valueObj == NULL && !(globals[i].type == > JMM_VMGLOBAL_TYPE_JSTRING)) { > > free(globals); > > JNU_ThrowOutOfMemoryError(env, 0); > > return 0; > > > > > > Summary: > > > > OOM?s have manifested after the following change was integrated: > > 8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c > doesn't handle JNI exceptions > > The following check was then added to > jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: > > if (valueObj == NULL) { > free(globals); > JNU_ThrowOutOfMemoryError(env, 0); > return 0; > } > > However, valueObj is not always the direct result of a failed JNI > allocation, for example: > > case JMM_VMGLOBAL_TYPE_JSTRING: > valueObj = globals[i].value.l; > > The valueObj here (a JSTRING) is coming a VM allocation, more > specifically from : > > > > services/management.cpp jmm_GetVMGlobals() > ... > add_global_entry() > > } else if (flag->is_ccstr()) { > Handle str = java_lang_String::create_from_str(flag->get_ccstr(), > CHECK_false); <<-- > global->value.l = (jobject)JNIHandles::make_local(env, str()); > global->type = JMM_VMGLOBAL_TYPE_JSTRING; > > For certain ccstr flags, such as the "HeapDumpFlag" for example, the > ccstr() is NULL (i.e. not set). > > So returning a NULL is fine here, the JNI NULL check validation needs to > take this into account. > > > > Thanks > > Markus > From markus.gronlund at oracle.com Wed Aug 3 09:14:29 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 3 Aug 2016 02:14:29 -0700 (PDT) Subject: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory In-Reply-To: References: Message-ID: <77ebab21-c656-413f-9ea1-47f64e73225f@default> Thanks David! Markus -----Original Message----- From: David Holmes Sent: den 3 augusti 2016 04:09 To: Markus Gronlund; serviceability-dev at openjdk.java.net Subject: Re: RFR(XXS): 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory Looks good. Sorry I missed this issue in reviewing 8162524. Thanks, David On 2/08/2016 10:58 PM, Markus Gronlund wrote: > Greetings, > > > > Please review this small fix to address some new issues seen in > testing where OOM is erroneously being reported: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8162945 > > > > Changeset: > > > > # HG changeset patch > > # User mgronlun > > # Date 1470141649 -7200 > > # Tue Aug 02 14:40:49 2016 +0200 > > # Node ID e06e6474ff5f5798f9249aeaa6b33ec6aa021563 > > # Parent 9672159305d72f5dd430a3edd4b97c4e5bc816e0 > > [mq]: 8162945 > > > > diff --git a/src/jdk.management/share/native/libmanagement_ext/Flag.c > b/src/jdk.management/share/native/libmanagement_ext/Flag.c > > --- a/src/jdk.management/share/native/libmanagement_ext/Flag.c > > +++ b/src/jdk.management/share/native/libmanagement_ext/Flag.c > > @@ -142,7 +142,7 @@ > > continue; > > } > > - if (valueObj == NULL) { > > + if (valueObj == NULL && !(globals[i].type == > JMM_VMGLOBAL_TYPE_JSTRING)) { > > free(globals); > > JNU_ThrowOutOfMemoryError(env, 0); > > return 0; > > > > > > Summary: > > > > OOM's have manifested after the following change was integrated: > > 8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c > doesn't handle JNI exceptions > > The following check was then added to > jdk\src\jdk.management\share\native\libmanagement_ext\flags.c: > > if (valueObj == NULL) { > free(globals); > JNU_ThrowOutOfMemoryError(env, 0); > return 0; > } > > However, valueObj is not always the direct result of a failed JNI > allocation, for example: > > case JMM_VMGLOBAL_TYPE_JSTRING: > valueObj = globals[i].value.l; > > The valueObj here (a JSTRING) is coming a VM allocation, more > specifically from : > > > > services/management.cpp jmm_GetVMGlobals() ... > add_global_entry() > > } else if (flag->is_ccstr()) { > Handle str = java_lang_String::create_from_str(flag->get_ccstr(), > CHECK_false); <<-- > global->value.l = (jobject)JNIHandles::make_local(env, str()); > global->type = JMM_VMGLOBAL_TYPE_JSTRING; > > For certain ccstr flags, such as the "HeapDumpFlag" for example, the > ccstr() is NULL (i.e. not set). > > So returning a NULL is fine here, the JNI NULL check validation needs > to take this into account. > > > > Thanks > > Markus > From yasuenag at gmail.com Wed Aug 3 12:20:48 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 3 Aug 2016 21:20:48 +0900 Subject: jhsdb jstack cannot work correctly Message-ID: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> Hi all, I use "jhsdb jstack" command in JDK 9 EA b129. But it does not seem to work fine. I encountered two problems: 1. AssertionFailure: illegal bci 2. Normal mode cannot work 1. AssertionFailure: illegal bci I saw error stack as below with JDK 9 EA b129 Linux x64: ------------------- 0x00007fe06bd270c2 * java.lang.Object.wait(long) bci:-520544688 (Interpreted frame) 0x00007fe06bd1a443 sun.jvm.hotspot.utilities.AssertionFailure: illegal bci at sun.jvm.hotspot.utilities.Assert.that(jdk.hotspot.agent at 9-ea/Assert.java:32) at sun.jvm.hotspot.oops.ConstMethod.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/ConstMethod.java:297) at sun.jvm.hotspot.oops.Method.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/Method.java:282) at sun.jvm.hotspot.tools.PStack.getJavaNames(jdk.hotspot.agent at 9-ea/PStack.java:239) at sun.jvm.hotspot.tools.PStack.run(jdk.hotspot.agent at 9-ea/PStack.java:112) ------------------- jhsdb can parse compiled frame correctly. It seems to be a problem for interpreter frame only. What is the cause of this problem? interpretedVFrame in HotSpot has changed the location to store BCP? 2. Normal mode cannot work "jhsdb jstack" should work as normal mode without being added --mixed option. However, this command always works as mixed mode. I think we can fix as below: ------------------- diff -r 5acd2b561936 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Tue Aug 02 20:55:27 2016 -0700 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Wed Aug 03 21:18:57 2016 +0900 @@ -68,6 +68,10 @@ } public void runWithArgs(String... args) { + // We should recover these mode to default value. + mixedMode = false; + concurrentLocks = false; + int used = 0; for (int i = 0; i < args.length; i++) { if (args[i].equals("-m")) { ------------------- Has someone worked for them? If not so, and patch of 2. is correct, I file it to JBS and upload webrev. Thanks, Yasumasa From jini.george at oracle.com Wed Aug 3 13:23:28 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 3 Aug 2016 06:23:28 -0700 (PDT) Subject: jhsdb jstack cannot work correctly In-Reply-To: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> Message-ID: <65956218-65d6-4dbd-b170-aad7bfe365f7@default> Hi Yasumasa, Thanks for noticing this. Regarding the illegal bci, you seem to be right. >From a quick look, this looks like this came in with the introduction of interpreter_frame_mirror_offset. (https://bugs.openjdk.java.net/browse/JDK-8154580). >From frame_x86.hpp, we have: ... 71 interpreter_frame_last_sp_offset = interpreter_frame_sender_sp_offset - 1, 72 interpreter_frame_method_offset = interpreter_frame_last_sp_offset - 1, 73 interpreter_frame_mirror_offset = interpreter_frame_method_offset - 1, 74 interpreter_frame_mdp_offset = interpreter_frame_mirror_offset - 1, 75 interpreter_frame_cache_offset = interpreter_frame_mdp_offset - 1, 76 interpreter_frame_locals_offset = interpreter_frame_cache_offset - 1, 77 interpreter_frame_bcp_offset = interpreter_frame_locals_offset - 1, ... This does not match with what we have in share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java. 77 INTERPRETER_FRAME_MDX_OFFSET = INTERPRETER_FRAME_METHOD_OFFSET - 1; 78 INTERPRETER_FRAME_CACHE_OFFSET = INTERPRETER_FRAME_MDX_OFFSET - 1; 79 INTERPRETER_FRAME_LOCALS_OFFSET = INTERPRETER_FRAME_CACHE_OFFSET - 1; 80 INTERPRETER_FRAME_BCX_OFFSET = INTERPRETER_FRAME_LOCALS_OFFSET - 1; We need to have the mirror offset reflected in the SA code also. I will file a bug for this and fix this. Thank you, Jini. > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: Wednesday, August 03, 2016 5:51 PM > To: serviceability-dev at openjdk.java.net > Subject: jhsdb jstack cannot work correctly > > Hi all, > > I use "jhsdb jstack" command in JDK 9 EA b129. > But it does not seem to work fine. > > I encountered two problems: > > 1. AssertionFailure: illegal bci > 2. Normal mode cannot work > > > 1. AssertionFailure: illegal bci > I saw error stack as below with JDK 9 EA b129 Linux x64: > ------------------- > 0x00007fe06bd270c2 * java.lang.Object.wait(long) bci:-520544688 > (Interpreted frame) > 0x00007fe06bd1a443 sun.jvm.hotspot.utilities.AssertionFailure: illegal bci > at sun.jvm.hotspot.utilities.Assert.that(jdk.hotspot.agent at 9- > ea/Assert.java:32) > at > sun.jvm.hotspot.oops.ConstMethod.getLineNumberFromBCI(jdk.hotspot.age > nt at 9-ea/ConstMethod.java:297) > at > sun.jvm.hotspot.oops.Method.getLineNumberFromBCI(jdk.hotspot.agent at 9- > ea/Method.java:282) > at sun.jvm.hotspot.tools.PStack.getJavaNames(jdk.hotspot.agent at 9- > ea/PStack.java:239) > at sun.jvm.hotspot.tools.PStack.run(jdk.hotspot.agent at 9- > ea/PStack.java:112) > ------------------- > > jhsdb can parse compiled frame correctly. It seems to be a problem for > interpreter frame only. > What is the cause of this problem? > interpretedVFrame in HotSpot has changed the location to store BCP? > > > 2. Normal mode cannot work > "jhsdb jstack" should work as normal mode without being added --mixed > option. > However, this command always works as mixed mode. > I think we can fix as below: > ------------------- > diff -r 5acd2b561936 > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java > Tue Aug 02 20:55:27 2016 -0700 > +++ > b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java > Wed Aug 03 21:18:57 2016 +0900 > @@ -68,6 +68,10 @@ > } > > public void runWithArgs(String... args) { > + // We should recover these mode to default value. > + mixedMode = false; > + concurrentLocks = false; > + > int used = 0; > for (int i = 0; i < args.length; i++) { > if (args[i].equals("-m")) { > ------------------- > > > Has someone worked for them? > If not so, and patch of 2. is correct, I file it to JBS and upload webrev. > > > Thanks, > > Yasumasa > > From george.triantafillou at oracle.com Wed Aug 3 13:31:44 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 3 Aug 2016 09:31:44 -0400 Subject: RFR 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip In-Reply-To: References: <533e8d45-9e5b-9222-e8f6-a56280bd5d7e@oracle.com> Message-ID: <9cb46939-4ce9-dac1-0068-3e1b34c78c07@oracle.com> Thanks Dan! -George On 8/2/2016 3:50 PM, Daniel D. Daugherty wrote: > Adding serviceability-dev at ... alias since these are JDI tests... > > Dan > > > On 8/2/16 12:49 PM, George Triantafillou wrote: >> Please review this small change to fix test failures in two JDI tests: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8160833 >> Open webrev: http://cr.openjdk.java.net/~gtriantafill/8160833/webrev/ >> >> >> Thanks to Tim Bell for his assistance. The fix replaces the use of >> javax.rmi.CORBA.Util with String.format. See this comment >> >> for details. >> >> Tested locally on Linux with latest version of jtreg. >> >> -George >> > From frederic.parain at oracle.com Wed Aug 3 14:07:16 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 3 Aug 2016 10:07:16 -0400 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> Message-ID: <4136b535-7618-6a42-7656-f8fcebafdb60@oracle.com> David, Interesting twist about JavaThreads returning to their plain Thread nature before dying. Fix looks good to me. Fred On 08/02/2016 09:13 PM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8159461 > > The suspend/resume signal (SR_signum) is never sent to a thread once it > has started to terminate. On one platform (SuSE 12) we have seen what > appears to be a "stuck" signal, which is only delivered when the > terminating thread restores its original signal mask (as if > pthread_sigmask makes the system realize there is a pending signal - we > already check the signal was not blocked). At this point in the thread > termination we have freed the osthread, so the the SR_handler would > access deallocated memory. In debug builds we first hit an assertion > that the current thread is a JavaThread or the VMThread - that assertion > fails, even though it is a JavaThread, because we have already executed > the ~JavaThread destructor and inside the ~Thread destructor we are a > plain Thread not a JavaThread. > > The fix was to make a small adjustment to the thread termination process > so that we delete the SR_lock before calling os::free_thread(). In the > SR_handler() we can then use a NULL check of SR_lock() to indicate the > thread has terminated and we return. > > While only seen on Linux I took the opportunity to apply the fix on all > platforms and also cleaned up the code where we were using > Thread::current() unsafely in a signal-handling context. > > Testing: regular tier 1 (JPRT) > Kitchensink (in progress) > > As we can't readily reproduce the problem I tested this by having a > terminating thread raise SR_signum directly from within the ~Thread > destructor. > > Thanks, > David From george.triantafillou at oracle.com Wed Aug 3 14:24:51 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 3 Aug 2016 10:24:51 -0400 Subject: RFR 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip In-Reply-To: <09a47dd8-c396-78fc-301c-23882322436e@oracle.com> References: <533e8d45-9e5b-9222-e8f6-a56280bd5d7e@oracle.com> <09a47dd8-c396-78fc-301c-23882322436e@oracle.com> Message-ID: Hi David, Thanks for your review. On 8/2/2016 9:49 PM, David Holmes wrote: > Hi George, > > On 3/08/2016 4:49 AM, George Triantafillou wrote: >> Please review this small change to fix test failures in two JDI tests: > > There's only one test changed in the webrev ?? RedefineCrossEvent.java simply runs a set of tests, including ClassesByName2Test.java, with @run driver. So fixing ClassesByName2Test.java also fixed the failure in RedefineCrossEvent.java. > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8160833 >> Open webrev: http://cr.openjdk.java.net/~gtriantafill/8160833/webrev/ >> >> >> Thanks to Tim Bell for his assistance. The fix replaces the use of >> javax.rmi.CORBA.Util with String.format. See this comment >> >> >> for details. > > So the assumption is that String.format will load a bunch of classes > not already loaded? Yes, and the test requires that those classes be loaded after ClassesByName2Targ. > I assume the problem with javax.rmi.CORBA was module accessibility? Or > does the Util class no longer exist? Yes, the problem was module accessibility. I tried to unravel a simple way to add module access, but was unsuccessful. > > 31 * @modules java.corba > > Presuambly this can be removed? Yes, good catch. java.corba is no longer required and I've removed it. New webrev is here: http://cr.openjdk.java.net/~gtriantafill/8160833.01/webrev/ > > However this: > > 56 java.awt.Toolkit tk = java.awt.Toolkit.getDefaultToolkit(); > > suggests we need @module java.desktop (which limits this test to > running on a full JDK). I don't know, since this was in the initial revision in the repo. -George > > Thanks, > David > >> Tested locally on Linux with latest version of jtreg. >> >> -George >> From yasuenag at gmail.com Wed Aug 3 14:45:04 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 3 Aug 2016 23:45:04 +0900 Subject: jhsdb jstack cannot work correctly In-Reply-To: <65956218-65d6-4dbd-b170-aad7bfe365f7@default> References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> <65956218-65d6-4dbd-b170-aad7bfe365f7@default> Message-ID: <97808f9e-0763-9421-84d0-65ff24ba0d8a@gmail.com> Hi Jini, Thank you for your advice! I could get thread dump with this change: ----------------- diff -r 5acd2b561936 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java Tue Aug 02 20:55:27 2016 -0700 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java Wed Aug 03 23:42:36 2016 +0900 @@ -48,7 +48,7 @@ private static final int SENDER_SP_OFFSET = 2; // Interpreter frames - private static final int INTERPRETER_FRAME_MIRROR_OFFSET = 2; // for native calls only + private static int INTERPRETER_FRAME_MIRROR_OFFSET; private static final int INTERPRETER_FRAME_SENDER_SP_OFFSET = -1; private static final int INTERPRETER_FRAME_LAST_SP_OFFSET = INTERPRETER_FRAME_SENDER_SP_OFFSET - 1; private static final int INTERPRETER_FRAME_METHOD_OFFSET = INTERPRETER_FRAME_LAST_SP_OFFSET - 1; @@ -74,7 +74,8 @@ } private static synchronized void initialize(TypeDataBase db) { - INTERPRETER_FRAME_MDX_OFFSET = INTERPRETER_FRAME_METHOD_OFFSET - 1; + INTERPRETER_FRAME_MIRROR_OFFSET = INTERPRETER_FRAME_METHOD_OFFSET - 1; + INTERPRETER_FRAME_MDX_OFFSET = INTERPRETER_FRAME_MIRROR_OFFSET - 1; INTERPRETER_FRAME_CACHE_OFFSET = INTERPRETER_FRAME_MDX_OFFSET - 1; INTERPRETER_FRAME_LOCALS_OFFSET = INTERPRETER_FRAME_CACHE_OFFSET - 1; INTERPRETER_FRAME_BCX_OFFSET = INTERPRETER_FRAME_LOCALS_OFFSET - 1; ----------------- I hope to resolve this issue ASAP. Yasumasa On 2016/08/03 22:23, Jini Susan George wrote: > Hi Yasumasa, > > Thanks for noticing this. Regarding the illegal bci, you seem to be right. From a quick look, this looks like this came in with the introduction of interpreter_frame_mirror_offset. (https://bugs.openjdk.java.net/browse/JDK-8154580). > From frame_x86.hpp, we have: > > ... > 71 interpreter_frame_last_sp_offset = interpreter_frame_sender_sp_offset - 1, > 72 interpreter_frame_method_offset = interpreter_frame_last_sp_offset - 1, > 73 interpreter_frame_mirror_offset = interpreter_frame_method_offset - 1, > 74 interpreter_frame_mdp_offset = interpreter_frame_mirror_offset - 1, > 75 interpreter_frame_cache_offset = interpreter_frame_mdp_offset - 1, > 76 interpreter_frame_locals_offset = interpreter_frame_cache_offset - 1, > 77 interpreter_frame_bcp_offset = interpreter_frame_locals_offset - 1, > ... > > This does not match with what we have in share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java. > > 77 INTERPRETER_FRAME_MDX_OFFSET = INTERPRETER_FRAME_METHOD_OFFSET - 1; > 78 INTERPRETER_FRAME_CACHE_OFFSET = INTERPRETER_FRAME_MDX_OFFSET - 1; > 79 INTERPRETER_FRAME_LOCALS_OFFSET = INTERPRETER_FRAME_CACHE_OFFSET - 1; > 80 INTERPRETER_FRAME_BCX_OFFSET = INTERPRETER_FRAME_LOCALS_OFFSET - 1; > > We need to have the mirror offset reflected in the SA code also. I will file a bug for this and fix this. > > Thank you, > Jini. > > >> -----Original Message----- >> From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] >> Sent: Wednesday, August 03, 2016 5:51 PM >> To: serviceability-dev at openjdk.java.net >> Subject: jhsdb jstack cannot work correctly >> >> Hi all, >> >> I use "jhsdb jstack" command in JDK 9 EA b129. >> But it does not seem to work fine. >> >> I encountered two problems: >> >> 1. AssertionFailure: illegal bci >> 2. Normal mode cannot work >> >> >> 1. AssertionFailure: illegal bci >> I saw error stack as below with JDK 9 EA b129 Linux x64: >> ------------------- >> 0x00007fe06bd270c2 * java.lang.Object.wait(long) bci:-520544688 >> (Interpreted frame) >> 0x00007fe06bd1a443 sun.jvm.hotspot.utilities.AssertionFailure: illegal bci >> at sun.jvm.hotspot.utilities.Assert.that(jdk.hotspot.agent at 9- >> ea/Assert.java:32) >> at >> sun.jvm.hotspot.oops.ConstMethod.getLineNumberFromBCI(jdk.hotspot.age >> nt at 9-ea/ConstMethod.java:297) >> at >> sun.jvm.hotspot.oops.Method.getLineNumberFromBCI(jdk.hotspot.agent at 9- >> ea/Method.java:282) >> at sun.jvm.hotspot.tools.PStack.getJavaNames(jdk.hotspot.agent at 9- >> ea/PStack.java:239) >> at sun.jvm.hotspot.tools.PStack.run(jdk.hotspot.agent at 9- >> ea/PStack.java:112) >> ------------------- >> >> jhsdb can parse compiled frame correctly. It seems to be a problem for >> interpreter frame only. >> What is the cause of this problem? >> interpretedVFrame in HotSpot has changed the location to store BCP? >> >> >> 2. Normal mode cannot work >> "jhsdb jstack" should work as normal mode without being added --mixed >> option. >> However, this command always works as mixed mode. >> I think we can fix as below: >> ------------------- >> diff -r 5acd2b561936 >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java >> --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java >> Tue Aug 02 20:55:27 2016 -0700 >> +++ >> b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java >> Wed Aug 03 21:18:57 2016 +0900 >> @@ -68,6 +68,10 @@ >> } >> >> public void runWithArgs(String... args) { >> + // We should recover these mode to default value. >> + mixedMode = false; >> + concurrentLocks = false; >> + >> int used = 0; >> for (int i = 0; i < args.length; i++) { >> if (args[i].equals("-m")) { >> ------------------- >> >> >> Has someone worked for them? >> If not so, and patch of 2. is correct, I file it to JBS and upload webrev. >> >> >> Thanks, >> >> Yasumasa >> >> From david.holmes at oracle.com Wed Aug 3 20:58:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Aug 2016 06:58:00 +1000 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: <4136b535-7618-6a42-7656-f8fcebafdb60@oracle.com> References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> <4136b535-7618-6a42-7656-f8fcebafdb60@oracle.com> Message-ID: <15f95901-eac9-4d20-1e76-94220a8b8934@oracle.com> On 4/08/2016 12:07 AM, Frederic Parain wrote: > David, > > Interesting twist about JavaThreads returning to their plain > Thread nature before dying. Yes that was quite baffling for a while :) > Fix looks good to me. Thanks for the review Fred! David > Fred > > On 08/02/2016 09:13 PM, David Holmes wrote: >> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8159461 >> >> The suspend/resume signal (SR_signum) is never sent to a thread once it >> has started to terminate. On one platform (SuSE 12) we have seen what >> appears to be a "stuck" signal, which is only delivered when the >> terminating thread restores its original signal mask (as if >> pthread_sigmask makes the system realize there is a pending signal - we >> already check the signal was not blocked). At this point in the thread >> termination we have freed the osthread, so the the SR_handler would >> access deallocated memory. In debug builds we first hit an assertion >> that the current thread is a JavaThread or the VMThread - that assertion >> fails, even though it is a JavaThread, because we have already executed >> the ~JavaThread destructor and inside the ~Thread destructor we are a >> plain Thread not a JavaThread. >> >> The fix was to make a small adjustment to the thread termination process >> so that we delete the SR_lock before calling os::free_thread(). In the >> SR_handler() we can then use a NULL check of SR_lock() to indicate the >> thread has terminated and we return. >> >> While only seen on Linux I took the opportunity to apply the fix on all >> platforms and also cleaned up the code where we were using >> Thread::current() unsafely in a signal-handling context. >> >> Testing: regular tier 1 (JPRT) >> Kitchensink (in progress) >> >> As we can't readily reproduce the problem I tested this by having a >> terminating thread raise SR_signum directly from within the ~Thread >> destructor. >> >> Thanks, >> David From yasuenag at gmail.com Thu Aug 4 13:25:39 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 4 Aug 2016 22:25:39 +0900 Subject: jhsdb jstack cannot work correctly In-Reply-To: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> Message-ID: <57A34253.1080409@gmail.com> Hi all, > 2. Normal mode cannot work > "jhsdb jstack" should work as normal mode without being added --mixed option. > However, this command always works as mixed mode. Does someone work for this issue? If not, I will file it to JBS. Thanks, Yasumasa On 2016/08/03 21:20, Yasumasa Suenaga wrote: > Hi all, > > I use "jhsdb jstack" command in JDK 9 EA b129. > But it does not seem to work fine. > > I encountered two problems: > > 1. AssertionFailure: illegal bci > 2. Normal mode cannot work > > > 1. AssertionFailure: illegal bci > I saw error stack as below with JDK 9 EA b129 Linux x64: > ------------------- > 0x00007fe06bd270c2 * java.lang.Object.wait(long) bci:-520544688 (Interpreted frame) > 0x00007fe06bd1a443 sun.jvm.hotspot.utilities.AssertionFailure: illegal bci > at sun.jvm.hotspot.utilities.Assert.that(jdk.hotspot.agent at 9-ea/Assert.java:32) > at sun.jvm.hotspot.oops.ConstMethod.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/ConstMethod.java:297) > at sun.jvm.hotspot.oops.Method.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/Method.java:282) > at sun.jvm.hotspot.tools.PStack.getJavaNames(jdk.hotspot.agent at 9-ea/PStack.java:239) > at sun.jvm.hotspot.tools.PStack.run(jdk.hotspot.agent at 9-ea/PStack.java:112) > ------------------- > > jhsdb can parse compiled frame correctly. It seems to be a problem for interpreter frame only. > What is the cause of this problem? > interpretedVFrame in HotSpot has changed the location to store BCP? > > > 2. Normal mode cannot work > "jhsdb jstack" should work as normal mode without being added --mixed option. > However, this command always works as mixed mode. > I think we can fix as below: > ------------------- > diff -r 5acd2b561936 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Tue Aug 02 20:55:27 2016 -0700 > +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Wed Aug 03 21:18:57 2016 +0900 > @@ -68,6 +68,10 @@ > } > > public void runWithArgs(String... args) { > + // We should recover these mode to default value. > + mixedMode = false; > + concurrentLocks = false; > + > int used = 0; > for (int i = 0; i < args.length; i++) { > if (args[i].equals("-m")) { > ------------------- > > > Has someone worked for them? > If not so, and patch of 2. is correct, I file it to JBS and upload webrev. > > > Thanks, > > Yasumasa > > From arvind.aprameya at oracle.com Thu Aug 4 13:36:44 2016 From: arvind.aprameya at oracle.com (Arvind Aprameya) Date: Thu, 4 Aug 2016 06:36:44 -0700 (PDT) Subject: jhsdb jstack cannot work correctly In-Reply-To: <57A34253.1080409@gmail.com> References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> <57A34253.1080409@gmail.com> Message-ID: <427c2eb5-a968-40fc-a7a0-bc52a5dbae9d@default> Hi Yasumasa, We will take this up and do it. Regards, Arvind -----Original Message----- From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] Sent: Thursday, August 04, 2016 6:56 PM To: serviceability-dev at openjdk.java.net Subject: Re: jhsdb jstack cannot work correctly Hi all, > 2. Normal mode cannot work > "jhsdb jstack" should work as normal mode without being added --mixed option. > However, this command always works as mixed mode. Does someone work for this issue? If not, I will file it to JBS. Thanks, Yasumasa On 2016/08/03 21:20, Yasumasa Suenaga wrote: > Hi all, > > I use "jhsdb jstack" command in JDK 9 EA b129. > But it does not seem to work fine. > > I encountered two problems: > > 1. AssertionFailure: illegal bci > 2. Normal mode cannot work > > > 1. AssertionFailure: illegal bci > I saw error stack as below with JDK 9 EA b129 Linux x64: > ------------------- > 0x00007fe06bd270c2 * java.lang.Object.wait(long) bci:-520544688 (Interpreted frame) > 0x00007fe06bd1a443 sun.jvm.hotspot.utilities.AssertionFailure: illegal bci > at sun.jvm.hotspot.utilities.Assert.that(jdk.hotspot.agent at 9-ea/Assert.java:32) > at sun.jvm.hotspot.oops.ConstMethod.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/ConstMethod.java:297) > at sun.jvm.hotspot.oops.Method.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/Method.java:282) > at sun.jvm.hotspot.tools.PStack.getJavaNames(jdk.hotspot.agent at 9-ea/PStack.java:239) > at sun.jvm.hotspot.tools.PStack.run(jdk.hotspot.agent at 9-ea/PStack.java:112) > ------------------- > > jhsdb can parse compiled frame correctly. It seems to be a problem for interpreter frame only. > What is the cause of this problem? > interpretedVFrame in HotSpot has changed the location to store BCP? > > > 2. Normal mode cannot work > "jhsdb jstack" should work as normal mode without being added --mixed option. > However, this command always works as mixed mode. > I think we can fix as below: > ------------------- > diff -r 5acd2b561936 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Tue Aug 02 20:55:27 2016 -0700 > +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Wed Aug 03 21:18:57 2016 +0900 > @@ -68,6 +68,10 @@ > } > > public void runWithArgs(String... args) { > + // We should recover these mode to default value. > + mixedMode = false; > + concurrentLocks = false; > + > int used = 0; > for (int i = 0; i < args.length; i++) { > if (args[i].equals("-m")) { > ------------------- > > > Has someone worked for them? > If not so, and patch of 2. is correct, I file it to JBS and upload webrev. > > > Thanks, > > Yasumasa > > From arvind.aprameya at oracle.com Thu Aug 4 13:57:22 2016 From: arvind.aprameya at oracle.com (Arvind Aprameya) Date: Thu, 4 Aug 2016 06:57:22 -0700 (PDT) Subject: jhsdb jstack cannot work correctly In-Reply-To: <57A34253.1080409@gmail.com> References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> <57A34253.1080409@gmail.com> Message-ID: <0710b0b3-0783-4733-a04c-36555b244d3d@default> Hi Yasumasa, We already have a bug filed for this one JDK-8163143 . regards, Arvind -----Original Message----- From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] Sent: Thursday, August 04, 2016 6:56 PM To: serviceability-dev at openjdk.java.net Subject: Re: jhsdb jstack cannot work correctly Hi all, > 2. Normal mode cannot work > "jhsdb jstack" should work as normal mode without being added --mixed option. > However, this command always works as mixed mode. Does someone work for this issue? If not, I will file it to JBS. Thanks, Yasumasa On 2016/08/03 21:20, Yasumasa Suenaga wrote: > Hi all, > > I use "jhsdb jstack" command in JDK 9 EA b129. > But it does not seem to work fine. > > I encountered two problems: > > 1. AssertionFailure: illegal bci > 2. Normal mode cannot work > > > 1. AssertionFailure: illegal bci > I saw error stack as below with JDK 9 EA b129 Linux x64: > ------------------- > 0x00007fe06bd270c2 * java.lang.Object.wait(long) bci:-520544688 (Interpreted frame) > 0x00007fe06bd1a443 sun.jvm.hotspot.utilities.AssertionFailure: illegal bci > at sun.jvm.hotspot.utilities.Assert.that(jdk.hotspot.agent at 9-ea/Assert.java:32) > at sun.jvm.hotspot.oops.ConstMethod.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/ConstMethod.java:297) > at sun.jvm.hotspot.oops.Method.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/Method.java:282) > at sun.jvm.hotspot.tools.PStack.getJavaNames(jdk.hotspot.agent at 9-ea/PStack.java:239) > at sun.jvm.hotspot.tools.PStack.run(jdk.hotspot.agent at 9-ea/PStack.java:112) > ------------------- > > jhsdb can parse compiled frame correctly. It seems to be a problem for interpreter frame only. > What is the cause of this problem? > interpretedVFrame in HotSpot has changed the location to store BCP? > > > 2. Normal mode cannot work > "jhsdb jstack" should work as normal mode without being added --mixed option. > However, this command always works as mixed mode. > I think we can fix as below: > ------------------- > diff -r 5acd2b561936 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java > --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Tue Aug 02 20:55:27 2016 -0700 > +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Wed Aug 03 21:18:57 2016 +0900 > @@ -68,6 +68,10 @@ > } > > public void runWithArgs(String... args) { > + // We should recover these mode to default value. > + mixedMode = false; > + concurrentLocks = false; > + > int used = 0; > for (int i = 0; i < args.length; i++) { > if (args[i].equals("-m")) { > ------------------- > > > Has someone worked for them? > If not so, and patch of 2. is correct, I file it to JBS and upload webrev. > > > Thanks, > > Yasumasa > > From yasuenag at gmail.com Thu Aug 4 14:16:37 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 4 Aug 2016 23:16:37 +0900 Subject: jhsdb jstack cannot work correctly In-Reply-To: <0710b0b3-0783-4733-a04c-36555b244d3d@default> References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> <57A34253.1080409@gmail.com> <0710b0b3-0783-4733-a04c-36555b244d3d@default> Message-ID: <695b62e3-94df-c07d-3c98-e997045f828f@gmail.com> Hi Arvind, I've reported two issues. I filed another one (jhsdb jstack cannot work with normal mode) to JBS as JDK-8163185. Thanks, Yasumasa On 2016/08/04 22:57, Arvind Aprameya wrote: > Hi Yasumasa, > We already have a bug filed for this one JDK-8163143 . > > regards, > Arvind > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: Thursday, August 04, 2016 6:56 PM > To: serviceability-dev at openjdk.java.net > Subject: Re: jhsdb jstack cannot work correctly > > Hi all, > >> 2. Normal mode cannot work >> "jhsdb jstack" should work as normal mode without being added --mixed option. >> However, this command always works as mixed mode. > > Does someone work for this issue? > If not, I will file it to JBS. > > > Thanks, > > Yasumasa > > > On 2016/08/03 21:20, Yasumasa Suenaga wrote: >> Hi all, >> >> I use "jhsdb jstack" command in JDK 9 EA b129. >> But it does not seem to work fine. >> >> I encountered two problems: >> >> 1. AssertionFailure: illegal bci >> 2. Normal mode cannot work >> >> >> 1. AssertionFailure: illegal bci >> I saw error stack as below with JDK 9 EA b129 Linux x64: >> ------------------- >> 0x00007fe06bd270c2 * java.lang.Object.wait(long) bci:-520544688 (Interpreted frame) >> 0x00007fe06bd1a443 sun.jvm.hotspot.utilities.AssertionFailure: illegal bci >> at sun.jvm.hotspot.utilities.Assert.that(jdk.hotspot.agent at 9-ea/Assert.java:32) >> at sun.jvm.hotspot.oops.ConstMethod.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/ConstMethod.java:297) >> at sun.jvm.hotspot.oops.Method.getLineNumberFromBCI(jdk.hotspot.agent at 9-ea/Method.java:282) >> at sun.jvm.hotspot.tools.PStack.getJavaNames(jdk.hotspot.agent at 9-ea/PStack.java:239) >> at sun.jvm.hotspot.tools.PStack.run(jdk.hotspot.agent at 9-ea/PStack.java:112) >> ------------------- >> >> jhsdb can parse compiled frame correctly. It seems to be a problem for interpreter frame only. >> What is the cause of this problem? >> interpretedVFrame in HotSpot has changed the location to store BCP? >> >> >> 2. Normal mode cannot work >> "jhsdb jstack" should work as normal mode without being added --mixed option. >> However, this command always works as mixed mode. >> I think we can fix as below: >> ------------------- >> diff -r 5acd2b561936 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java >> --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Tue Aug 02 20:55:27 2016 -0700 >> +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/JStack.java Wed Aug 03 21:18:57 2016 +0900 >> @@ -68,6 +68,10 @@ >> } >> >> public void runWithArgs(String... args) { >> + // We should recover these mode to default value. >> + mixedMode = false; >> + concurrentLocks = false; >> + >> int used = 0; >> for (int i = 0; i < args.length; i++) { >> if (args[i].equals("-m")) { >> ------------------- >> >> >> Has someone worked for them? >> If not so, and patch of 2. is correct, I file it to JBS and upload webrev. >> >> >> Thanks, >> >> Yasumasa >> >> From yasuenag at gmail.com Thu Aug 4 14:24:41 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 4 Aug 2016 23:24:41 +0900 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode Message-ID: Hi all, This review request is related to [1]. "jhsdb jstack" should work as normal mode without being added --mixed option. However, this command always works as mixed mode. So I uploaded webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html From dmitry.samersoff at oracle.com Thu Aug 4 14:43:43 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 4 Aug 2016 17:43:43 +0300 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: References: Message-ID: <7974c5e5-de31-27b4-384e-ce41757aea2f@oracle.com> Yasumasa, Looks good for me. Comment is a bit misleading, so it might be better to remove it (no need to re-review). -Dmitry On 2016-08-04 17:24, Yasumasa Suenaga wrote: > Hi all, > > This review request is related to [1]. > > "jhsdb jstack" should work as normal mode without being added --mixed > option. > However, this command always works as mixed mode. > > So I uploaded webrev for this issue. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ > > > I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Thu Aug 4 14:51:04 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 4 Aug 2016 23:51:04 +0900 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: <7974c5e5-de31-27b4-384e-ce41757aea2f@oracle.com> References: <7974c5e5-de31-27b4-384e-ce41757aea2f@oracle.com> Message-ID: Thanks Dmitry, 2016/08/04 23:44 "Dmitry Samersoff" : > > Yasumasa, > > Looks good for me. > > Comment is a bit misleading, so it might be better to remove it (no need > to re-review). Okay, I will remove it. Yasumasa > -Dmitry > > > On 2016-08-04 17:24, Yasumasa Suenaga wrote: > > Hi all, > > > > This review request is related to [1]. > > > > "jhsdb jstack" should work as normal mode without being added --mixed > > option. > > However, this command always works as mixed mode. > > > > So I uploaded webrev for this issue. Could you review it? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ > > > > > > I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. > > So I need a sponsor. > > > > > > Thanks, > > > > Yasumasa > > > > > > [1] > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Aug 4 15:48:13 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Aug 2016 17:48:13 +0200 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> Message-ID: Hi David, thanks for doing this change on all platforms. The fix looks good. Maybe you can just extend the following comment with something like: // Note that the SR_lock plays no role in this suspend/resume protocol. // It is only used in SR_handler as a thread termination indicator if NULL. Regards, Volker On Wed, Aug 3, 2016 at 3:13 AM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8159461 > > The suspend/resume signal (SR_signum) is never sent to a thread once it > has started to terminate. On one platform (SuSE 12) we have seen what > appears to be a "stuck" signal, which is only delivered when the > terminating thread restores its original signal mask (as if pthread_sigmask > makes the system realize there is a pending signal - we already check the > signal was not blocked). At this point in the thread termination we have > freed the osthread, so the the SR_handler would access deallocated memory. > In debug builds we first hit an assertion that the current thread is a > JavaThread or the VMThread - that assertion fails, even though it is a > JavaThread, because we have already executed the ~JavaThread destructor and > inside the ~Thread destructor we are a plain Thread not a JavaThread. > > The fix was to make a small adjustment to the thread termination process > so that we delete the SR_lock before calling os::free_thread(). In the > SR_handler() we can then use a NULL check of SR_lock() to indicate the > thread has terminated and we return. > > While only seen on Linux I took the opportunity to apply the fix on all > platforms and also cleaned up the code where we were using > Thread::current() unsafely in a signal-handling context. > > Testing: regular tier 1 (JPRT) > Kitchensink (in progress) > > As we can't readily reproduce the problem I tested this by having a > terminating thread raise SR_signum directly from within the ~Thread > destructor. > > Thanks, > David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Thu Aug 4 16:19:34 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 4 Aug 2016 21:49:34 +0530 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot Message-ID: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> Hello All, Please review the below simple test fix for the issue, https://bugs.openjdk.java.net/browse/JDK-8151345 with webrev located at, http://cr.openjdk.java.net/~hb/8151345/webrev.00/ Regards Harsha From david.holmes at oracle.com Fri Aug 5 02:28:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Aug 2016 12:28:47 +1000 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> Message-ID: <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> Hi Volker, Thanks for looking at this. On 5/08/2016 1:48 AM, Volker Simonis wrote: > Hi David, > > thanks for doing this change on all platforms. > The fix looks good. Maybe you can just extend the following comment with > something like: > > // Note that the SR_lock plays no role in this suspend/resume protocol. > // It is only used in SR_handler as a thread termination indicator if > NULL. Darn this code is confusing - too many "SR"'s :( I have added // Note that the SR_lock plays no role in this suspend/resume protocol, // but is checked for NULL in SR_handler as a thread termination indicator. Updated webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev.v2/ This also reminded me to follow up on why the Solaris SR_handler is different and I found it is not actually installed as a direct signal handler, but is called from the real signal handler if dealing with a JavaThread or the VMThread. Consequently the Solaris version of the SR_handler can not encounter this specific bug and so I have reverted the changes to os_solaris.cpp Thanks, David > Regards, > Volker > > On Wed, Aug 3, 2016 at 3:13 AM, David Holmes > wrote: > > webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ > > > bug: https://bugs.openjdk.java.net/browse/JDK-8159461 > > > The suspend/resume signal (SR_signum) is never sent to a thread once > it has started to terminate. On one platform (SuSE 12) we have seen > what appears to be a "stuck" signal, which is only delivered when > the terminating thread restores its original signal mask (as if > pthread_sigmask makes the system realize there is a pending signal - > we already check the signal was not blocked). At this point in the > thread termination we have freed the osthread, so the the SR_handler > would access deallocated memory. In debug builds we first hit an > assertion that the current thread is a JavaThread or the VMThread - > that assertion fails, even though it is a JavaThread, because we > have already executed the ~JavaThread destructor and inside the > ~Thread destructor we are a plain Thread not a JavaThread. > > The fix was to make a small adjustment to the thread termination > process so that we delete the SR_lock before calling > os::free_thread(). In the SR_handler() we can then use a NULL check > of SR_lock() to indicate the thread has terminated and we return. > > While only seen on Linux I took the opportunity to apply the fix on > all platforms and also cleaned up the code where we were using > Thread::current() unsafely in a signal-handling context. > > Testing: regular tier 1 (JPRT) > Kitchensink (in progress) > > As we can't readily reproduce the problem I tested this by having a > terminating thread raise SR_signum directly from within the ~Thread > destructor. > > Thanks, > David > > From david.holmes at oracle.com Fri Aug 5 05:49:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Aug 2016 15:49:22 +1000 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: References: Message-ID: On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: > Hi all, > > This review request is related to [1]. > > "jhsdb jstack" should work as normal mode without being added --mixed > option. > However, this command always works as mixed mode. So it seems to me the JStack class has a very poorly designed API and command-line interface. It appears that jstack wants to default to mixedMode and concurrentLocks, but provides no means to disable those defaults. Given there is no way to turn those settings off from the commad-line then the default should be that they are off! Then you would not need current proposed change. That said the proposed fix effectively disables those defaults, which seems to me to be a change in behaviour. I can't see a way to fix this without breaking existing behaviour somewhere. In which case I would change the way the JStack instance is initialized by default ie: public JStack() { this(true, true); } becomes: public JStack() { this(false, false); } Or it may be better to handle this on the jhsdb side and change this: JStack.main(newArgs.toArray(new String[newArgs.size()])); to JStack js = new jstack(false,false); js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); Cheers, David > So I uploaded webrev for this issue. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ > > > I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html > From yasuenag at gmail.com Fri Aug 5 10:55:02 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 5 Aug 2016 19:55:02 +0900 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: References: Message-ID: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> Hi David, Thank you for your comment. For not to break current behavior, I think we should not change c'tor of JStack. I uploaded new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.01/ David, is it okay? Dmitry, could you review again? Thanks, Yasumasa On 2016/08/05 14:49, David Holmes wrote: > On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> This review request is related to [1]. >> >> "jhsdb jstack" should work as normal mode without being added --mixed >> option. >> However, this command always works as mixed mode. > > So it seems to me the JStack class has a very poorly designed API and command-line interface. It appears that jstack wants to default to mixedMode and concurrentLocks, but provides no means to disable those defaults. Given there is no way to turn those settings off from the commad-line then the default should be that they are off! Then you would not need current proposed change. > > That said the proposed fix effectively disables those defaults, which seems to me to be a change in behaviour. > > I can't see a way to fix this without breaking existing behaviour somewhere. In which case I would change the way the JStack instance is initialized by default ie: > > public JStack() { > this(true, true); > } > > becomes: > > public JStack() { > this(false, false); > } > > Or it may be better to handle this on the jhsdb side and change this: > > JStack.main(newArgs.toArray(new String[newArgs.size()])); > to > > JStack js = new jstack(false,false); > js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); > > > Cheers, > David > >> So I uploaded webrev for this issue. Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ >> >> >> I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html >> From dmitry.samersoff at oracle.com Fri Aug 5 10:57:33 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 5 Aug 2016 13:57:33 +0300 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> References: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> Message-ID: Yasumasa, I'm OK with this fix. -Dmitry On 2016-08-05 13:55, Yasumasa Suenaga wrote: > Hi David, > > Thank you for your comment. > > For not to break current behavior, I think we should not change c'tor of > JStack. > I uploaded new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.01/ > > David, is it okay? > Dmitry, could you review again? > > > Thanks, > > Yasumasa > > > On 2016/08/05 14:49, David Holmes wrote: >> On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This review request is related to [1]. >>> >>> "jhsdb jstack" should work as normal mode without being added --mixed >>> option. >>> However, this command always works as mixed mode. >> >> So it seems to me the JStack class has a very poorly designed API and >> command-line interface. It appears that jstack wants to default to >> mixedMode and concurrentLocks, but provides no means to disable those >> defaults. Given there is no way to turn those settings off from the >> commad-line then the default should be that they are off! Then you >> would not need current proposed change. >> >> That said the proposed fix effectively disables those defaults, which >> seems to me to be a change in behaviour. >> >> I can't see a way to fix this without breaking existing behaviour >> somewhere. In which case I would change the way the JStack instance is >> initialized by default ie: >> >> public JStack() { >> this(true, true); >> } >> >> becomes: >> >> public JStack() { >> this(false, false); >> } >> >> Or it may be better to handle this on the jhsdb side and change this: >> >> JStack.main(newArgs.toArray(new String[newArgs.size()])); >> to >> >> JStack js = new jstack(false,false); >> js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); >> >> >> Cheers, >> David >> >>> So I uploaded webrev for this issue. Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ >>> >>> >>> I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Fri Aug 5 11:38:04 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 5 Aug 2016 21:38:04 +1000 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> References: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> Message-ID: On 5/08/2016 8:55 PM, Yasumasa Suenaga wrote: > Hi David, > > Thank you for your comment. > > For not to break current behavior, I think we should not change c'tor of > JStack. > I uploaded new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.01/ > > David, is it okay? It is a better fix in my opinion but still changes the behaviour of jhsdb - or is that not an issue? Is jhsdb new with 9? Thanks, David > Dmitry, could you review again? > > > Thanks, > > Yasumasa > > > On 2016/08/05 14:49, David Holmes wrote: >> On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> This review request is related to [1]. >>> >>> "jhsdb jstack" should work as normal mode without being added --mixed >>> option. >>> However, this command always works as mixed mode. >> >> So it seems to me the JStack class has a very poorly designed API and >> command-line interface. It appears that jstack wants to default to >> mixedMode and concurrentLocks, but provides no means to disable those >> defaults. Given there is no way to turn those settings off from the >> commad-line then the default should be that they are off! Then you >> would not need current proposed change. >> >> That said the proposed fix effectively disables those defaults, which >> seems to me to be a change in behaviour. >> >> I can't see a way to fix this without breaking existing behaviour >> somewhere. In which case I would change the way the JStack instance is >> initialized by default ie: >> >> public JStack() { >> this(true, true); >> } >> >> becomes: >> >> public JStack() { >> this(false, false); >> } >> >> Or it may be better to handle this on the jhsdb side and change this: >> >> JStack.main(newArgs.toArray(new String[newArgs.size()])); >> to >> >> JStack js = new jstack(false,false); >> js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); >> >> >> Cheers, >> David >> >>> So I uploaded webrev for this issue. Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ >>> >>> >>> I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html >>> >>> From yasuenag at gmail.com Fri Aug 5 11:42:55 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 5 Aug 2016 20:42:55 +0900 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: References: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> Message-ID: > It is a better fix in my opinion but still changes the behaviour of jhsdb - or is that not an issue? Is jhsdb new with 9? At least, until April 2016, "jhsdb jstack" worked as normal mode (and not concurrent lock) mode by default. jhsdb jstack --help shows as below: ------------- --locks to print java.util.concurrent locks --mixed to print both java and native frames (mixed mode) --exe executable image name --core path to coredump --pid pid of process to attach ------------- Thus I think --locks and --mixed should be false by default. Thanks, Yasumasa On 2016/08/05 20:38, David Holmes wrote: > On 5/08/2016 8:55 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> Thank you for your comment. >> >> For not to break current behavior, I think we should not change c'tor of >> JStack. >> I uploaded new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.01/ >> >> David, is it okay? > > It is a better fix in my opinion but still changes the behaviour of jhsdb - or is that not an issue? Is jhsdb new with 9? > > Thanks, > David > >> Dmitry, could you review again? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/08/05 14:49, David Holmes wrote: >>> On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request is related to [1]. >>>> >>>> "jhsdb jstack" should work as normal mode without being added --mixed >>>> option. >>>> However, this command always works as mixed mode. >>> >>> So it seems to me the JStack class has a very poorly designed API and >>> command-line interface. It appears that jstack wants to default to >>> mixedMode and concurrentLocks, but provides no means to disable those >>> defaults. Given there is no way to turn those settings off from the >>> commad-line then the default should be that they are off! Then you >>> would not need current proposed change. >>> >>> That said the proposed fix effectively disables those defaults, which >>> seems to me to be a change in behaviour. >>> >>> I can't see a way to fix this without breaking existing behaviour >>> somewhere. In which case I would change the way the JStack instance is >>> initialized by default ie: >>> >>> public JStack() { >>> this(true, true); >>> } >>> >>> becomes: >>> >>> public JStack() { >>> this(false, false); >>> } >>> >>> Or it may be better to handle this on the jhsdb side and change this: >>> >>> JStack.main(newArgs.toArray(new String[newArgs.size()])); >>> to >>> >>> JStack js = new jstack(false,false); >>> js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); >>> >>> >>> Cheers, >>> David >>> >>>> So I uploaded webrev for this issue. Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ >>>> >>>> >>>> I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html >>>> >>>> From dmitry.samersoff at oracle.com Fri Aug 5 11:51:44 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 5 Aug 2016 14:51:44 +0300 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: References: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> Message-ID: <8dc749d7-f9a7-0d79-2312-9ef4f9c6abd9@oracle.com> David, > jhsdb - or is that not an issue? Is jhsdb new with 9? jhsdb is new for jdk9 and we can lift it's behavior as necessary. Personally, I'm for adding --no-mixed and leave default to mixed (making --mixed NOP), because mixed is the most common usecase. But I'm OK with a simple fix that restores original jstack behavior. -Dmitry On 2016-08-05 14:38, David Holmes wrote: > On 5/08/2016 8:55 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> Thank you for your comment. >> >> For not to break current behavior, I think we should not change c'tor of >> JStack. >> I uploaded new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.01/ >> >> David, is it okay? > > It is a better fix in my opinion but still changes the behaviour of > jhsdb - or is that not an issue? Is jhsdb new with 9? > > Thanks, > David > >> Dmitry, could you review again? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/08/05 14:49, David Holmes wrote: >>> On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request is related to [1]. >>>> >>>> "jhsdb jstack" should work as normal mode without being added --mixed >>>> option. >>>> However, this command always works as mixed mode. >>> >>> So it seems to me the JStack class has a very poorly designed API and >>> command-line interface. It appears that jstack wants to default to >>> mixedMode and concurrentLocks, but provides no means to disable those >>> defaults. Given there is no way to turn those settings off from the >>> commad-line then the default should be that they are off! Then you >>> would not need current proposed change. >>> >>> That said the proposed fix effectively disables those defaults, which >>> seems to me to be a change in behaviour. >>> >>> I can't see a way to fix this without breaking existing behaviour >>> somewhere. In which case I would change the way the JStack instance is >>> initialized by default ie: >>> >>> public JStack() { >>> this(true, true); >>> } >>> >>> becomes: >>> >>> public JStack() { >>> this(false, false); >>> } >>> >>> Or it may be better to handle this on the jhsdb side and change this: >>> >>> JStack.main(newArgs.toArray(new String[newArgs.size()])); >>> to >>> >>> JStack js = new jstack(false,false); >>> js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); >>> >>> >>> Cheers, >>> David >>> >>>> So I uploaded webrev for this issue. Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ >>>> >>>> >>>> I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html >>>> >>>> >>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Fri Aug 5 11:59:40 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 5 Aug 2016 20:59:40 +0900 Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties Message-ID: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> Hi all, I tried to get system properties via "jhsdb jinfo". However, it did not work as below: ---------------- $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 Attaching to process ID 1002, please wait... Debugger attached successfully. Server compiler detected. JVM version is 9-ea+129 Java System Properties: java.lang.NullPointerException at sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hotspot.agent at 9-ea/ObjectReader.java:217) at sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hotspot.agent at 9-ea/ObjectReader.java:247) at sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspot.agent at 9-ea/ObjectReader.java:105) at sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9-ea/VM.java:940) at sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot.agent at 9-ea/InstanceKlass.java:872) at sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsInternal(jdk.hotspot.agent at 9-ea/InstanceKlass.java:572) at sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.hotspot.agent at 9-ea/InstanceKlass.java:560) at sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot.agent at 9-ea/VM.java:935) : System Properties info not available! ---------------- * If you want to see all stack, please see JBS. I think this is caused by JDK-8029891. JDK-8029891 changes that j.u.Properties stores properties to j.u.c.ConcurrentHashMap. ObjectReader should be adapted to this change. I uploaded webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ I'm jdk 9 commiter, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From jini.george at oracle.com Sat Aug 6 13:37:33 2016 From: jini.george at oracle.com (Jini Susan George) Date: Sat, 6 Aug 2016 06:37:33 -0700 (PDT) Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties In-Reply-To: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> References: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> Message-ID: <0d8df07d-da2b-4302-82fb-9d72f2e8bb0f@default> Hi Yasumasa, It would be great if you could modify jdk/test/sun/tools/jhsdb/BasicLauncherTest.java to test for this also as a part of your change. Thanks, Jini. (Not a Reviewer). > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: Friday, August 05, 2016 5:30 PM > To: serviceability-dev at openjdk.java.net > Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties > > Hi all, > > I tried to get system properties via "jhsdb jinfo". > However, it did not work as below: > > ---------------- > $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 > Attaching to process ID 1002, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 9-ea+129 > Java System Properties: > > java.lang.NullPointerException > at > sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hotspot.agent at 9- > ea/ObjectReader.java:217) > at > sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hotspot.agent at 9- > ea/ObjectReader.java:247) > at > sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspot.agent at 9- > ea/ObjectReader.java:105) > at sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9- > ea/VM.java:940) > at sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot.agent at 9- > ea/InstanceKlass.java:872) > at > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsInternal(jdk.hotspot.ag > ent at 9-ea/InstanceKlass.java:572) > at > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.hotspot.agent at 9- > ea/InstanceKlass.java:560) > at > sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot.agent at 9- > ea/VM.java:935) > : > System Properties info not available! > ---------------- > * If you want to see all stack, please see JBS. > > > I think this is caused by JDK-8029891. > JDK-8029891 changes that j.u.Properties stores properties to > j.u.c.ConcurrentHashMap. > ObjectReader should be adapted to this change. > > I uploaded webrev. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ > > I'm jdk 9 commiter, but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > From yasuenag at gmail.com Sat Aug 6 15:19:48 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 7 Aug 2016 00:19:48 +0900 Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties In-Reply-To: <0d8df07d-da2b-4302-82fb-9d72f2e8bb0f@default> References: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> <0d8df07d-da2b-4302-82fb-9d72f2e8bb0f@default> Message-ID: Hi Jini, I changed BasicLauncherTest#launch() to handle unexpected message. http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.01/jdk/ Does this change fit to your needs? Thanks, Yasumasa On 2016/08/06 22:37, Jini Susan George wrote: > Hi Yasumasa, > > It would be great if you could modify jdk/test/sun/tools/jhsdb/BasicLauncherTest.java to test for this also as a part of your change. > > Thanks, > Jini. (Not a Reviewer). > >> -----Original Message----- >> From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] >> Sent: Friday, August 05, 2016 5:30 PM >> To: serviceability-dev at openjdk.java.net >> Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties >> >> Hi all, >> >> I tried to get system properties via "jhsdb jinfo". >> However, it did not work as below: >> >> ---------------- >> $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 >> Attaching to process ID 1002, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 9-ea+129 >> Java System Properties: >> >> java.lang.NullPointerException >> at >> sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hotspot.agent at 9- >> ea/ObjectReader.java:217) >> at >> sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hotspot.agent at 9- >> ea/ObjectReader.java:247) >> at >> sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspot.agent at 9- >> ea/ObjectReader.java:105) >> at sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9- >> ea/VM.java:940) >> at sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot.agent at 9- >> ea/InstanceKlass.java:872) >> at >> sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsInternal(jdk.hotspot.ag >> ent at 9-ea/InstanceKlass.java:572) >> at >> sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.hotspot.agent at 9- >> ea/InstanceKlass.java:560) >> at >> sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot.agent at 9- >> ea/VM.java:935) >> : >> System Properties info not available! >> ---------------- >> * If you want to see all stack, please see JBS. >> >> >> I think this is caused by JDK-8029891. >> JDK-8029891 changes that j.u.Properties stores properties to >> j.u.c.ConcurrentHashMap. >> ObjectReader should be adapted to this change. >> >> I uploaded webrev. Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ >> >> I'm jdk 9 commiter, but I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> From david.holmes at oracle.com Sun Aug 7 23:52:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Aug 2016 09:52:42 +1000 Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties In-Reply-To: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> References: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> Message-ID: Hi Yasumasa, On 5/08/2016 9:59 PM, Yasumasa Suenaga wrote: > Hi all, > > I tried to get system properties via "jhsdb jinfo". > However, it did not work as below: > > ---------------- > $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 > Attaching to process ID 1002, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 9-ea+129 > Java System Properties: > > java.lang.NullPointerException > at > sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hotspot.agent at 9-ea/ObjectReader.java:217) > > at > sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hotspot.agent at 9-ea/ObjectReader.java:247) > > at > sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspot.agent at 9-ea/ObjectReader.java:105) > > at > sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9-ea/VM.java:940) > at > sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot.agent at 9-ea/InstanceKlass.java:872) > > at > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsInternal(jdk.hotspot.agent at 9-ea/InstanceKlass.java:572) > > at > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.hotspot.agent at 9-ea/InstanceKlass.java:560) > > at > sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot.agent at 9-ea/VM.java:935) > > : > System Properties info not available! > ---------------- > * If you want to see all stack, please see JBS. > > > I think this is caused by JDK-8029891. > JDK-8029891 changes that j.u.Properties stores properties to > j.u.c.ConcurrentHashMap. > ObjectReader should be adapted to this change. > > I uploaded webrev. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ I'm not very familiar with how SA operates here so this could be a stupid question, but why do we need to know exactly how Properties are implemented instead of just using the public API to access them and read/write them ?? Thanks, David > I'm jdk 9 commiter, but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > From yasuenag at gmail.com Mon Aug 8 00:26:58 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 8 Aug 2016 09:26:58 +0900 Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties In-Reply-To: References: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> Message-ID: Hi David, To get properties from memory, SA have to know memory layout. SA is used for attaching to live process/core image. So we cannot execute Java API. Thanks, Yasumasa 2016/08/08 8:52 "David Holmes" : > Hi Yasumasa, > > On 5/08/2016 9:59 PM, Yasumasa Suenaga wrote: > >> Hi all, >> >> I tried to get system properties via "jhsdb jinfo". >> However, it did not work as below: >> >> ---------------- >> $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 >> Attaching to process ID 1002, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 9-ea+129 >> Java System Properties: >> >> java.lang.NullPointerException >> at >> sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hots >> pot.agent at 9-ea/ObjectReader.java:217) >> >> at >> sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hots >> pot.agent at 9-ea/ObjectReader.java:247) >> >> at >> sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspot.agent at 9-ea >> /ObjectReader.java:105) >> >> at >> sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9-ea/VM.java:940) >> at >> sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot.agent at 9-ea >> /InstanceKlass.java:872) >> >> at >> sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsIntern >> al(jdk.hotspot.agent at 9-ea/InstanceKlass.java:572) >> >> at >> sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.h >> otspot.agent at 9-ea/InstanceKlass.java:560) >> >> at >> sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot.agent at 9-ea >> /VM.java:935) >> >> : >> System Properties info not available! >> ---------------- >> * If you want to see all stack, please see JBS. >> >> >> I think this is caused by JDK-8029891. >> JDK-8029891 changes that j.u.Properties stores properties to >> j.u.c.ConcurrentHashMap. >> ObjectReader should be adapted to this change. >> >> I uploaded webrev. Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ >> > > I'm not very familiar with how SA operates here so this could be a stupid > question, but why do we need to know exactly how Properties are implemented > instead of just using the public API to access them and read/write them ?? > > Thanks, > David > > I'm jdk 9 commiter, but I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Aug 8 00:59:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 Aug 2016 10:59:50 +1000 Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties In-Reply-To: References: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> Message-ID: <57eb72c0-8764-0516-280d-dc74ad39f268@oracle.com> On 8/08/2016 10:26 AM, Yasumasa Suenaga wrote: > Hi David, > > To get properties from memory, SA have to know memory layout. > SA is used for attaching to live process/core image. So we cannot > execute Java API. I see - so we have to read memory element by memory element. Okay - code seems okay. Thanks, David > Thanks, > > Yasumasa > > > 2016/08/08 8:52 "David Holmes" >: > > Hi Yasumasa, > > On 5/08/2016 9:59 PM, Yasumasa Suenaga wrote: > > Hi all, > > I tried to get system properties via "jhsdb jinfo". > However, it did not work as below: > > ---------------- > $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 > Attaching to process ID 1002, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 9-ea+129 > Java System Properties: > > java.lang.NullPointerException > at > sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hotspot.agent at 9-ea/ObjectReader.java:217) > > at > sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hotspot.agent at 9-ea/ObjectReader.java:247) > > at > sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspot.agent at 9-ea/ObjectReader.java:105) > > at > sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9-ea/VM.java:940) > at > sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot.agent at 9-ea/InstanceKlass.java:872) > > at > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsInternal(jdk.hotspot.agent at 9-ea/InstanceKlass.java:572) > > at > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.hotspot.agent at 9-ea/InstanceKlass.java:560) > > at > sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot.agent at 9-ea/VM.java:935) > > : > System Properties info not available! > ---------------- > * If you want to see all stack, please see JBS. > > > I think this is caused by JDK-8029891. > JDK-8029891 changes that j.u.Properties stores properties to > j.u.c.ConcurrentHashMap. > ObjectReader should be adapted to this change. > > I uploaded webrev. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ > > > > I'm not very familiar with how SA operates here so this could be a > stupid question, but why do we need to know exactly how Properties > are implemented instead of just using the public API to access them > and read/write them ?? > > Thanks, > David > > I'm jdk 9 commiter, but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > From yasuenag at gmail.com Mon Aug 8 02:05:22 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 8 Aug 2016 11:05:22 +0900 Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties In-Reply-To: <57eb72c0-8764-0516-280d-dc74ad39f268@oracle.com> References: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> <57eb72c0-8764-0516-280d-dc74ad39f268@oracle.com> Message-ID: Thanks David! I'm waiting a second reviewer and a sponsor. Yasumasa 2016/08/08 10:00 "David Holmes" : > On 8/08/2016 10:26 AM, Yasumasa Suenaga wrote: > >> Hi David, >> >> To get properties from memory, SA have to know memory layout. >> SA is used for attaching to live process/core image. So we cannot >> execute Java API. >> > > I see - so we have to read memory element by memory element. > > Okay - code seems okay. > > Thanks, > David > > Thanks, >> >> Yasumasa >> >> >> 2016/08/08 8:52 "David Holmes" > >: >> >> Hi Yasumasa, >> >> On 5/08/2016 9:59 PM, Yasumasa Suenaga wrote: >> >> Hi all, >> >> I tried to get system properties via "jhsdb jinfo". >> However, it did not work as below: >> >> ---------------- >> $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 >> Attaching to process ID 1002, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 9-ea+129 >> Java System Properties: >> >> java.lang.NullPointerException >> at >> sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hots >> pot.agent at 9-ea/ObjectReader.java:217) >> >> at >> sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hots >> pot.agent at 9-ea/ObjectReader.java:247) >> >> at >> sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspo >> t.agent at 9-ea/ObjectReader.java:105) >> >> at >> sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9-ea/VM >> .java:940) >> at >> sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot. >> agent at 9-ea/InstanceKlass.java:872) >> >> at >> sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsIntern >> al(jdk.hotspot.agent at 9-ea/InstanceKlass.java:572) >> >> at >> sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.h >> otspot.agent at 9-ea/InstanceKlass.java:560) >> >> at >> sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot. >> agent at 9-ea/VM.java:935) >> >> : >> System Properties info not available! >> ---------------- >> * If you want to see all stack, please see JBS. >> >> >> I think this is caused by JDK-8029891. >> JDK-8029891 changes that j.u.Properties stores properties to >> j.u.c.ConcurrentHashMap. >> ObjectReader should be adapted to this change. >> >> I uploaded webrev. Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ >> >> >> >> I'm not very familiar with how SA operates here so this could be a >> stupid question, but why do we need to know exactly how Properties >> are implemented instead of just using the public API to access them >> and read/write them ?? >> >> Thanks, >> David >> >> I'm jdk 9 commiter, but I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Mon Aug 8 04:38:41 2016 From: jini.george at oracle.com (Jini Susan George) Date: Sun, 7 Aug 2016 21:38:41 -0700 (PDT) Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties In-Reply-To: References: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> <0d8df07d-da2b-4302-82fb-9d72f2e8bb0f@default> Message-ID: <5d2a9fec-7605-48be-a538-33556e5498f2@default> Thank you, Yasumasa, for this. Your changes for the BasicLauncherTest.java modification look good. Nice that you also caught and corrected the fact that jstack was not getting launched. Regards, - Jini (Not a Reviewer). > -----Original Message----- > From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > Sent: Saturday, August 06, 2016 8:50 PM > To: Jini Susan George > Cc: serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8163272: jhsdb jinfo cannot show system properties > > Hi Jini, > > I changed BasicLauncherTest#launch() to handle unexpected message. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.01/jdk/ > > Does this change fit to your needs? > > > Thanks, > > Yasumasa > > > On 2016/08/06 22:37, Jini Susan George wrote: > > Hi Yasumasa, > > > > It would be great if you could modify > jdk/test/sun/tools/jhsdb/BasicLauncherTest.java to test for this also as a > part of your change. > > > > Thanks, > > Jini. (Not a Reviewer). > > > >> -----Original Message----- > >> From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] > >> Sent: Friday, August 05, 2016 5:30 PM > >> To: serviceability-dev at openjdk.java.net > >> Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties > >> > >> Hi all, > >> > >> I tried to get system properties via "jhsdb jinfo". > >> However, it did not work as below: > >> > >> ---------------- > >> $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 > >> Attaching to process ID 1002, please wait... > >> Debugger attached successfully. > >> Server compiler detected. > >> JVM version is 9-ea+129 > >> Java System Properties: > >> > >> java.lang.NullPointerException > >> at > >> > sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hotspot.agent at 9- > >> ea/ObjectReader.java:217) > >> at > >> > sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hotspot.agent at 9- > >> ea/ObjectReader.java:247) > >> at > >> sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspot.agent at 9- > >> ea/ObjectReader.java:105) > >> at sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9- > >> ea/VM.java:940) > >> at > sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot.agent at 9- > >> ea/InstanceKlass.java:872) > >> at > >> > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsInternal(jdk.hotspot.ag > >> ent at 9-ea/InstanceKlass.java:572) > >> at > >> > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.hotspot.agent at 9- > >> ea/InstanceKlass.java:560) > >> at > >> sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot.agent at 9- > >> ea/VM.java:935) > >> : > >> System Properties info not available! > >> ---------------- > >> * If you want to see all stack, please see JBS. > >> > >> > >> I think this is caused by JDK-8029891. > >> JDK-8029891 changes that j.u.Properties stores properties to > >> j.u.c.ConcurrentHashMap. > >> ObjectReader should be adapted to this change. > >> > >> I uploaded webrev. Could you review it? > >> > >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ > >> > >> I'm jdk 9 commiter, but I cannot access JPRT. > >> So I need a sponsor. > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> From sharath.ballal at oracle.com Mon Aug 8 09:37:50 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Mon, 8 Aug 2016 02:37:50 -0700 (PDT) Subject: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. Message-ID: Hello, Pls review the following fix for modifying the testcase jmap-hashcode/Test8028623.java to use LingeredApp. http://cr.openjdk.java.net/~sballal/8163346/webrev.00/ Link to bug: https://bugs.openjdk.java.net/browse/JDK-8163346 -Sharath Ballal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Mon Aug 8 11:05:21 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 8 Aug 2016 14:05:21 +0300 Subject: RFR: JDK-8163272: jhsdb jinfo cannot show system properties In-Reply-To: References: <8495e816-081a-5443-c775-49d67e02c5af@gmail.com> <57eb72c0-8764-0516-280d-dc74ad39f268@oracle.com> Message-ID: <83881750-afd3-c985-a4e2-46458f1fa23e@oracle.com> Yasumasa, The fix looks good for me. I'll sponsor the push. -Dmitry On 2016-08-08 05:05, Yasumasa Suenaga wrote: > Thanks David! > > I'm waiting a second reviewer and a sponsor. > > Yasumasa > > > 2016/08/08 10:00 "David Holmes" >: > > On 8/08/2016 10:26 AM, Yasumasa Suenaga wrote: > > Hi David, > > To get properties from memory, SA have to know memory layout. > SA is used for attaching to live process/core image. So we cannot > execute Java API. > > > I see - so we have to read memory element by memory element. > > Okay - code seems okay. > > Thanks, > David > > Thanks, > > Yasumasa > > > 2016/08/08 8:52 "David Holmes" > >>: > > Hi Yasumasa, > > On 5/08/2016 9:59 PM, Yasumasa Suenaga wrote: > > Hi all, > > I tried to get system properties via "jhsdb jinfo". > However, it did not work as below: > > ---------------- > $ /usr/local/jdk-9/bin/jhsdb jinfo --pid 1002 > Attaching to process ID 1002, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 9-ea+129 > Java System Properties: > > java.lang.NullPointerException > at > > sun.jvm.hotspot.utilities.ObjectReader.getHashtable(jdk.hotspot.agent at 9-ea/ObjectReader.java:217) > > at > > sun.jvm.hotspot.utilities.ObjectReader.readInstance(jdk.hotspot.agent at 9-ea/ObjectReader.java:247) > > at > > sun.jvm.hotspot.utilities.ObjectReader.readObject(jdk.hotspot.agent at 9-ea/ObjectReader.java:105) > > at > > sun.jvm.hotspot.runtime.VM$2.doOop(jdk.hotspot.agent at 9-ea/VM.java:940) > at > > sun.jvm.hotspot.oops.InstanceKlass.visitField(jdk.hotspot.agent at 9-ea/InstanceKlass.java:872) > > at > > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFieldsInternal(jdk.hotspot.agent at 9-ea/InstanceKlass.java:572) > > at > > sun.jvm.hotspot.oops.InstanceKlass.iterateStaticFields(jdk.hotspot.agent at 9-ea/InstanceKlass.java:560) > > at > > sun.jvm.hotspot.runtime.VM.readSystemProperties(jdk.hotspot.agent at 9-ea/VM.java:935) > > : > System Properties info not available! > ---------------- > * If you want to see all stack, please see JBS. > > > I think this is caused by JDK-8029891. > JDK-8029891 changes that j.u.Properties stores properties to > j.u.c.ConcurrentHashMap. > ObjectReader should be adapted to this change. > > I uploaded webrev. Could you review it? > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163272/webrev.00/ > > > > > > > I'm not very familiar with how SA operates here so this > could be a > stupid question, but why do we need to know exactly how > Properties > are implemented instead of just using the public API to > access them > and read/write them ?? > > Thanks, > David > > I'm jdk 9 commiter, but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Mon Aug 8 13:17:09 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 8 Aug 2016 22:17:09 +0900 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: References: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> Message-ID: <1381bfa3-3c3c-74d8-854f-b828019ed20c@gmail.com> Hi David, > It is a better fix in my opinion but still changes the behaviour of jhsdb - or is that not an issue? Is jhsdb new with 9? Can I list you as a reviewer? This change is agreed by Dmitry. So I think we can move forward it. Thanks, Yasumasa On 2016/08/05 20:38, David Holmes wrote: > On 5/08/2016 8:55 PM, Yasumasa Suenaga wrote: >> Hi David, >> >> Thank you for your comment. >> >> For not to break current behavior, I think we should not change c'tor of >> JStack. >> I uploaded new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.01/ >> >> David, is it okay? > > It is a better fix in my opinion but still changes the behaviour of jhsdb - or is that not an issue? Is jhsdb new with 9? > > Thanks, > David > >> Dmitry, could you review again? >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/08/05 14:49, David Holmes wrote: >>> On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This review request is related to [1]. >>>> >>>> "jhsdb jstack" should work as normal mode without being added --mixed >>>> option. >>>> However, this command always works as mixed mode. >>> >>> So it seems to me the JStack class has a very poorly designed API and >>> command-line interface. It appears that jstack wants to default to >>> mixedMode and concurrentLocks, but provides no means to disable those >>> defaults. Given there is no way to turn those settings off from the >>> commad-line then the default should be that they are off! Then you >>> would not need current proposed change. >>> >>> That said the proposed fix effectively disables those defaults, which >>> seems to me to be a change in behaviour. >>> >>> I can't see a way to fix this without breaking existing behaviour >>> somewhere. In which case I would change the way the JStack instance is >>> initialized by default ie: >>> >>> public JStack() { >>> this(true, true); >>> } >>> >>> becomes: >>> >>> public JStack() { >>> this(false, false); >>> } >>> >>> Or it may be better to handle this on the jhsdb side and change this: >>> >>> JStack.main(newArgs.toArray(new String[newArgs.size()])); >>> to >>> >>> JStack js = new jstack(false,false); >>> js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); >>> >>> >>> Cheers, >>> David >>> >>>> So I uploaded webrev for this issue. Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ >>>> >>>> >>>> I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html >>>> >>>> From volker.simonis at gmail.com Mon Aug 8 13:35:41 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Aug 2016 15:35:41 +0200 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> Message-ID: Hi David, looks good now. Thanks, Volker On Fri, Aug 5, 2016 at 4:28 AM, David Holmes wrote: > Hi Volker, > > Thanks for looking at this. > > On 5/08/2016 1:48 AM, Volker Simonis wrote: >> >> Hi David, >> >> thanks for doing this change on all platforms. >> The fix looks good. Maybe you can just extend the following comment with >> something like: >> >> // Note that the SR_lock plays no role in this suspend/resume protocol. >> // It is only used in SR_handler as a thread termination indicator if >> NULL. > > > Darn this code is confusing - too many "SR"'s :( I have added > > // Note that the SR_lock plays no role in this suspend/resume protocol, > // but is checked for NULL in SR_handler as a thread termination indicator. > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8159461/webrev.v2/ > > This also reminded me to follow up on why the Solaris SR_handler is > different and I found it is not actually installed as a direct signal > handler, but is called from the real signal handler if dealing with a > JavaThread or the VMThread. Consequently the Solaris version of the > SR_handler can not encounter this specific bug and so I have reverted the > changes to os_solaris.cpp > > Thanks, > David > > >> Regards, >> Volker >> >> On Wed, Aug 3, 2016 at 3:13 AM, David Holmes > > wrote: >> >> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ >> >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8159461 >> >> >> The suspend/resume signal (SR_signum) is never sent to a thread once >> it has started to terminate. On one platform (SuSE 12) we have seen >> what appears to be a "stuck" signal, which is only delivered when >> the terminating thread restores its original signal mask (as if >> pthread_sigmask makes the system realize there is a pending signal - >> we already check the signal was not blocked). At this point in the >> thread termination we have freed the osthread, so the the SR_handler >> would access deallocated memory. In debug builds we first hit an >> assertion that the current thread is a JavaThread or the VMThread - >> that assertion fails, even though it is a JavaThread, because we >> have already executed the ~JavaThread destructor and inside the >> ~Thread destructor we are a plain Thread not a JavaThread. >> >> The fix was to make a small adjustment to the thread termination >> process so that we delete the SR_lock before calling >> os::free_thread(). In the SR_handler() we can then use a NULL check >> of SR_lock() to indicate the thread has terminated and we return. >> >> While only seen on Linux I took the opportunity to apply the fix on >> all platforms and also cleaned up the code where we were using >> Thread::current() unsafely in a signal-handling context. >> >> Testing: regular tier 1 (JPRT) >> Kitchensink (in progress) >> >> As we can't readily reproduce the problem I tested this by having a >> terminating thread raise SR_signum directly from within the ~Thread >> destructor. >> >> Thanks, >> David >> >> > From harsha.wardhana.b at oracle.com Mon Aug 8 14:09:58 2016 From: harsha.wardhana.b at oracle.com (Harsha wardhana B) Date: Mon, 8 Aug 2016 19:39:58 +0530 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> Message-ID: <57A892B6.3010703@oracle.com> Gentle Reminder !! On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: > Hello All, > > Please review the below simple test fix for the issue, > > https://bugs.openjdk.java.net/browse/JDK-8151345 > > with webrev located at, > > http://cr.openjdk.java.net/~hb/8151345/webrev.00/ > > Regards > > Harsha > From leonid.mesnik at oracle.com Mon Aug 8 14:19:30 2016 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Mon, 8 Aug 2016 17:19:30 +0300 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: <57A892B6.3010703@oracle.com> References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> Message-ID: <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> Please use following alias for compiler tests (hotspot/test/compiler): hotspot-compiler-dev at openjdk.java.net Leonid On 08.08.2016 17:09, Harsha wardhana B wrote: > Gentle Reminder !! > > On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >> Hello All, >> >> Please review the below simple test fix for the issue, >> >> https://bugs.openjdk.java.net/browse/JDK-8151345 >> >> with webrev located at, >> >> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >> >> Regards >> >> Harsha >> > From daniel.daugherty at oracle.com Mon Aug 8 16:07:46 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 8 Aug 2016 10:07:46 -0600 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> Message-ID: On 8/4/16 8:28 PM, David Holmes wrote: > Hi Volker, > > Thanks for looking at this. > > On 5/08/2016 1:48 AM, Volker Simonis wrote: >> Hi David, >> >> thanks for doing this change on all platforms. >> The fix looks good. Maybe you can just extend the following comment with >> something like: >> >> // Note that the SR_lock plays no role in this suspend/resume >> protocol. >> // It is only used in SR_handler as a thread termination indicator if >> NULL. > > Darn this code is confusing - too many "SR"'s :( I have added > > // Note that the SR_lock plays no role in this suspend/resume protocol, > // but is checked for NULL in SR_handler as a thread termination > indicator. > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8159461/webrev.v2/ src/share/vm/runtime/thread.cpp L380: _SR_lock = NULL; I was expecting the _SR_lock to be freed and NULL'ed earlier based on the discussion in the bug report. Since the crashing assert() happens in a race between the JavaThread destructor the NULL'ing of the _SR_lock field, I was expecting the _SR_lock field to be dealt with as early as possible in the Thread destructor (or even earlier; see my last comment). src/os/linux/vm/os_linux.cpp L4010: // mask is changed as part of thread termination. Check the current thread grammar?: "Check the current" -> "Check that the current" L4015: if (thread->SR_lock() == NULL) L4016: return; style nit: multi-line if-statements require '{' and '}' Please add the braces or make this a single line if-statement. I would prefer the braces. :-) Isn't there still a window between the completion of the JavaThread destructor and where the Thread destructor sets _SR_lock = NULL? L4020: OSThread* osthread = thread->osthread(); Not your bug. This code assumes that osthread != NULL. Maybe it needs to be more robust. src/os/aix/vm/os_aix.cpp L2731: if (thread->SR_lock() == NULL) L2732: return; Same style nit. Same race. L2736: OSThread* osthread = thread->osthread(); Same robustness comment. src/os/bsd/vm/os_bsd.cpp L2759: if (thread->SR_lock() == NULL) L2760: return; Same style nit. Same race. L2764: OSThread* osthread = thread->osthread(); Same robustness comment. It has been a very long time since I've dealt with races in the suspend/resume code so I'm probably very rusty with this code. If the _SR_lock is only used by the JavaThread suspend/resume protocol, then we could consider free'ing and NULL'ing the field in the JavaThread destructor (as the last piece of work). That should eliminate the race that was being observed by the SR_handler() in this bug. It will open a very small race where is_Java_thread() can return true, the _SR_lock field is !NULL, but the _SR_lock has been deleted. Dan > > This also reminded me to follow up on why the Solaris SR_handler is > different and I found it is not actually installed as a direct signal > handler, but is called from the real signal handler if dealing with a > JavaThread or the VMThread. Consequently the Solaris version of the > SR_handler can not encounter this specific bug and so I have reverted > the changes to os_solaris.cpp > > Thanks, > David > > >> Regards, >> Volker >> >> On Wed, Aug 3, 2016 at 3:13 AM, David Holmes > > wrote: >> >> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ >> >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8159461 >> >> >> The suspend/resume signal (SR_signum) is never sent to a thread once >> it has started to terminate. On one platform (SuSE 12) we have seen >> what appears to be a "stuck" signal, which is only delivered when >> the terminating thread restores its original signal mask (as if >> pthread_sigmask makes the system realize there is a pending signal - >> we already check the signal was not blocked). At this point in the >> thread termination we have freed the osthread, so the the SR_handler >> would access deallocated memory. In debug builds we first hit an >> assertion that the current thread is a JavaThread or the VMThread - >> that assertion fails, even though it is a JavaThread, because we >> have already executed the ~JavaThread destructor and inside the >> ~Thread destructor we are a plain Thread not a JavaThread. >> >> The fix was to make a small adjustment to the thread termination >> process so that we delete the SR_lock before calling >> os::free_thread(). In the SR_handler() we can then use a NULL check >> of SR_lock() to indicate the thread has terminated and we return. >> >> While only seen on Linux I took the opportunity to apply the fix on >> all platforms and also cleaned up the code where we were using >> Thread::current() unsafely in a signal-handling context. >> >> Testing: regular tier 1 (JPRT) >> Kitchensink (in progress) >> >> As we can't readily reproduce the problem I tested this by having a >> terminating thread raise SR_signum directly from within the ~Thread >> destructor. >> >> Thanks, >> David >> >> From david.holmes at oracle.com Mon Aug 8 23:57:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Aug 2016 09:57:35 +1000 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> Message-ID: <047f996d-51b2-8993-6439-a32e6d5c7908@oracle.com> Hi Dan, Thanks for the review. On 9/08/2016 2:07 AM, Daniel D. Daugherty wrote: > On 8/4/16 8:28 PM, David Holmes wrote: >> Hi Volker, >> >> Thanks for looking at this. >> >> On 5/08/2016 1:48 AM, Volker Simonis wrote: >>> Hi David, >>> >>> thanks for doing this change on all platforms. >>> The fix looks good. Maybe you can just extend the following comment with >>> something like: >>> >>> // Note that the SR_lock plays no role in this suspend/resume >>> protocol. >>> // It is only used in SR_handler as a thread termination indicator if >>> NULL. >> >> Darn this code is confusing - too many "SR"'s :( I have added >> >> // Note that the SR_lock plays no role in this suspend/resume protocol, >> // but is checked for NULL in SR_handler as a thread termination >> indicator. >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8159461/webrev.v2/ > > src/share/vm/runtime/thread.cpp > L380: _SR_lock = NULL; > I was expecting the _SR_lock to be freed and NULL'ed earlier > based on the discussion in the bug report. Since the crashing > assert() happens in a race between the JavaThread destructor > the NULL'ing of the _SR_lock field, I was expecting the _SR_lock > field to be dealt with as early as possible in the Thread > destructor (or even earlier; see my last comment). I will respond after that comment. > src/os/linux/vm/os_linux.cpp > L4010: // mask is changed as part of thread termination. Check the > current thread > grammar?: "Check the current" -> "Check that the current" Will change. > L4015: if (thread->SR_lock() == NULL) > L4016: return; > style nit: multi-line if-statements require '{' and '}' > Please add the braces or make this a single line if-statement. > I would prefer the braces. :-) Will fix. > Isn't there still a window between the completion of the > JavaThread destructor and where the Thread destructor sets > _SR_lock = NULL? See below. > L4020: OSThread* osthread = thread->osthread(); > Not your bug. This code assumes that osthread != NULL. > Maybe it needs to be more robust. Depends what kind of impossibilities we want to guard against. :) There should be no possible way a signal can be sent to a thread that doesn't even have a osThread as it means we never successfully started/attached the thread. > src/os/aix/vm/os_aix.cpp > L2731: if (thread->SR_lock() == NULL) > L2732: return; > Same style nit. > > Same race. > > L2736: OSThread* osthread = thread->osthread(); > Same robustness comment. > > src/os/bsd/vm/os_bsd.cpp > L2759: if (thread->SR_lock() == NULL) > L2760: return; > Same style nit. > > Same race. > > L2764: OSThread* osthread = thread->osthread(); > Same robustness comment. > > It has been a very long time since I've dealt with races in the > suspend/resume code so I'm probably very rusty with this code. > If the _SR_lock is only used by the JavaThread suspend/resume > protocol, then we could consider free'ing and NULL'ing the field > in the JavaThread destructor (as the last piece of work). > > That should eliminate the race that was being observed by the > SR_handler() in this bug. It will open a very small race where > is_Java_thread() can return true, the _SR_lock field is !NULL, > but the _SR_lock has been deleted. Given that it should have been impossible to get into the SR_handler in the first place from this code I was trying to minimize the disruption to the existing logic. Moving the delete/NULLing to just before the call to os::free_thread() fixes the crashes that had been observed. I was not trying to make the entire destruction sequence safe wrt. the SR_handler. My major concern with deleting the SR_lock much earlier is the potential race condition that I have previously outlined in: https://bugs.openjdk.java.net/browse/JDK-8152849 where there is no protection against a target thread terminating. The sooner it terminates and deletes the SR_lock the more likely we may attempt to lock a deleted lock! Thanks, David > Dan > > >> >> This also reminded me to follow up on why the Solaris SR_handler is >> different and I found it is not actually installed as a direct signal >> handler, but is called from the real signal handler if dealing with a >> JavaThread or the VMThread. Consequently the Solaris version of the >> SR_handler can not encounter this specific bug and so I have reverted >> the changes to os_solaris.cpp >> >> Thanks, >> David >> >> >>> Regards, >>> Volker >>> >>> On Wed, Aug 3, 2016 at 3:13 AM, David Holmes >> > wrote: >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ >>> >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8159461 >>> >>> >>> The suspend/resume signal (SR_signum) is never sent to a thread once >>> it has started to terminate. On one platform (SuSE 12) we have seen >>> what appears to be a "stuck" signal, which is only delivered when >>> the terminating thread restores its original signal mask (as if >>> pthread_sigmask makes the system realize there is a pending signal - >>> we already check the signal was not blocked). At this point in the >>> thread termination we have freed the osthread, so the the SR_handler >>> would access deallocated memory. In debug builds we first hit an >>> assertion that the current thread is a JavaThread or the VMThread - >>> that assertion fails, even though it is a JavaThread, because we >>> have already executed the ~JavaThread destructor and inside the >>> ~Thread destructor we are a plain Thread not a JavaThread. >>> >>> The fix was to make a small adjustment to the thread termination >>> process so that we delete the SR_lock before calling >>> os::free_thread(). In the SR_handler() we can then use a NULL check >>> of SR_lock() to indicate the thread has terminated and we return. >>> >>> While only seen on Linux I took the opportunity to apply the fix on >>> all platforms and also cleaned up the code where we were using >>> Thread::current() unsafely in a signal-handling context. >>> >>> Testing: regular tier 1 (JPRT) >>> Kitchensink (in progress) >>> >>> As we can't readily reproduce the problem I tested this by having a >>> terminating thread raise SR_signum directly from within the ~Thread >>> destructor. >>> >>> Thanks, >>> David >>> >>> > From david.holmes at oracle.com Tue Aug 9 00:33:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Aug 2016 10:33:08 +1000 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> Message-ID: <026edff0-4e36-793c-4711-00a605435914@oracle.com> Thanks Volker! David On 8/08/2016 11:35 PM, Volker Simonis wrote: > Hi David, > > looks good now. > > Thanks, > Volker > > > On Fri, Aug 5, 2016 at 4:28 AM, David Holmes wrote: >> Hi Volker, >> >> Thanks for looking at this. >> >> On 5/08/2016 1:48 AM, Volker Simonis wrote: >>> >>> Hi David, >>> >>> thanks for doing this change on all platforms. >>> The fix looks good. Maybe you can just extend the following comment with >>> something like: >>> >>> // Note that the SR_lock plays no role in this suspend/resume protocol. >>> // It is only used in SR_handler as a thread termination indicator if >>> NULL. >> >> >> Darn this code is confusing - too many "SR"'s :( I have added >> >> // Note that the SR_lock plays no role in this suspend/resume protocol, >> // but is checked for NULL in SR_handler as a thread termination indicator. >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8159461/webrev.v2/ >> >> This also reminded me to follow up on why the Solaris SR_handler is >> different and I found it is not actually installed as a direct signal >> handler, but is called from the real signal handler if dealing with a >> JavaThread or the VMThread. Consequently the Solaris version of the >> SR_handler can not encounter this specific bug and so I have reverted the >> changes to os_solaris.cpp >> >> Thanks, >> David >> >> >>> Regards, >>> Volker >>> >>> On Wed, Aug 3, 2016 at 3:13 AM, David Holmes >> > wrote: >>> >>> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ >>> >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8159461 >>> >>> >>> The suspend/resume signal (SR_signum) is never sent to a thread once >>> it has started to terminate. On one platform (SuSE 12) we have seen >>> what appears to be a "stuck" signal, which is only delivered when >>> the terminating thread restores its original signal mask (as if >>> pthread_sigmask makes the system realize there is a pending signal - >>> we already check the signal was not blocked). At this point in the >>> thread termination we have freed the osthread, so the the SR_handler >>> would access deallocated memory. In debug builds we first hit an >>> assertion that the current thread is a JavaThread or the VMThread - >>> that assertion fails, even though it is a JavaThread, because we >>> have already executed the ~JavaThread destructor and inside the >>> ~Thread destructor we are a plain Thread not a JavaThread. >>> >>> The fix was to make a small adjustment to the thread termination >>> process so that we delete the SR_lock before calling >>> os::free_thread(). In the SR_handler() we can then use a NULL check >>> of SR_lock() to indicate the thread has terminated and we return. >>> >>> While only seen on Linux I took the opportunity to apply the fix on >>> all platforms and also cleaned up the code where we were using >>> Thread::current() unsafely in a signal-handling context. >>> >>> Testing: regular tier 1 (JPRT) >>> Kitchensink (in progress) >>> >>> As we can't readily reproduce the problem I tested this by having a >>> terminating thread raise SR_signum directly from within the ~Thread >>> destructor. >>> >>> Thanks, >>> David >>> >>> >> From david.holmes at oracle.com Tue Aug 9 01:01:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Aug 2016 11:01:12 +1000 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: <1381bfa3-3c3c-74d8-854f-b828019ed20c@gmail.com> References: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> <1381bfa3-3c3c-74d8-854f-b828019ed20c@gmail.com> Message-ID: On 8/08/2016 11:17 PM, Yasumasa Suenaga wrote: > Hi David, > >> It is a better fix in my opinion but still changes the behaviour of >> jhsdb - or is that not an issue? Is jhsdb new with 9? > > Can I list you as a reviewer? > This change is agreed by Dmitry. So I think we can move forward it. Yes to both. :) Thanks, David > > Thanks, > > Yasumasa > > > On 2016/08/05 20:38, David Holmes wrote: >> On 5/08/2016 8:55 PM, Yasumasa Suenaga wrote: >>> Hi David, >>> >>> Thank you for your comment. >>> >>> For not to break current behavior, I think we should not change c'tor of >>> JStack. >>> I uploaded new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.01/ >>> >>> David, is it okay? >> >> It is a better fix in my opinion but still changes the behaviour of >> jhsdb - or is that not an issue? Is jhsdb new with 9? >> >> Thanks, >> David >> >>> Dmitry, could you review again? >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/08/05 14:49, David Holmes wrote: >>>> On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This review request is related to [1]. >>>>> >>>>> "jhsdb jstack" should work as normal mode without being added --mixed >>>>> option. >>>>> However, this command always works as mixed mode. >>>> >>>> So it seems to me the JStack class has a very poorly designed API and >>>> command-line interface. It appears that jstack wants to default to >>>> mixedMode and concurrentLocks, but provides no means to disable those >>>> defaults. Given there is no way to turn those settings off from the >>>> commad-line then the default should be that they are off! Then you >>>> would not need current proposed change. >>>> >>>> That said the proposed fix effectively disables those defaults, which >>>> seems to me to be a change in behaviour. >>>> >>>> I can't see a way to fix this without breaking existing behaviour >>>> somewhere. In which case I would change the way the JStack instance is >>>> initialized by default ie: >>>> >>>> public JStack() { >>>> this(true, true); >>>> } >>>> >>>> becomes: >>>> >>>> public JStack() { >>>> this(false, false); >>>> } >>>> >>>> Or it may be better to handle this on the jhsdb side and change this: >>>> >>>> JStack.main(newArgs.toArray(new String[newArgs.size()])); >>>> to >>>> >>>> JStack js = new jstack(false,false); >>>> js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); >>>> >>>> >>>> Cheers, >>>> David >>>> >>>>> So I uploaded webrev for this issue. Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ >>>>> >>>>> >>>>> I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. >>>>> So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html >>>>> >>>>> >>>>> From dmitry.samersoff at oracle.com Tue Aug 9 06:49:56 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 9 Aug 2016 09:49:56 +0300 Subject: RFR: JDK-8163185: jhsdb jstack cannot work with normal mode In-Reply-To: References: <0929959a-e792-ea01-3eac-2f514fbd07bf@gmail.com> <1381bfa3-3c3c-74d8-854f-b828019ed20c@gmail.com> Message-ID: <5f49b75d-4cdd-aa6d-9133-c3a60da34fea@oracle.com> Yasumasa, I'll sponsor the push. -Dmitry On 2016-08-09 04:01, David Holmes wrote: > On 8/08/2016 11:17 PM, Yasumasa Suenaga wrote: >> Hi David, >> >>> It is a better fix in my opinion but still changes the behaviour of >>> jhsdb - or is that not an issue? Is jhsdb new with 9? >> >> Can I list you as a reviewer? >> This change is agreed by Dmitry. So I think we can move forward it. > > Yes to both. :) > > Thanks, > David > >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/08/05 20:38, David Holmes wrote: >>> On 5/08/2016 8:55 PM, Yasumasa Suenaga wrote: >>>> Hi David, >>>> >>>> Thank you for your comment. >>>> >>>> For not to break current behavior, I think we should not change >>>> c'tor of >>>> JStack. >>>> I uploaded new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.01/ >>>> >>>> David, is it okay? >>> >>> It is a better fix in my opinion but still changes the behaviour of >>> jhsdb - or is that not an issue? Is jhsdb new with 9? >>> >>> Thanks, >>> David >>> >>>> Dmitry, could you review again? >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/08/05 14:49, David Holmes wrote: >>>>> On 5/08/2016 12:24 AM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> This review request is related to [1]. >>>>>> >>>>>> "jhsdb jstack" should work as normal mode without being added --mixed >>>>>> option. >>>>>> However, this command always works as mixed mode. >>>>> >>>>> So it seems to me the JStack class has a very poorly designed API and >>>>> command-line interface. It appears that jstack wants to default to >>>>> mixedMode and concurrentLocks, but provides no means to disable those >>>>> defaults. Given there is no way to turn those settings off from the >>>>> commad-line then the default should be that they are off! Then you >>>>> would not need current proposed change. >>>>> >>>>> That said the proposed fix effectively disables those defaults, which >>>>> seems to me to be a change in behaviour. >>>>> >>>>> I can't see a way to fix this without breaking existing behaviour >>>>> somewhere. In which case I would change the way the JStack instance is >>>>> initialized by default ie: >>>>> >>>>> public JStack() { >>>>> this(true, true); >>>>> } >>>>> >>>>> becomes: >>>>> >>>>> public JStack() { >>>>> this(false, false); >>>>> } >>>>> >>>>> Or it may be better to handle this on the jhsdb side and change this: >>>>> >>>>> JStack.main(newArgs.toArray(new String[newArgs.size()])); >>>>> to >>>>> >>>>> JStack js = new jstack(false,false); >>>>> js.runWithArgs(newArgs.toArray(new String[newArgs.size()])); >>>>> >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> So I uploaded webrev for this issue. Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163185/webrev.00/ >>>>>> >>>>>> >>>>>> I'm jdk 9 reviewer (ysuenaga), but I cannot access JPRT. >>>>>> So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-August/020087.html >>>>>> >>>>>> >>>>>> >>>>>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Tue Aug 9 09:53:01 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 9 Aug 2016 10:53:01 +0100 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues In-Reply-To: References: Message-ID: Hi John, JDK-8061177 [1] has been resolved as a duplicate of JDK-8065756 [2] which is still open. The correct action for this one might be to leave the test in the problem list but change the bug ID. The rest looks good to me - even though two of these test have been fixed by either adding diagnosis information or fixed as 'Cannot Reproduce'. Since most of these tests are in the serviceability area however, it might be good to get someone from serviceability-dev (added in cc:) to confirm whether they want to get these out of the problem list. best regards, [1] https://bugs.openjdk.java.net/browse/JDK-8061177 [2] https://bugs.openjdk.java.net/browse/JDK-8065756 -- daniel On 09/08/16 09:34, John Jiang wrote: > Hi, > The below issues have been closed, > JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, > JDK-8031555 > but the associated items still be contained by ProblemList.txt. This > small patch removes them. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 > Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 > > Best regards, > John Jiang > From alexander.kulyakhtin at oracle.com Tue Aug 9 11:28:38 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 9 Aug 2016 04:28:38 -0700 (PDT) Subject: RFR:8139368:-javaagent and -Dcom.sun.management need to add to the initial set of modules to resolve Message-ID: <6d7a7e6b-bf7c-4195-921b-78b4699835c3@default> Hi, Could you, please, review this test-only change (adding a new test). CR: https://bugs.openjdk.java.net/browse/JDK-8139368 "-javaagent and -Dcom.sun.management need to add to the initial set of modules to resolve" Webrev: http://cr.openjdk.java.net/~akulyakh/8139368_01/ The new tests starts java with the -javaagent option at the same time limiting the initial modules not to include the java.instrument module. The test then verifies that java starts successfully and that both the agent and the application produce the expected output. The other part of the CR, related to the -Dcom.sun.management, is not addressed by this fix as it is being addressed by a separate CR JDK-8131061 Best regards, Alexander From mallikarjuna.avaluri at oracle.com Tue Aug 9 05:41:13 2016 From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri) Date: Tue, 9 Aug 2016 11:11:13 +0530 Subject: RFR 8160913: [TEST_BUG] javax/management/security/SecurityTest.java fails due to missing keyStore file Message-ID: Hi all, Could you please review fix for following issue. Bug id: https://bugs.openjdk.java.net/browse/JDK-8160913 Summary: [TEST_BUG] javax/management/security/SecurityTest.java fails due to missing keyStore file Solution: Following files keystoreAgent, keystoreClient, truststoreAgent and truststoreClient were created under jdk/test/javax/management/ folder, while test expects them under jdk/test/javax/management/security/ path. Moved the files to correct folder. Webrev: http://cr.openjdk.java.net/~bgopularam/mavaluri/rev/8160913/webrev.00/ Thanks, Mallikarjuna Avaluri From sha.jiang at oracle.com Tue Aug 9 13:17:39 2016 From: sha.jiang at oracle.com (John Jiang) Date: Tue, 9 Aug 2016 21:17:39 +0800 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues In-Reply-To: References: Message-ID: <80776127-be7e-95a2-87b6-e590478f5660@oracle.com> Hi Daniel, Thanks for your review! Please take a look at this updated webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.01/ Best regards, John Jiang On 2016/8/9 17:53, Daniel Fuchs wrote: > Hi John, > > JDK-8061177 [1] has been resolved as a duplicate of > JDK-8065756 [2] which is still open. > The correct action for this one might be to leave the > test in the problem list but change the bug ID. > > The rest looks good to me - even though > two of these test have been fixed by either adding > diagnosis information or fixed as 'Cannot Reproduce'. > > Since most of these tests are in the serviceability > area however, it might be good to get someone from > serviceability-dev (added in cc:) to confirm whether > they want to get these out of the problem list. > > best regards, > > [1] https://bugs.openjdk.java.net/browse/JDK-8061177 > [2] https://bugs.openjdk.java.net/browse/JDK-8065756 > > -- daniel > > On 09/08/16 09:34, John Jiang wrote: >> Hi, >> The below issues have been closed, >> JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, >> JDK-8031555 >> but the associated items still be contained by ProblemList.txt. This >> small patch removes them. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 >> Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 >> >> Best regards, >> John Jiang >> > > From jini.george at oracle.com Wed Aug 10 07:10:35 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 10 Aug 2016 00:10:35 -0700 (PDT) Subject: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames Message-ID: Hi all, Please do review the changes for the SA defect: https://bugs.openjdk.java.net/browse/JDK-8163143 The webrev is at: http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.00/ Need testing with PPC64 for this. I have implemented the changes but have not tested on PPC64. Thank you, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Wed Aug 10 07:45:34 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 10 Aug 2016 10:45:34 +0300 Subject: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. In-Reply-To: References: Message-ID: <8ad9f953-205a-c331-e642-46016eefc740@oracle.com> Sharath, As soon as you request a heap dump of LingeredApp, LingeredApp should contains the object with extended characters in it's name. So please: 1. Inherit LingeredApp (See LingeredAppWithDeadlock as an example) and add public static int \u00CB = 1; 2. Copy BasicLauncherTest to HeapDumpWitExtCharsTest.java and change it according to you needs (i.e. remove everything but heapDumpTest) 3. Remove Test8028623.java -Dmitry On 2016-08-08 12:37, Sharath Ballal wrote: > Hello, > > Pls review the following fix for modifying the testcase > jmap-hashcode/Test8028623.java to use LingeredApp. > > > > http://cr.openjdk.java.net/~sballal/8163346/webrev.00/ > > > > Link to bug: https://bugs.openjdk.java.net/browse/JDK-8163346 > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Aug 10 08:12:23 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 10 Aug 2016 11:12:23 +0300 Subject: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames In-Reply-To: References: Message-ID: Jini, Code changes looks good for me. CC'in Goetz for PPC changes. BasicLauncherTest.java: I'm not sure we need two extra parameters to launch() just to check for jstack Assertion Failure. Please either create a separate launchJStack method or just check exit code of jhsdb jstack. -Dmitry On 2016-08-10 10:10, Jini Susan George wrote: > Hi all, > > > > Please do review the changes for the SA defect: > > > > https://bugs.openjdk.java.net/browse/JDK-8163143 > > > > The webrev is at: > > > > http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.00/ > > > > Need testing with PPC64 for this. I have implemented the changes but > have not tested on PPC64. > > > > Thank you, > > - Jini Susan George > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From amit.sapre at oracle.com Wed Aug 10 10:46:59 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 10 Aug 2016 03:46:59 -0700 (PDT) Subject: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly In-Reply-To: <0607b181-0227-bb91-4b71-f141ae1798c9@oracle.com> References: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> <0607b181-0227-bb91-4b71-f141ae1798c9@oracle.com> Message-ID: Hello, Well for some reason, unknown to me, JNI code checker is not complaining for exception thrown by SetObjectArrayElement. It complains for any pending exceptions before calling SetObjectArrayElement. I have added exceptions checks after calling SetObjectArrayElement. The updated changes are in this webrev. http://cr.openjdk.java.net/~sballal/sponsorship/8162530/webrev.02/ Thanks, Amit -----Original Message----- From: David Holmes Sent: Wednesday, August 03, 2016 5:50 AM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly Hi Amit, On 2/08/2016 7:49 PM, Amit Sapre wrote: > Hello, > I have made changes as David suggested. > > Here is the new webrev link. > http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ If the changes are required to pass a JNI code checker then you will also need to check for exceptions from SetObjectArrayElement. While ArrayStoreException should not be possible in this code, I can't tell for certain that the passed in arrays are ensured to have the required lengths. Thanks, David > Thanks, > Amit > > -----Original Message----- > From: David Holmes > Sent: Monday, August 01, 2016 12:33 PM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8162530 : > src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c > doesn't handle JNI exceptions properly > > Hi Amit, > > On 1/08/2016 4:10 PM, Amit Sapre wrote: >> Hello, >> >> >> >> Please review JNI exception handling related changes. >> >> Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 >> >> Webrev : >> http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ > > Sorry but that's wrong way to fix this. We should never just blindly clear exceptions and continue as if they never happened. If an exception is pending after one of these JNI calls the method should return immediately and allow the exception to propagate to the java code. > > Thanks, > David > >> >> >> Thanks, >> >> Amit >> From yasuenag at gmail.com Wed Aug 10 12:18:50 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 10 Aug 2016 21:18:50 +0900 Subject: RFR: JDK-8163580: Cannot get Monitor Cache Dump in HSDB Message-ID: <9a210c08-bc27-9fc1-0c81-237942c01652@gmail.com> Hi all, When I chose "Monitor Cache Dump" menu in HSDB, I saw an Exception as below: ------------ Exception in thread "AWT-EventQueue-0" java.lang.ExceptionInInitializerError at sun.jvm.hotspot.ui.MonitorCacheDumpPanel.dumpOn(jdk.hotspot.agent at 9-internal/MonitorCacheDumpPanel.java:92) at sun.jvm.hotspot.ui.MonitorCacheDumpPanel.(jdk.hotspot.agent at 9-internal/MonitorCacheDumpPanel.java:59) at sun.jvm.hotspot.HSDB.showMonitorCacheDumpPanel(jdk.hotspot.agent at 9-internal/HSDB.java:1534) : Caused by: java.lang.ArithmeticException: / by zero at sun.jvm.hotspot.runtime.ObjectSynchronizer.initialize(jdk.hotspot.agent at 9-internal/ObjectSynchronizer.java:55) : ------------ ObjectSynchronizer finds DEFAULT_CACHE_LINE_SIZE value from VMStructs, however, it is not contained. This value is added by JDK-8049737. DEFAULT_CACHE_LINE_SIZE is macro. When we set macro value to VMStructs, we have to use declare_preprocessor_constant macro. However this change uses declare_constant macro. It is the cause of this exception. I uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8163580/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From yasuenag at gmail.com Wed Aug 10 12:20:38 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 10 Aug 2016 21:20:38 +0900 Subject: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap Message-ID: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> Hi all, When I chose "Heap Parameters" menu in HSDB, I got following value: -------------------- Heap Parameters: unknown subtype of CollectedHeap @ 0x00007f4d4c030510 (0x00000006c6e00000,0x00000007c0000000) -------------------- I think it should not be "unknown subtype". This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). This method is overrided in ParallelScavengeHeap and GenCollectedHeap. However, G1CollectedHeap does not override. I think G1CollectedHeap should override this method. I uploaded a webrev for this issue. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ I'm jdk 9 committer, but I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From david.holmes at oracle.com Thu Aug 11 00:24:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Aug 2016 10:24:38 +1000 Subject: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly In-Reply-To: References: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> <0607b181-0227-bb91-4b71-f141ae1798c9@oracle.com> Message-ID: On 10/08/2016 8:46 PM, Amit Sapre wrote: > Hello, > Well for some reason, unknown to me, JNI code checker is not complaining for > exception thrown by SetObjectArrayElement. It complains for any pending exceptions before calling SetObjectArrayElement. > > I have added exceptions checks after calling SetObjectArrayElement. The updated changes are in this webrev. > > http://cr.openjdk.java.net/~sballal/sponsorship/8162530/webrev.02/ This looks fine to me. Thanks, David > Thanks, > Amit > > > > -----Original Message----- > From: David Holmes > Sent: Wednesday, August 03, 2016 5:50 AM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly > > Hi Amit, > > On 2/08/2016 7:49 PM, Amit Sapre wrote: >> Hello, >> I have made changes as David suggested. >> >> Here is the new webrev link. >> http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ > > If the changes are required to pass a JNI code checker then you will also need to check for exceptions from SetObjectArrayElement. While ArrayStoreException should not be possible in this code, I can't tell for certain that the passed in arrays are ensured to have the required lengths. > > Thanks, > David > >> Thanks, >> Amit >> >> -----Original Message----- >> From: David Holmes >> Sent: Monday, August 01, 2016 12:33 PM >> To: Amit Sapre; serviceability-dev >> Subject: Re: RFR : JDK-8162530 : >> src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c >> doesn't handle JNI exceptions properly >> >> Hi Amit, >> >> On 1/08/2016 4:10 PM, Amit Sapre wrote: >>> Hello, >>> >>> >>> >>> Please review JNI exception handling related changes. >>> >>> Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 >>> >>> Webrev : >>> http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ >> >> Sorry but that's wrong way to fix this. We should never just blindly clear exceptions and continue as if they never happened. If an exception is pending after one of these JNI calls the method should return immediately and allow the exception to propagate to the java code. >> >> Thanks, >> David >> >>> >>> >>> Thanks, >>> >>> Amit >>> From david.holmes at oracle.com Thu Aug 11 00:59:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Aug 2016 10:59:21 +1000 Subject: RFR: JDK-8163580: Cannot get Monitor Cache Dump in HSDB In-Reply-To: <9a210c08-bc27-9fc1-0c81-237942c01652@gmail.com> References: <9a210c08-bc27-9fc1-0c81-237942c01652@gmail.com> Message-ID: <77ce3778-e367-92b0-c434-09efb9ebece4@oracle.com> Hi Yasumasa, On 10/08/2016 10:18 PM, Yasumasa Suenaga wrote: > Hi all, > > When I chose "Monitor Cache Dump" menu in HSDB, I saw an Exception as > below: > ------------ > Exception in thread "AWT-EventQueue-0" > java.lang.ExceptionInInitializerError > at > sun.jvm.hotspot.ui.MonitorCacheDumpPanel.dumpOn(jdk.hotspot.agent at 9-internal/MonitorCacheDumpPanel.java:92) > > at > sun.jvm.hotspot.ui.MonitorCacheDumpPanel.(jdk.hotspot.agent at 9-internal/MonitorCacheDumpPanel.java:59) > > at > sun.jvm.hotspot.HSDB.showMonitorCacheDumpPanel(jdk.hotspot.agent at 9-internal/HSDB.java:1534) > > : > Caused by: java.lang.ArithmeticException: / by zero > at > sun.jvm.hotspot.runtime.ObjectSynchronizer.initialize(jdk.hotspot.agent at 9-internal/ObjectSynchronizer.java:55) > > : > ------------ > > ObjectSynchronizer finds DEFAULT_CACHE_LINE_SIZE value from VMStructs, > however, it is not contained. > > This value is added by JDK-8049737. DEFAULT_CACHE_LINE_SIZE is macro. > When we set macro value to VMStructs, we have to use > declare_preprocessor_constant macro. However this change uses > declare_constant macro. It is the cause of this exception. > > I uploaded a webrev for this issue. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163580/webrev.00/ > > I'm jdk 9 committer, but I cannot access JPRT. > So I need a sponsor. I agree with your analysis and fix. I will sponsor this under the 'trivial change' rules. Thanks, David > > Thanks, > > Yasumasa > From david.holmes at oracle.com Thu Aug 11 04:32:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Aug 2016 14:32:46 +1000 Subject: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap In-Reply-To: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> References: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> Message-ID: <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> Hi Yasumasa, Adding in GC folk. I agree with the need to override the printOn method, but can't comment on the details of what you are actually printing. Thanks, David On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: > Hi all, > > When I chose "Heap Parameters" menu in HSDB, I got following value: > -------------------- > Heap Parameters: > unknown subtype of CollectedHeap @ 0x00007f4d4c030510 > (0x00000006c6e00000,0x00000007c0000000) > -------------------- > > I think it should not be "unknown subtype". > > This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). > This method is overrided in ParallelScavengeHeap and GenCollectedHeap. > However, G1CollectedHeap does not override. > > I think G1CollectedHeap should override this method. > > I uploaded a webrev for this issue. > Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ > > I'm jdk 9 committer, but I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > From jini.george at oracle.com Thu Aug 11 05:57:34 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 10 Aug 2016 22:57:34 -0700 (PDT) Subject: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames In-Reply-To: References: Message-ID: <768863ae-2cbe-4eed-96ed-5be9cbcc0044@default> Thank you very much, Dmitry for the review. I have created a new webrev with a launchJStack() method in BasicLauncherTest.java. The exit value is 0, despite the error -- so that does not help. Please do take a look at the modified webrev: http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.01/ Thanks, -Jini. > -----Original Message----- > From: Dmitry Samersoff > Sent: Wednesday, August 10, 2016 1:42 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net; Lindenmaier, > Goetz > Subject: Re: RFR: JDK-8163143: illegal bci error with interpreted frames in > SA due to mirror being stored in interpreted frames > > Jini, > > Code changes looks good for me. > > CC'in Goetz for PPC changes. > > > BasicLauncherTest.java: > > I'm not sure we need two extra parameters to launch() just to check for > jstack Assertion Failure. > > Please either create a separate launchJStack method or just check exit > code of jhsdb jstack. > > -Dmitry > > On 2016-08-10 10:10, Jini Susan George wrote: > > Hi all, > > > > > > > > Please do review the changes for the SA defect: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8163143 > > > > > > > > The webrev is at: > > > > > > > > http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.00/ > > > > > > > > Need testing with PPC64 for this. I have implemented the changes but > > have not tested on PPC64. > > > > > > > > Thank you, > > > > - Jini Susan George > > > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From sha.jiang at oracle.com Thu Aug 11 06:30:36 2016 From: sha.jiang at oracle.com (John Jiang) Date: Thu, 11 Aug 2016 14:30:36 +0800 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues In-Reply-To: <80776127-be7e-95a2-87b6-e590478f5660@oracle.com> References: <80776127-be7e-95a2-87b6-e590478f5660@oracle.com> Message-ID: Hi, Please review another updated webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.02/ com/sun/jdi/JdbMethodExitTest.sh 8031555 generic-all The above line shouldn't be removed, and 8031555 should be replaced by 6902121. Because JDK-8031555 is closed as a duplicate of JDK-6902121, which is still open. Best regards, John Jiang On 2016/8/9 21:17, John Jiang wrote: > Hi Daniel, > Thanks for your review! > > Please take a look at this updated webrev: > http://cr.openjdk.java.net/~jjiang/8160611/webrev.01/ > > Best regards, > John Jiang > > > On 2016/8/9 17:53, Daniel Fuchs wrote: >> Hi John, >> >> JDK-8061177 [1] has been resolved as a duplicate of >> JDK-8065756 [2] which is still open. >> The correct action for this one might be to leave the >> test in the problem list but change the bug ID. >> >> The rest looks good to me - even though >> two of these test have been fixed by either adding >> diagnosis information or fixed as 'Cannot Reproduce'. >> >> Since most of these tests are in the serviceability >> area however, it might be good to get someone from >> serviceability-dev (added in cc:) to confirm whether >> they want to get these out of the problem list. >> >> best regards, >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8061177 >> [2] https://bugs.openjdk.java.net/browse/JDK-8065756 >> >> -- daniel >> >> On 09/08/16 09:34, John Jiang wrote: >>> Hi, >>> The below issues have been closed, >>> JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, >>> JDK-8031555 >>> but the associated items still be contained by ProblemList.txt. This >>> small patch removes them. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 >>> Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 >>> >>> Best regards, >>> John Jiang >>> >> >> > > From harsha.wardhana.b at oracle.com Thu Aug 11 06:32:55 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 11 Aug 2016 12:02:55 +0530 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> Message-ID: Hello, Could one of you please review the below fix? Thanks Harsha On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: > Please use following alias for compiler tests (hotspot/test/compiler): > > hotspot-compiler-dev at openjdk.java.net > > Leonid > > > On 08.08.2016 17:09, Harsha wardhana B wrote: >> Gentle Reminder !! >> >> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>> Hello All, >>> >>> Please review the below simple test fix for the issue, >>> >>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>> >>> with webrev located at, >>> >>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>> >>> Regards >>> >>> Harsha >>> >> > From jini.george at oracle.com Thu Aug 11 06:33:53 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 10 Aug 2016 23:33:53 -0700 (PDT) Subject: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap In-Reply-To: <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> References: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> Message-ID: Thank you for this fix, Yasumasa. This issue was manifested through the 'universe' command in clhsdb also, and your change fixes that. It would be great if you could modify BasicLauncherTest.java to have some testing done for this also. Thank you, Jini (Not a Reviewer). > -----Original Message----- > From: David Holmes > Sent: Thursday, August 11, 2016 10:03 AM > To: Yasumasa Suenaga; serviceability-dev at openjdk.java.net; hotspot-gc- > dev at openjdk.java.net > Subject: Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle > G1CollectedHeap > > Hi Yasumasa, > > Adding in GC folk. > > I agree with the need to override the printOn method, but can't comment > on the details of what you are actually printing. > > Thanks, > David > > On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: > > Hi all, > > > > When I chose "Heap Parameters" menu in HSDB, I got following value: > > -------------------- > > Heap Parameters: > > unknown subtype of CollectedHeap @ 0x00007f4d4c030510 > > (0x00000006c6e00000,0x00000007c0000000) > > -------------------- > > > > I think it should not be "unknown subtype". > > > > This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). > > This method is overrided in ParallelScavengeHeap and GenCollectedHeap. > > However, G1CollectedHeap does not override. > > > > I think G1CollectedHeap should override this method. > > > > I uploaded a webrev for this issue. > > Could you review it? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ > > > > I'm jdk 9 committer, but I cannot access JPRT. > > So I need a sponsor. > > > > > > Thanks, > > > > Yasumasa > > From dmitry.samersoff at oracle.com Thu Aug 11 07:20:18 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Aug 2016 10:20:18 +0300 Subject: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames In-Reply-To: <768863ae-2cbe-4eed-96ed-5be9cbcc0044@default> References: <768863ae-2cbe-4eed-96ed-5be9cbcc0044@default> Message-ID: Jini, Looks good for me! -Dmitry On 2016-08-11 08:57, Jini Susan George wrote: > Thank you very much, Dmitry for the review. I have created a new webrev with a launchJStack() method in BasicLauncherTest.java. The exit value is 0, despite the error -- so that does not help. Please do take a look at the modified webrev: > > http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.01/ > > Thanks, > -Jini. > >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Wednesday, August 10, 2016 1:42 PM >> To: Jini Susan George; serviceability-dev at openjdk.java.net; Lindenmaier, >> Goetz >> Subject: Re: RFR: JDK-8163143: illegal bci error with interpreted frames in >> SA due to mirror being stored in interpreted frames >> >> Jini, >> >> Code changes looks good for me. >> >> CC'in Goetz for PPC changes. >> >> >> BasicLauncherTest.java: >> >> I'm not sure we need two extra parameters to launch() just to check for >> jstack Assertion Failure. >> >> Please either create a separate launchJStack method or just check exit >> code of jhsdb jstack. >> >> -Dmitry >> >> On 2016-08-10 10:10, Jini Susan George wrote: >>> Hi all, >>> >>> >>> >>> Please do review the changes for the SA defect: >>> >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8163143 >>> >>> >>> >>> The webrev is at: >>> >>> >>> >>> http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.00/ >>> >>> >>> >>> Need testing with PPC64 for this. I have implemented the changes but >>> have not tested on PPC64. >>> >>> >>> >>> Thank you, >>> >>> - Jini Susan George >>> >>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From jini.george at oracle.com Thu Aug 11 07:28:43 2016 From: jini.george at oracle.com (Jini Susan George) Date: Thu, 11 Aug 2016 00:28:43 -0700 (PDT) Subject: RFR: JDK-8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames In-Reply-To: References: <768863ae-2cbe-4eed-96ed-5be9cbcc0044@default> Message-ID: <802819aa-a446-435d-b414-572b3b5fc1a0@default> Thank you, Dmitry ! -jini > -----Original Message----- > From: Dmitry Samersoff > Sent: Thursday, August 11, 2016 12:50 PM > To: Jini Susan George; serviceability-dev at openjdk.java.net; Lindenmaier, > Goetz > Subject: Re: RFR: JDK-8163143: illegal bci error with interpreted frames in > SA due to mirror being stored in interpreted frames > > Jini, > > Looks good for me! > > -Dmitry > > > On 2016-08-11 08:57, Jini Susan George wrote: > > Thank you very much, Dmitry for the review. I have created a new webrev > with a launchJStack() method in BasicLauncherTest.java. The exit value is 0, > despite the error -- so that does not help. Please do take a look at the > modified webrev: > > > > http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.01/ > > > > Thanks, > > -Jini. > > > >> -----Original Message----- > >> From: Dmitry Samersoff > >> Sent: Wednesday, August 10, 2016 1:42 PM > >> To: Jini Susan George; serviceability-dev at openjdk.java.net; Lindenmaier, > >> Goetz > >> Subject: Re: RFR: JDK-8163143: illegal bci error with interpreted frames > in > >> SA due to mirror being stored in interpreted frames > >> > >> Jini, > >> > >> Code changes looks good for me. > >> > >> CC'in Goetz for PPC changes. > >> > >> > >> BasicLauncherTest.java: > >> > >> I'm not sure we need two extra parameters to launch() just to check for > >> jstack Assertion Failure. > >> > >> Please either create a separate launchJStack method or just check exit > >> code of jhsdb jstack. > >> > >> -Dmitry > >> > >> On 2016-08-10 10:10, Jini Susan George wrote: > >>> Hi all, > >>> > >>> > >>> > >>> Please do review the changes for the SA defect: > >>> > >>> > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8163143 > >>> > >>> > >>> > >>> The webrev is at: > >>> > >>> > >>> > >>> http://cr.openjdk.java.net/~sballal/sponsorship/8163143/webrev.00/ > >>> > >>> > >>> > >>> Need testing with PPC64 for this. I have implemented the changes but > >>> have not tested on PPC64. > >>> > >>> > >>> > >>> Thank you, > >>> > >>> - Jini Susan George > >>> > >>> > >>> > >> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From yasuenag at gmail.com Thu Aug 11 14:15:36 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 11 Aug 2016 23:15:36 +0900 Subject: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap In-Reply-To: References: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> Message-ID: Hi Jini, I added this check in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ Thanks, Yasumasa On 2016/08/11 15:33, Jini Susan George wrote: > Thank you for this fix, Yasumasa. This issue was manifested through the 'universe' command in clhsdb also, and your change fixes that. It would be great if you could modify BasicLauncherTest.java to have some testing done for this also. > > Thank you, > Jini (Not a Reviewer). > >> -----Original Message----- >> From: David Holmes >> Sent: Thursday, August 11, 2016 10:03 AM >> To: Yasumasa Suenaga; serviceability-dev at openjdk.java.net; hotspot-gc- >> dev at openjdk.java.net >> Subject: Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle >> G1CollectedHeap >> >> Hi Yasumasa, >> >> Adding in GC folk. >> >> I agree with the need to override the printOn method, but can't comment >> on the details of what you are actually printing. >> >> Thanks, >> David >> >> On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> When I chose "Heap Parameters" menu in HSDB, I got following value: >>> -------------------- >>> Heap Parameters: >>> unknown subtype of CollectedHeap @ 0x00007f4d4c030510 >>> (0x00000006c6e00000,0x00000007c0000000) >>> -------------------- >>> >>> I think it should not be "unknown subtype". >>> >>> This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). >>> This method is overrided in ParallelScavengeHeap and GenCollectedHeap. >>> However, G1CollectedHeap does not override. >>> >>> I think G1CollectedHeap should override this method. >>> >>> I uploaded a webrev for this issue. >>> Could you review it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ >>> >>> I'm jdk 9 committer, but I cannot access JPRT. >>> So I need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> From joe.darcy at oracle.com Thu Aug 11 16:05:40 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 11 Aug 2016 09:05:40 -0700 Subject: [9] RFR 8160611: Clean up ProblemList.txt for closed/resolved issues In-Reply-To: References: <80776127-be7e-95a2-87b6-e590478f5660@oracle.com> Message-ID: <87d2d0f4-62e4-a861-52ac-78ccb3433e17@oracle.com> Looks fine; thanks, -Joe On 8/10/2016 11:30 PM, John Jiang wrote: > Hi, > Please review another updated webrev: > http://cr.openjdk.java.net/~jjiang/8160611/webrev.02/ > > com/sun/jdi/JdbMethodExitTest.sh 8031555 generic-all > The above line shouldn't be removed, and 8031555 should be replaced by > 6902121. > Because JDK-8031555 is closed as a duplicate of JDK-6902121, which is > still open. > > Best regards, > John Jiang > > > On 2016/8/9 21:17, John Jiang wrote: >> Hi Daniel, >> Thanks for your review! >> >> Please take a look at this updated webrev: >> http://cr.openjdk.java.net/~jjiang/8160611/webrev.01/ >> >> Best regards, >> John Jiang >> >> >> On 2016/8/9 17:53, Daniel Fuchs wrote: >>> Hi John, >>> >>> JDK-8061177 [1] has been resolved as a duplicate of >>> JDK-8065756 [2] which is still open. >>> The correct action for this one might be to leave the >>> test in the problem list but change the bug ID. >>> >>> The rest looks good to me - even though >>> two of these test have been fixed by either adding >>> diagnosis information or fixed as 'Cannot Reproduce'. >>> >>> Since most of these tests are in the serviceability >>> area however, it might be good to get someone from >>> serviceability-dev (added in cc:) to confirm whether >>> they want to get these out of the problem list. >>> >>> best regards, >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8061177 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8065756 >>> >>> -- daniel >>> >>> On 09/08/16 09:34, John Jiang wrote: >>>> Hi, >>>> The below issues have been closed, >>>> JDK-8130339, JDK-8068645, JDK-8061177, JDK-8058616, JDK-8046285, >>>> JDK-8031555 >>>> but the associated items still be contained by ProblemList.txt. This >>>> small patch removes them. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8160611 >>>> Webrev: http://cr.openjdk.java.net/~jjiang/8160611/webrev.00 >>>> >>>> Best regards, >>>> John Jiang >>>> >>> >>> >> >> > From dmitry.samersoff at oracle.com Thu Aug 11 16:55:55 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 11 Aug 2016 19:55:55 +0300 Subject: RFR(S): JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file In-Reply-To: <1cf08a48-d7c0-1953-08ef-5d75f8225a3c@oracle.com> References: <1cf08a48-d7c0-1953-08ef-5d75f8225a3c@oracle.com> Message-ID: <9a8c4cdb-0389-5d0b-6b87-7167ed66c655@oracle.com> David, Please see updated webrev. http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ I didn't touch windows version because it quite different from *NIX one. -Dmitry On 2016-08-08 02:40, David Holmes wrote: > Hi Dmitry, > > On 5/08/2016 7:25 PM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review the fix: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.02/ >> >> Problem: >> Tests fail intermittently because it can't attach to child process, >> these attach failures is hard to debug because attach framework >> doesn't provide enough diagnostic information. >> >> Solution: >> >> a) Increase attach timeout >> b) Slightly change attach loop to save a bit of CPU power. >> c) Add some logging to attach listener. >> >> It's just a first step in this direction. Complete cleanup of attach >> code (remove LinuxThreads support and convert all printing to UL) is not >> a goal of this fix - I'll file a separate CR for it. > > I still think you need more logging now to aid in debugging these cases. > In particular we want to be able to verify that the path of the attach > file is what we expect in all cases ie whether we find the .attach_pid > file in cwd or whether we are looking in temp directory, and whether we > ultimately succeed or fail. > > Plus whatever you do now should be done consistently for all platforms. > > Thanks, > David > >> -Dmitry >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.daugherty at oracle.com Thu Aug 11 17:57:10 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Aug 2016 11:57:10 -0600 Subject: RFR(XXXS): 8163879 quarantine serviceability/sa/sadebugd/SADebugDTest.java since it hangs intermittently Message-ID: Greetings, I'm quarantining a test that hung in the 2016-08-09 and 2016-08-10 JDK9-hs nightlies: JDK-8163879 quarantine serviceability/sa/sadebugd/SADebugDTest.java since it hangs intermittently https://bugs.openjdk.java.net/browse/JDK-8163879 $ hg diff diff -r 14f97d7574bf test/serviceability/sa/sadebugd/SADebugDTest.java --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Mon Aug 08 15:53:02 2016 +0000 +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Thu Aug 11 10:48:52 2016 -0700 @@ -28,6 +28,7 @@ * @modules java.base/jdk.internal.misc * @library /test/lib/share/classes * + * @ignore 8163805 * @run main/othervm SADebugDTest */ import java.io.File; This change falls under the HotSpot Trivial Change rule so I'm looking for a single (R)eviewer. Thanks, in advance, for any comments, suggestions or questions! Dan From daniel.daugherty at oracle.com Thu Aug 11 19:27:30 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Aug 2016 13:27:30 -0600 Subject: RFR(XXXS): 8163879 quarantine serviceability/sa/sadebugd/SADebugDTest.java since it hangs intermittently In-Reply-To: References: Message-ID: <5d5989dc-9f3b-5c4c-cfb5-9b355899a8b2@oracle.com> Added back serviceability-dev at ... The "reply to list" option usually only replies to one of the lists when more than one is specified... One of the few cases where "reply to all" is useful... :-) Thanks Harold! Dan On 8/11/16 12:59 PM, harold seigel wrote: > Looks good! > > Harold > > > On 8/11/2016 1:57 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm quarantining a test that hung in the 2016-08-09 and >> 2016-08-10 JDK9-hs nightlies: >> >> JDK-8163879 quarantine serviceability/sa/sadebugd/SADebugDTest.java >> since it hangs intermittently >> https://bugs.openjdk.java.net/browse/JDK-8163879 >> >> >> $ hg diff >> diff -r 14f97d7574bf test/serviceability/sa/sadebugd/SADebugDTest.java >> --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Mon Aug 08 >> 15:53:02 2016 +0000 >> +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Thu Aug 11 >> 10:48:52 2016 -0700 >> @@ -28,6 +28,7 @@ >> * @modules java.base/jdk.internal.misc >> * @library /test/lib/share/classes >> * >> + * @ignore 8163805 >> * @run main/othervm SADebugDTest >> */ >> import java.io.File; >> >> >> This change falls under the HotSpot Trivial Change rule so I'm >> looking for a single (R)eviewer. >> >> Thanks, in advance, for any comments, suggestions or questions! >> >> Dan > From david.holmes at oracle.com Fri Aug 12 00:24:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Aug 2016 10:24:58 +1000 Subject: RFR(S): JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file In-Reply-To: <9a8c4cdb-0389-5d0b-6b87-7167ed66c655@oracle.com> References: <1cf08a48-d7c0-1953-08ef-5d75f8225a3c@oracle.com> <9a8c4cdb-0389-5d0b-6b87-7167ed66c655@oracle.com> Message-ID: <0e789ca0-bd59-08ee-e9a8-da0646f06780@oracle.com> Hi Dmitry, On 12/08/2016 2:55 AM, Dmitry Samersoff wrote: > David, > > Please see updated webrev. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ > > I didn't touch windows version because it quite different from *NIX one. Do we ever see failures on Windows? Is so we should add diagnostics there too even if they are different to *NIX. I would still like to see what file it is working with. We need some logging in here: bool AttachListener::is_init_trigger() { if (init_at_startup() || is_initialized()) { return false; // initialized at startup or already initialized } char fn[PATH_MAX+1]; sprintf(fn, ".attach_pid%d", os::current_process_id()); int ret; struct stat64 st; RESTARTABLE(::stat64(fn, &st), ret); if (ret == -1) { + log ("failed to find attach file: %s, trying alternate", fn) snprintf(fn, sizeof(fn), "%s/.attach_pid%d", os::get_temp_directory(), os::current_process_id()); RESTARTABLE(::stat64(fn, &st), ret); + if (ret == -1) { + log("failed to find attach file: %s", fn); + } } All failure paths need to show us what it was that failed. typos: trigerred -> triggered Thanks, David > -Dmitry > > On 2016-08-08 02:40, David Holmes wrote: >> Hi Dmitry, >> >> On 5/08/2016 7:25 PM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review the fix: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.02/ >>> >>> Problem: >>> Tests fail intermittently because it can't attach to child process, >>> these attach failures is hard to debug because attach framework >>> doesn't provide enough diagnostic information. >>> >>> Solution: >>> >>> a) Increase attach timeout >>> b) Slightly change attach loop to save a bit of CPU power. >>> c) Add some logging to attach listener. >>> >>> It's just a first step in this direction. Complete cleanup of attach >>> code (remove LinuxThreads support and convert all printing to UL) is not >>> a goal of this fix - I'll file a separate CR for it. >> >> I still think you need more logging now to aid in debugging these cases. >> In particular we want to be able to verify that the path of the attach >> file is what we expect in all cases ie whether we find the .attach_pid >> file in cwd or whether we are looking in temp directory, and whether we >> ultimately succeed or fail. >> >> Plus whatever you do now should be done consistently for all platforms. >> >> Thanks, >> David >> >>> -Dmitry >>> > > From daniel.daugherty at oracle.com Fri Aug 12 01:25:39 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 11 Aug 2016 19:25:39 -0600 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: <047f996d-51b2-8993-6439-a32e6d5c7908@oracle.com> References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> <047f996d-51b2-8993-6439-a32e6d5c7908@oracle.com> Message-ID: <82648eab-d84a-a112-2862-4f905ed772d4@oracle.com> David, Sorry I forgot to respond before I left for Santa Fe, NM... More below... On 8/8/16 5:57 PM, David Holmes wrote: > Hi Dan, > > Thanks for the review. > > On 9/08/2016 2:07 AM, Daniel D. Daugherty wrote: >> On 8/4/16 8:28 PM, David Holmes wrote: >>> Hi Volker, >>> >>> Thanks for looking at this. >>> >>> On 5/08/2016 1:48 AM, Volker Simonis wrote: >>>> Hi David, >>>> >>>> thanks for doing this change on all platforms. >>>> The fix looks good. Maybe you can just extend the following comment >>>> with >>>> something like: >>>> >>>> // Note that the SR_lock plays no role in this suspend/resume >>>> protocol. >>>> // It is only used in SR_handler as a thread termination >>>> indicator if >>>> NULL. >>> >>> Darn this code is confusing - too many "SR"'s :( I have added >>> >>> // Note that the SR_lock plays no role in this suspend/resume >>> protocol, >>> // but is checked for NULL in SR_handler as a thread termination >>> indicator. >>> >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/8159461/webrev.v2/ >> >> src/share/vm/runtime/thread.cpp >> L380: _SR_lock = NULL; >> I was expecting the _SR_lock to be freed and NULL'ed earlier >> based on the discussion in the bug report. Since the crashing >> assert() happens in a race between the JavaThread destructor >> the NULL'ing of the _SR_lock field, I was expecting the _SR_lock >> field to be dealt with as early as possible in the Thread >> destructor (or even earlier; see my last comment). > > I will respond after that comment. > >> src/os/linux/vm/os_linux.cpp >> L4010: // mask is changed as part of thread termination. Check the >> current thread >> grammar?: "Check the current" -> "Check that the current" > > Will change. > >> L4015: if (thread->SR_lock() == NULL) >> L4016: return; >> style nit: multi-line if-statements require '{' and '}' >> Please add the braces or make this a single line if-statement. >> I would prefer the braces. :-) > > Will fix. > >> Isn't there still a window between the completion of the >> JavaThread destructor and where the Thread destructor sets >> _SR_lock = NULL? > > See below. > >> L4020: OSThread* osthread = thread->osthread(); >> Not your bug. This code assumes that osthread != NULL. >> Maybe it needs to be more robust. > > Depends what kind of impossibilities we want to guard against. :) > There should be no possible way a signal can be sent to a thread that > doesn't even have a osThread as it means we never successfully > started/attached the thread. That's a really good point. I'm good with what's there for osthread. > >> src/os/aix/vm/os_aix.cpp >> L2731: if (thread->SR_lock() == NULL) >> L2732: return; >> Same style nit. >> >> Same race. >> >> L2736: OSThread* osthread = thread->osthread(); >> Same robustness comment. >> >> src/os/bsd/vm/os_bsd.cpp >> L2759: if (thread->SR_lock() == NULL) >> L2760: return; >> Same style nit. >> >> Same race. >> >> L2764: OSThread* osthread = thread->osthread(); >> Same robustness comment. >> >> It has been a very long time since I've dealt with races in the >> suspend/resume code so I'm probably very rusty with this code. >> If the _SR_lock is only used by the JavaThread suspend/resume >> protocol, then we could consider free'ing and NULL'ing the field >> in the JavaThread destructor (as the last piece of work). >> >> That should eliminate the race that was being observed by the >> SR_handler() in this bug. It will open a very small race where >> is_Java_thread() can return true, the _SR_lock field is !NULL, >> but the _SR_lock has been deleted. > > Given that it should have been impossible to get into the SR_handler > in the first place from this code I was trying to minimize the > disruption to the existing logic. Moving the delete/NULLing to just > before the call to os::free_thread() fixes the crashes that had been > observed. I was not trying to make the entire destruction sequence > safe wrt. the SR_handler. I suspect it is the combination of 1) NULLing the _SR_lock as a sentinel and 2) doing that before the more expensive os::free_thread() call that results in the change in behavior. > My major concern with deleting the SR_lock much earlier is the > potential race condition that I have previously outlined in: > > https://bugs.openjdk.java.net/browse/JDK-8152849 > > where there is no protection against a target thread terminating. The > sooner it terminates and deletes the SR_lock the more likely we may > attempt to lock a deleted lock! Ah yes... thanks for the reminder. We have seen a few of those in the past where we're racing to grab the _SR_lock and Elvis is trying to leave the building... I'm good with just the minor changes you agreed to make above. I don't think I need to see a new webrev for the above edits. Thumbs up! Dan > > Thanks, > David > >> Dan >> >> >>> >>> This also reminded me to follow up on why the Solaris SR_handler is >>> different and I found it is not actually installed as a direct signal >>> handler, but is called from the real signal handler if dealing with a >>> JavaThread or the VMThread. Consequently the Solaris version of the >>> SR_handler can not encounter this specific bug and so I have reverted >>> the changes to os_solaris.cpp >>> >>> Thanks, >>> David >>> >>> >>>> Regards, >>>> Volker >>>> >>>> On Wed, Aug 3, 2016 at 3:13 AM, David Holmes >>> > wrote: >>>> >>>> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ >>>> >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8159461 >>>> >>>> >>>> The suspend/resume signal (SR_signum) is never sent to a thread >>>> once >>>> it has started to terminate. On one platform (SuSE 12) we have >>>> seen >>>> what appears to be a "stuck" signal, which is only delivered when >>>> the terminating thread restores its original signal mask (as if >>>> pthread_sigmask makes the system realize there is a pending >>>> signal - >>>> we already check the signal was not blocked). At this point in the >>>> thread termination we have freed the osthread, so the the >>>> SR_handler >>>> would access deallocated memory. In debug builds we first hit an >>>> assertion that the current thread is a JavaThread or the >>>> VMThread - >>>> that assertion fails, even though it is a JavaThread, because we >>>> have already executed the ~JavaThread destructor and inside the >>>> ~Thread destructor we are a plain Thread not a JavaThread. >>>> >>>> The fix was to make a small adjustment to the thread termination >>>> process so that we delete the SR_lock before calling >>>> os::free_thread(). In the SR_handler() we can then use a NULL >>>> check >>>> of SR_lock() to indicate the thread has terminated and we return. >>>> >>>> While only seen on Linux I took the opportunity to apply the >>>> fix on >>>> all platforms and also cleaned up the code where we were using >>>> Thread::current() unsafely in a signal-handling context. >>>> >>>> Testing: regular tier 1 (JPRT) >>>> Kitchensink (in progress) >>>> >>>> As we can't readily reproduce the problem I tested this by >>>> having a >>>> terminating thread raise SR_signum directly from within the >>>> ~Thread >>>> destructor. >>>> >>>> Thanks, >>>> David >>>> >>>> >> From david.holmes at oracle.com Fri Aug 12 04:06:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Aug 2016 14:06:18 +1000 Subject: (S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread In-Reply-To: <82648eab-d84a-a112-2862-4f905ed772d4@oracle.com> References: <3c87ada2-71e3-ded3-33fb-e6dce6b12ee4@oracle.com> <17a8d9a5-e9da-ef69-8f14-81b46710eaf1@oracle.com> <047f996d-51b2-8993-6439-a32e6d5c7908@oracle.com> <82648eab-d84a-a112-2862-4f905ed772d4@oracle.com> Message-ID: <583699c2-62f2-f4e9-0839-4fced4b568fd@oracle.com> On 12/08/2016 11:25 AM, Daniel D. Daugherty wrote: > David, > > Sorry I forgot to respond before I left for Santa Fe, NM... > More below... No problem. > > On 8/8/16 5:57 PM, David Holmes wrote: >> Hi Dan, >> >> Thanks for the review. >> >> On 9/08/2016 2:07 AM, Daniel D. Daugherty wrote: >>> On 8/4/16 8:28 PM, David Holmes wrote: >>>> Hi Volker, >>>> >>>> Thanks for looking at this. >>>> >>>> On 5/08/2016 1:48 AM, Volker Simonis wrote: >>>>> Hi David, >>>>> >>>>> thanks for doing this change on all platforms. >>>>> The fix looks good. Maybe you can just extend the following comment >>>>> with >>>>> something like: >>>>> >>>>> // Note that the SR_lock plays no role in this suspend/resume >>>>> protocol. >>>>> // It is only used in SR_handler as a thread termination >>>>> indicator if >>>>> NULL. >>>> >>>> Darn this code is confusing - too many "SR"'s :( I have added >>>> >>>> // Note that the SR_lock plays no role in this suspend/resume >>>> protocol, >>>> // but is checked for NULL in SR_handler as a thread termination >>>> indicator. >>>> >>>> Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8159461/webrev.v2/ >>> >>> src/share/vm/runtime/thread.cpp >>> L380: _SR_lock = NULL; >>> I was expecting the _SR_lock to be freed and NULL'ed earlier >>> based on the discussion in the bug report. Since the crashing >>> assert() happens in a race between the JavaThread destructor >>> the NULL'ing of the _SR_lock field, I was expecting the _SR_lock >>> field to be dealt with as early as possible in the Thread >>> destructor (or even earlier; see my last comment). >> >> I will respond after that comment. >> >>> src/os/linux/vm/os_linux.cpp >>> L4010: // mask is changed as part of thread termination. Check the >>> current thread >>> grammar?: "Check the current" -> "Check that the current" >> >> Will change. >> >>> L4015: if (thread->SR_lock() == NULL) >>> L4016: return; >>> style nit: multi-line if-statements require '{' and '}' >>> Please add the braces or make this a single line if-statement. >>> I would prefer the braces. :-) >> >> Will fix. >> >>> Isn't there still a window between the completion of the >>> JavaThread destructor and where the Thread destructor sets >>> _SR_lock = NULL? >> >> See below. >> >>> L4020: OSThread* osthread = thread->osthread(); >>> Not your bug. This code assumes that osthread != NULL. >>> Maybe it needs to be more robust. >> >> Depends what kind of impossibilities we want to guard against. :) >> There should be no possible way a signal can be sent to a thread that >> doesn't even have a osThread as it means we never successfully >> started/attached the thread. > > That's a really good point. I'm good with what's there > for osthread. > > >> >>> src/os/aix/vm/os_aix.cpp >>> L2731: if (thread->SR_lock() == NULL) >>> L2732: return; >>> Same style nit. >>> >>> Same race. >>> >>> L2736: OSThread* osthread = thread->osthread(); >>> Same robustness comment. >>> >>> src/os/bsd/vm/os_bsd.cpp >>> L2759: if (thread->SR_lock() == NULL) >>> L2760: return; >>> Same style nit. >>> >>> Same race. >>> >>> L2764: OSThread* osthread = thread->osthread(); >>> Same robustness comment. >>> >>> It has been a very long time since I've dealt with races in the >>> suspend/resume code so I'm probably very rusty with this code. >>> If the _SR_lock is only used by the JavaThread suspend/resume >>> protocol, then we could consider free'ing and NULL'ing the field >>> in the JavaThread destructor (as the last piece of work). >>> >>> That should eliminate the race that was being observed by the >>> SR_handler() in this bug. It will open a very small race where >>> is_Java_thread() can return true, the _SR_lock field is !NULL, >>> but the _SR_lock has been deleted. >> >> Given that it should have been impossible to get into the SR_handler >> in the first place from this code I was trying to minimize the >> disruption to the existing logic. Moving the delete/NULLing to just >> before the call to os::free_thread() fixes the crashes that had been >> observed. I was not trying to make the entire destruction sequence >> safe wrt. the SR_handler. > > I suspect it is the combination of 1) NULLing the _SR_lock as a sentinel > and > 2) doing that before the more expensive os::free_thread() call that results > in the change in behavior. Right. The call to pthread_sigmask in os::free_thread is what appeared to un-jam the pending signal; so if we bail out before os::free_thread we avoid that. > >> My major concern with deleting the SR_lock much earlier is the >> potential race condition that I have previously outlined in: >> >> https://bugs.openjdk.java.net/browse/JDK-8152849 >> >> where there is no protection against a target thread terminating. The >> sooner it terminates and deletes the SR_lock the more likely we may >> attempt to lock a deleted lock! > > Ah yes... thanks for the reminder. We have seen a few of those in the > past where we're racing to grab the _SR_lock and Elvis is trying to > leave the building... > > I'm good with just the minor changes you agreed to make above. I don't > think I need to see a new webrev for the above edits. > > Thumbs up! Thanks! David ----- > Dan > > > >> >> Thanks, >> David >> >>> Dan >>> >>> >>>> >>>> This also reminded me to follow up on why the Solaris SR_handler is >>>> different and I found it is not actually installed as a direct signal >>>> handler, but is called from the real signal handler if dealing with a >>>> JavaThread or the VMThread. Consequently the Solaris version of the >>>> SR_handler can not encounter this specific bug and so I have reverted >>>> the changes to os_solaris.cpp >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> On Wed, Aug 3, 2016 at 3:13 AM, David Holmes >>>> > wrote: >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/ >>>>> >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8159461 >>>>> >>>>> >>>>> The suspend/resume signal (SR_signum) is never sent to a thread >>>>> once >>>>> it has started to terminate. On one platform (SuSE 12) we have >>>>> seen >>>>> what appears to be a "stuck" signal, which is only delivered when >>>>> the terminating thread restores its original signal mask (as if >>>>> pthread_sigmask makes the system realize there is a pending >>>>> signal - >>>>> we already check the signal was not blocked). At this point in the >>>>> thread termination we have freed the osthread, so the the >>>>> SR_handler >>>>> would access deallocated memory. In debug builds we first hit an >>>>> assertion that the current thread is a JavaThread or the >>>>> VMThread - >>>>> that assertion fails, even though it is a JavaThread, because we >>>>> have already executed the ~JavaThread destructor and inside the >>>>> ~Thread destructor we are a plain Thread not a JavaThread. >>>>> >>>>> The fix was to make a small adjustment to the thread termination >>>>> process so that we delete the SR_lock before calling >>>>> os::free_thread(). In the SR_handler() we can then use a NULL >>>>> check >>>>> of SR_lock() to indicate the thread has terminated and we return. >>>>> >>>>> While only seen on Linux I took the opportunity to apply the >>>>> fix on >>>>> all platforms and also cleaned up the code where we were using >>>>> Thread::current() unsafely in a signal-handling context. >>>>> >>>>> Testing: regular tier 1 (JPRT) >>>>> Kitchensink (in progress) >>>>> >>>>> As we can't readily reproduce the problem I tested this by >>>>> having a >>>>> terminating thread raise SR_signum directly from within the >>>>> ~Thread >>>>> destructor. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>> > From harsha.wardhana.b at oracle.com Fri Aug 12 05:01:01 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 12 Aug 2016 10:31:01 +0530 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules Message-ID: Hi All, Please review fix for issue, JDK-8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules with webrev located at, http://cr.openjdk.java.net/~hb/8131061/webrev.00/ Regards Harsha -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Fri Aug 12 08:07:34 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 12 Aug 2016 13:37:34 +0530 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> Message-ID: Hello, I forgot to put-in the fix details. The test was failing because of a race condition caused by the order in which MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage was invoked. It is possible that intermediate allocations can happen which can lead to getUsage > getPeakUsage if getUsage is called after getPeakUsage. The correct order would be to capture getUsage and then capture getPeakUsage in order to account for intermediate allocations. Thanks Harsha On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote: > Hello, > > Could one of you please review the below fix? > > Thanks > Harsha > > On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: >> Please use following alias for compiler tests (hotspot/test/compiler): >> >> hotspot-compiler-dev at openjdk.java.net >> >> Leonid >> >> >> On 08.08.2016 17:09, Harsha wardhana B wrote: >>> Gentle Reminder !! >>> >>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>>> Hello All, >>>> >>>> Please review the below simple test fix for the issue, >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>>> >>>> with webrev located at, >>>> >>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>>> >>>> Regards >>>> >>>> Harsha >>>> >>> >> > From staffan.larsen at oracle.com Fri Aug 12 08:29:10 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 12 Aug 2016 10:29:10 +0200 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> Message-ID: <19374B3B-6373-458F-B0A0-45D56798BDFE@oracle.com> Harsha, Thanks for the explanation! With that in mind the new code looks correct, although I would probably make it even more obvious in which order getUsage() and getPeakUsage() is executed by calling them on separate lines before the call to assertEQorLTE() instead of relying on the order method parameters are evaluated. Relying on the order of evaluation is correct, but doing explicit calls would make it a lot more obvious that the order is important. Thanks, /Staffan > On 12 aug. 2016, at 10:07, Harsha Wardhana B wrote: > > Hello, > > I forgot to put-in the fix details. > > The test was failing because of a race condition caused by the order in which MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage was invoked. It is possible that intermediate allocations can happen which can lead to getUsage > getPeakUsage if getUsage is called after getPeakUsage. The correct order would be to capture getUsage and then capture getPeakUsage in order to account for intermediate allocations. > > Thanks > > Harsha > > > On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote: >> Hello, >> >> Could one of you please review the below fix? >> >> Thanks >> Harsha >> >> On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: >>> Please use following alias for compiler tests (hotspot/test/compiler): >>> >>> hotspot-compiler-dev at openjdk.java.net >>> >>> Leonid >>> >>> >>> On 08.08.2016 17:09, Harsha wardhana B wrote: >>>> Gentle Reminder !! >>>> >>>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>>>> Hello All, >>>>> >>>>> Please review the below simple test fix for the issue, >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>>>> >>>>> with webrev located at, >>>>> >>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>> >>> >> > From dmitry.samersoff at oracle.com Fri Aug 12 09:04:42 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 12 Aug 2016 12:04:42 +0300 Subject: RFR(S): JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file In-Reply-To: <0e789ca0-bd59-08ee-e9a8-da0646f06780@oracle.com> References: <1cf08a48-d7c0-1953-08ef-5d75f8225a3c@oracle.com> <9a8c4cdb-0389-5d0b-6b87-7167ed66c655@oracle.com> <0e789ca0-bd59-08ee-e9a8-da0646f06780@oracle.com> Message-ID: David, Updated webrev is: http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.04/ Windows is absolutely different story that requires significant efforts to reproduce error conditions and test changes. Also it has nothing to do with ARMv7. So I would prefer to address windows issues separately either as a part of JDK-8159799 or as a separate CR. -Dmitry On 2016-08-12 03:24, David Holmes wrote: > Hi Dmitry, > > On 12/08/2016 2:55 AM, Dmitry Samersoff wrote: >> David, >> >> Please see updated webrev. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ >> >> I didn't touch windows version because it quite different from *NIX one. > > Do we ever see failures on Windows? Is so we should add diagnostics > there too even if they are different to *NIX. > > I would still like to see what file it is working with. We need some > logging in here: > > bool AttachListener::is_init_trigger() { > if (init_at_startup() || is_initialized()) { > return false; // initialized at startup or already > initialized > } > char fn[PATH_MAX+1]; > sprintf(fn, ".attach_pid%d", os::current_process_id()); > int ret; > struct stat64 st; > RESTARTABLE(::stat64(fn, &st), ret); > if (ret == -1) { > + log ("failed to find attach file: %s, trying alternate", fn) > snprintf(fn, sizeof(fn), "%s/.attach_pid%d", > os::get_temp_directory(), os::current_process_id()); > RESTARTABLE(::stat64(fn, &st), ret); > + if (ret == -1) { > + log("failed to find attach file: %s", fn); > + } > } > > All failure paths need to show us what it was that failed. > > typos: trigerred -> triggered > > Thanks, > David > >> -Dmitry >> >> On 2016-08-08 02:40, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 5/08/2016 7:25 PM, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review the fix: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.02/ >>>> >>>> Problem: >>>> Tests fail intermittently because it can't attach to child process, >>>> these attach failures is hard to debug because attach framework >>>> doesn't provide enough diagnostic information. >>>> >>>> Solution: >>>> >>>> a) Increase attach timeout >>>> b) Slightly change attach loop to save a bit of CPU power. >>>> c) Add some logging to attach listener. >>>> >>>> It's just a first step in this direction. Complete cleanup of attach >>>> code (remove LinuxThreads support and convert all printing to UL) is >>>> not >>>> a goal of this fix - I'll file a separate CR for it. >>> >>> I still think you need more logging now to aid in debugging these cases. >>> In particular we want to be able to verify that the path of the attach >>> file is what we expect in all cases ie whether we find the .attach_pid >>> file in cwd or whether we are looking in temp directory, and whether we >>> ultimately succeed or fail. >>> >>> Plus whatever you do now should be done consistently for all platforms. >>> >>> Thanks, >>> David >>> >>>> -Dmitry >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alexander.kulyakhtin at oracle.com Fri Aug 12 12:55:09 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Fri, 12 Aug 2016 05:55:09 -0700 (PDT) Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" Message-ID: Hi, Could you, please, review the following test-only change (adding a new test): CR: https://bugs.openjdk.java.net/browse/JDK-8148103 Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/ The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. When started the debuggee reports its loaded modules to the test. The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. Best regards, Alexander From harsha.wardhana.b at oracle.com Fri Aug 12 15:26:48 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Fri, 12 Aug 2016 20:56:48 +0530 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: <19374B3B-6373-458F-B0A0-45D56798BDFE@oracle.com> References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> <19374B3B-6373-458F-B0A0-45D56798BDFE@oracle.com> Message-ID: <4d40553c-c8b1-ecbc-b9fc-7482f50449ce@oracle.com> Hi, Please review modified webrev incorporating Staffan's comments. http://cr.openjdk.java.net/~hb/8151345/webrev.01/ Thanks Harsha On Friday 12 August 2016 01:59 PM, Staffan Larsen wrote: > Harsha, > > Thanks for the explanation! With that in mind the new code looks correct, although I would probably make it even more obvious in which order getUsage() and getPeakUsage() is executed by calling them on separate lines before the call to assertEQorLTE() instead of relying on the order method parameters are evaluated. Relying on the order of evaluation is correct, but doing explicit calls would make it a lot more obvious that the order is important. > > Thanks, > /Staffan > >> On 12 aug. 2016, at 10:07, Harsha Wardhana B wrote: >> >> Hello, >> >> I forgot to put-in the fix details. >> >> The test was failing because of a race condition caused by the order in which MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage was invoked. It is possible that intermediate allocations can happen which can lead to getUsage > getPeakUsage if getUsage is called after getPeakUsage. The correct order would be to capture getUsage and then capture getPeakUsage in order to account for intermediate allocations. >> >> Thanks >> >> Harsha >> >> >> On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote: >>> Hello, >>> >>> Could one of you please review the below fix? >>> >>> Thanks >>> Harsha >>> >>> On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: >>>> Please use following alias for compiler tests (hotspot/test/compiler): >>>> >>>> hotspot-compiler-dev at openjdk.java.net >>>> >>>> Leonid >>>> >>>> >>>> On 08.08.2016 17:09, Harsha wardhana B wrote: >>>>> Gentle Reminder !! >>>>> >>>>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>>>>> Hello All, >>>>>> >>>>>> Please review the below simple test fix for the issue, >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>>>>> >>>>>> with webrev located at, >>>>>> >>>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>>>>> >>>>>> Regards >>>>>> >>>>>> Harsha >>>>>> From staffan.larsen at oracle.com Fri Aug 12 19:29:35 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 12 Aug 2016 21:29:35 +0200 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: <4d40553c-c8b1-ecbc-b9fc-7482f50449ce@oracle.com> References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> <19374B3B-6373-458F-B0A0-45D56798BDFE@oracle.com> <4d40553c-c8b1-ecbc-b9fc-7482f50449ce@oracle.com> Message-ID: <0497B367-0700-4C9A-B26E-08475BF01796@oracle.com> If you swap currUsage and peakUsage in the call to assertEQorLTE() you can use assertEQorGTE() and you won?t have to change CodeCacheUtils.java. Or am I missing something? > On 12 aug. 2016, at 17:26, Harsha Wardhana B wrote: > > Hi, > > Please review modified webrev incorporating Staffan's comments. > > http://cr.openjdk.java.net/~hb/8151345/webrev.01/ > > Thanks > Harsha > > On Friday 12 August 2016 01:59 PM, Staffan Larsen wrote: >> Harsha, >> >> Thanks for the explanation! With that in mind the new code looks correct, although I would probably make it even more obvious in which order getUsage() and getPeakUsage() is executed by calling them on separate lines before the call to assertEQorLTE() instead of relying on the order method parameters are evaluated. Relying on the order of evaluation is correct, but doing explicit calls would make it a lot more obvious that the order is important. >> >> Thanks, >> /Staffan >> >>> On 12 aug. 2016, at 10:07, Harsha Wardhana B wrote: >>> >>> Hello, >>> >>> I forgot to put-in the fix details. >>> >>> The test was failing because of a race condition caused by the order in which MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage was invoked. It is possible that intermediate allocations can happen which can lead to getUsage > getPeakUsage if getUsage is called after getPeakUsage. The correct order would be to capture getUsage and then capture getPeakUsage in order to account for intermediate allocations. >>> >>> Thanks >>> >>> Harsha >>> >>> >>> On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote: >>>> Hello, >>>> >>>> Could one of you please review the below fix? >>>> >>>> Thanks >>>> Harsha >>>> >>>> On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: >>>>> Please use following alias for compiler tests (hotspot/test/compiler): >>>>> >>>>> hotspot-compiler-dev at openjdk.java.net >>>>> >>>>> Leonid >>>>> >>>>> >>>>> On 08.08.2016 17:09, Harsha wardhana B wrote: >>>>>> Gentle Reminder !! >>>>>> >>>>>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>>>>>> Hello All, >>>>>>> >>>>>>> Please review the below simple test fix for the issue, >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>>>>>> >>>>>>> with webrev located at, >>>>>>> >>>>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Harsha >>>>>>> > From david.holmes at oracle.com Mon Aug 15 04:23:17 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Aug 2016 14:23:17 +1000 Subject: RFR(S): JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file In-Reply-To: References: <1cf08a48-d7c0-1953-08ef-5d75f8225a3c@oracle.com> <9a8c4cdb-0389-5d0b-6b87-7167ed66c655@oracle.com> <0e789ca0-bd59-08ee-e9a8-da0646f06780@oracle.com> Message-ID: On 12/08/2016 7:04 PM, Dmitry Samersoff wrote: > David, > > Updated webrev is: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.04/ Thanks, this looks okay. Only minor concern is whether we have to apply casts to the results of geteuid() and st.st_uid when used with %d format specifier? > Windows is absolutely different story that requires significant efforts > to reproduce error conditions and test changes. Also it has nothing to > do with ARMv7. > > So I would prefer to address windows issues separately either as a part > of JDK-8159799 or as a separate CR. Ok. Thanks, David > -Dmitry > > On 2016-08-12 03:24, David Holmes wrote: >> Hi Dmitry, >> >> On 12/08/2016 2:55 AM, Dmitry Samersoff wrote: >>> David, >>> >>> Please see updated webrev. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ >>> >>> I didn't touch windows version because it quite different from *NIX one. >> >> Do we ever see failures on Windows? Is so we should add diagnostics >> there too even if they are different to *NIX. >> >> I would still like to see what file it is working with. We need some >> logging in here: >> >> bool AttachListener::is_init_trigger() { >> if (init_at_startup() || is_initialized()) { >> return false; // initialized at startup or already >> initialized >> } >> char fn[PATH_MAX+1]; >> sprintf(fn, ".attach_pid%d", os::current_process_id()); >> int ret; >> struct stat64 st; >> RESTARTABLE(::stat64(fn, &st), ret); >> if (ret == -1) { >> + log ("failed to find attach file: %s, trying alternate", fn) >> snprintf(fn, sizeof(fn), "%s/.attach_pid%d", >> os::get_temp_directory(), os::current_process_id()); >> RESTARTABLE(::stat64(fn, &st), ret); >> + if (ret == -1) { >> + log("failed to find attach file: %s", fn); >> + } >> } >> >> All failure paths need to show us what it was that failed. >> >> typos: trigerred -> triggered >> >> Thanks, >> David >> >>> -Dmitry >>> >>> On 2016-08-08 02:40, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 5/08/2016 7:25 PM, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review the fix: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.02/ >>>>> >>>>> Problem: >>>>> Tests fail intermittently because it can't attach to child process, >>>>> these attach failures is hard to debug because attach framework >>>>> doesn't provide enough diagnostic information. >>>>> >>>>> Solution: >>>>> >>>>> a) Increase attach timeout >>>>> b) Slightly change attach loop to save a bit of CPU power. >>>>> c) Add some logging to attach listener. >>>>> >>>>> It's just a first step in this direction. Complete cleanup of attach >>>>> code (remove LinuxThreads support and convert all printing to UL) is >>>>> not >>>>> a goal of this fix - I'll file a separate CR for it. >>>> >>>> I still think you need more logging now to aid in debugging these cases. >>>> In particular we want to be able to verify that the path of the attach >>>> file is what we expect in all cases ie whether we find the .attach_pid >>>> file in cwd or whether we are looking in temp directory, and whether we >>>> ultimately succeed or fail. >>>> >>>> Plus whatever you do now should be done consistently for all platforms. >>>> >>>> Thanks, >>>> David >>>> >>>>> -Dmitry >>>>> >>> >>> > > From dmitry.samersoff at oracle.com Mon Aug 15 08:48:43 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 15 Aug 2016 11:48:43 +0300 Subject: RFR(S): JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file In-Reply-To: References: <1cf08a48-d7c0-1953-08ef-5d75f8225a3c@oracle.com> <9a8c4cdb-0389-5d0b-6b87-7167ed66c655@oracle.com> <0e789ca0-bd59-08ee-e9a8-da0646f06780@oracle.com> Message-ID: <61d03ed0-770f-ffd6-67e8-9d7078272ea1@oracle.com> David, > Thanks, this looks okay. Thank you for review! > Only minor concern is whether we have to > apply casts to the results of geteuid() and st.st_uid when used with > %d format specifier? I didn't see any complains neither from jprt nor building locally. uid_t is 4 byte type for both 32bit/64bit so I don't think we need to cast. -Dmitry On 2016-08-15 07:23, David Holmes wrote: > On 12/08/2016 7:04 PM, Dmitry Samersoff wrote: >> David, >> >> Updated webrev is: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.04/ > > Thanks, this looks okay. Only minor concern is whether we have to > apply casts to the results of geteuid() and st.st_uid when used with > %d format specifier? > >> Windows is absolutely different story that requires significant >> efforts to reproduce error conditions and test changes. Also it has >> nothing to do with ARMv7. >> >> So I would prefer to address windows issues separately either as a >> part of JDK-8159799 or as a separate CR. > > Ok. > > Thanks, David > >> -Dmitry >> >> On 2016-08-12 03:24, David Holmes wrote: >>> Hi Dmitry, >>> >>> On 12/08/2016 2:55 AM, Dmitry Samersoff wrote: >>>> David, >>>> >>>> Please see updated webrev. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ >>>> >>>> I didn't touch windows version because it quite different from >>>> *NIX one. >>> >>> Do we ever see failures on Windows? Is so we should add >>> diagnostics there too even if they are different to *NIX. >>> >>> I would still like to see what file it is working with. We need >>> some logging in here: >>> >>> bool AttachListener::is_init_trigger() { if (init_at_startup() || >>> is_initialized()) { return false; // initialized at >>> startup or already initialized } char fn[PATH_MAX+1]; sprintf(fn, >>> ".attach_pid%d", os::current_process_id()); int ret; struct >>> stat64 st; RESTARTABLE(::stat64(fn, &st), ret); if (ret == -1) { >>> + log ("failed to find attach file: %s, trying alternate", >>> fn) snprintf(fn, sizeof(fn), "%s/.attach_pid%d", >>> os::get_temp_directory(), os::current_process_id()); >>> RESTARTABLE(::stat64(fn, &st), ret); + if (ret == -1) { + >>> log("failed to find attach file: %s", fn); + } } >>> >>> All failure paths need to show us what it was that failed. >>> >>> typos: trigerred -> triggered >>> >>> Thanks, David >>> >>>> -Dmitry >>>> >>>> On 2016-08-08 02:40, David Holmes wrote: >>>>> Hi Dmitry, >>>>> >>>>> On 5/08/2016 7:25 PM, Dmitry Samersoff wrote: >>>>>> Everybody, >>>>>> >>>>>> Please review the fix: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.02/ >>>>>> >>>>>> >>>>>> Problem: >>>>>> Tests fail intermittently because it can't attach to child >>>>>> process, these attach failures is hard to debug because >>>>>> attach framework doesn't provide enough diagnostic >>>>>> information. >>>>>> >>>>>> Solution: >>>>>> >>>>>> a) Increase attach timeout b) Slightly change attach loop >>>>>> to save a bit of CPU power. c) Add some logging to attach >>>>>> listener. >>>>>> >>>>>> It's just a first step in this direction. Complete cleanup >>>>>> of attach code (remove LinuxThreads support and convert all >>>>>> printing to UL) is not a goal of this fix - I'll file a >>>>>> separate CR for it. >>>>> >>>>> I still think you need more logging now to aid in debugging >>>>> these cases. In particular we want to be able to verify that >>>>> the path of the attach file is what we expect in all cases ie >>>>> whether we find the .attach_pid file in cwd or whether we >>>>> are looking in temp directory, and whether we ultimately >>>>> succeed or fail. >>>>> >>>>> Plus whatever you do now should be done consistently for all >>>>> platforms. >>>>> >>>>> Thanks, David >>>>> >>>>>> -Dmitry >>>>>> >>>> >>>> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Mon Aug 15 08:49:33 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 15 Aug 2016 11:49:33 +0300 Subject: RFR(S): *NEED SECOND* JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file In-Reply-To: References: <1cf08a48-d7c0-1953-08ef-5d75f8225a3c@oracle.com> <9a8c4cdb-0389-5d0b-6b87-7167ed66c655@oracle.com> <0e789ca0-bd59-08ee-e9a8-da0646f06780@oracle.com> Message-ID: <432f2abb-4652-2e08-0af3-70e4ad308ea8@oracle.com> On 2016-08-12 12:04, Dmitry Samersoff wrote: > David, > > Updated webrev is: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.04/ > > Windows is absolutely different story that requires significant efforts > to reproduce error conditions and test changes. Also it has nothing to > do with ARMv7. > > So I would prefer to address windows issues separately either as a part > of JDK-8159799 or as a separate CR. > > -Dmitry > > On 2016-08-12 03:24, David Holmes wrote: >> Hi Dmitry, >> >> On 12/08/2016 2:55 AM, Dmitry Samersoff wrote: >>> David, >>> >>> Please see updated webrev. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.03/ >>> >>> I didn't touch windows version because it quite different from *NIX one. >> >> Do we ever see failures on Windows? Is so we should add diagnostics >> there too even if they are different to *NIX. >> >> I would still like to see what file it is working with. We need some >> logging in here: >> >> bool AttachListener::is_init_trigger() { >> if (init_at_startup() || is_initialized()) { >> return false; // initialized at startup or already >> initialized >> } >> char fn[PATH_MAX+1]; >> sprintf(fn, ".attach_pid%d", os::current_process_id()); >> int ret; >> struct stat64 st; >> RESTARTABLE(::stat64(fn, &st), ret); >> if (ret == -1) { >> + log ("failed to find attach file: %s, trying alternate", fn) >> snprintf(fn, sizeof(fn), "%s/.attach_pid%d", >> os::get_temp_directory(), os::current_process_id()); >> RESTARTABLE(::stat64(fn, &st), ret); >> + if (ret == -1) { >> + log("failed to find attach file: %s", fn); >> + } >> } >> >> All failure paths need to show us what it was that failed. >> >> typos: trigerred -> triggered >> >> Thanks, >> David >> >>> -Dmitry >>> >>> On 2016-08-08 02:40, David Holmes wrote: >>>> Hi Dmitry, >>>> >>>> On 5/08/2016 7:25 PM, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review the fix: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.02/ >>>>> >>>>> Problem: >>>>> Tests fail intermittently because it can't attach to child process, >>>>> these attach failures is hard to debug because attach framework >>>>> doesn't provide enough diagnostic information. >>>>> >>>>> Solution: >>>>> >>>>> a) Increase attach timeout >>>>> b) Slightly change attach loop to save a bit of CPU power. >>>>> c) Add some logging to attach listener. >>>>> >>>>> It's just a first step in this direction. Complete cleanup of attach >>>>> code (remove LinuxThreads support and convert all printing to UL) is >>>>> not >>>>> a goal of this fix - I'll file a separate CR for it. >>>> >>>> I still think you need more logging now to aid in debugging these cases. >>>> In particular we want to be able to verify that the path of the attach >>>> file is what we expect in all cases ie whether we find the .attach_pid >>>> file in cwd or whether we are looking in temp directory, and whether we >>>> ultimately succeed or fail. >>>> >>>> Plus whatever you do now should be done consistently for all platforms. >>>> >>>> Thanks, >>>> David >>>> >>>>> -Dmitry >>>>> >>> >>> > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Mon Aug 15 18:15:49 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 15 Aug 2016 20:15:49 +0200 Subject: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found Message-ID: All, Please review this fix for a test that starting failing after recent changes to java.lang.invoke. The test instructs jdb to break on all exceptions matching "java.lang.I*" (that's a capital 'i'). The semantics of that operation actually means "break on all exceptions which have a class name or superclass name matching this string". Some of the recent changes in java.lang.invoke now causes the code to throw numerous java.lang.NoSuchMethodErrors. This is a subclass of java.lang.IncompatibleClassChangeError, which matches "java.lang.I*". The net result is that jdb will break on a lot more places (all the NoSuchMethodError exceptions) than the test expects and the test fails. We can work around this in the test by changing this line: cmd catch all java.lang.I* to the following two lines: cmd catch all java.lang.Il* cmd catch all java.lang.Ind* This will still match the exception types the test is looking for (IllegalArgumentException, IllegalMonitorStateException, and IndexOutOfBoundsException), but it will not match IncompatibleClassChangeError. Thanks, /Staffan diff --git a/test/com/sun/jdi/CatchPatternTest.sh b/test/com/sun/jdi/CatchPatternTest.sh --- a/test/com/sun/jdi/CatchPatternTest.sh +++ b/test/com/sun/jdi/CatchPatternTest.sh @@ -87,7 +87,12 @@ cmd stop in ${classname}.partTwo runToBkpt cmd ignore uncaught java.lang.Throwable - cmd catch all java.lang.I* + # Instead of matching java.lang.I* we use two more specific + # patterns here. The reason is to avoid matching IncompatibleClassChangeError + # (or the subclass NoSuchMethodError) thrown by the + # java.lang.invoke infrastructure. + cmd catch all java.lang.Il* + cmd catch all java.lang.Ind* cmd cont cmd cont cmd cont From dmitry.samersoff at oracle.com Mon Aug 15 18:27:40 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 15 Aug 2016 21:27:40 +0300 Subject: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found In-Reply-To: References: Message-ID: Staffan, Looks good for me! -Dmitry On 2016-08-15 21:15, Staffan Larsen wrote: > All, > > Please review this fix for a test that starting failing after recent changes to java.lang.invoke. > > The test instructs jdb to break on all exceptions matching "java.lang.I*" (that's a capital 'i'). The semantics of that operation actually means "break on all exceptions which have a class name or superclass name matching this string". > > Some of the recent changes in java.lang.invoke now causes the code to throw numerous java.lang.NoSuchMethodErrors. This is a subclass of java.lang.IncompatibleClassChangeError, which matches "java.lang.I*". > > The net result is that jdb will break on a lot more places (all the NoSuchMethodError exceptions) than the test expects and the test fails. > > We can work around this in the test by changing this line: > > cmd catch all java.lang.I* > > to the following two lines: > > cmd catch all java.lang.Il* > cmd catch all java.lang.Ind* > > This will still match the exception types the test is looking for (IllegalArgumentException, IllegalMonitorStateException, and IndexOutOfBoundsException), but it will not match IncompatibleClassChangeError. > > Thanks, > /Staffan > > > diff --git a/test/com/sun/jdi/CatchPatternTest.sh b/test/com/sun/jdi/CatchPatternTest.sh > --- a/test/com/sun/jdi/CatchPatternTest.sh > +++ b/test/com/sun/jdi/CatchPatternTest.sh > @@ -87,7 +87,12 @@ > cmd stop in ${classname}.partTwo > runToBkpt > cmd ignore uncaught java.lang.Throwable > - cmd catch all java.lang.I* > + # Instead of matching java.lang.I* we use two more specific > + # patterns here. The reason is to avoid matching IncompatibleClassChangeError > + # (or the subclass NoSuchMethodError) thrown by the > + # java.lang.invoke infrastructure. > + cmd catch all java.lang.Il* > + cmd catch all java.lang.Ind* > cmd cont > cmd cont > cmd cont > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From staffan.larsen at oracle.com Mon Aug 15 19:07:37 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 15 Aug 2016 21:07:37 +0200 Subject: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found In-Reply-To: References: Message-ID: <777102A0-E9CF-4114-9001-D9044ED3F26E@oracle.com> Thank you! > On 15 aug. 2016, at 20:27, Dmitry Samersoff wrote: > > Staffan, > > Looks good for me! > > -Dmitry > > > On 2016-08-15 21:15, Staffan Larsen wrote: >> All, >> >> Please review this fix for a test that starting failing after recent changes to java.lang.invoke. >> >> The test instructs jdb to break on all exceptions matching "java.lang.I*" (that's a capital 'i'). The semantics of that operation actually means "break on all exceptions which have a class name or superclass name matching this string". >> >> Some of the recent changes in java.lang.invoke now causes the code to throw numerous java.lang.NoSuchMethodErrors. This is a subclass of java.lang.IncompatibleClassChangeError, which matches "java.lang.I*". >> >> The net result is that jdb will break on a lot more places (all the NoSuchMethodError exceptions) than the test expects and the test fails. >> >> We can work around this in the test by changing this line: >> >> cmd catch all java.lang.I* >> >> to the following two lines: >> >> cmd catch all java.lang.Il* >> cmd catch all java.lang.Ind* >> >> This will still match the exception types the test is looking for (IllegalArgumentException, IllegalMonitorStateException, and IndexOutOfBoundsException), but it will not match IncompatibleClassChangeError. >> >> Thanks, >> /Staffan >> >> >> diff --git a/test/com/sun/jdi/CatchPatternTest.sh b/test/com/sun/jdi/CatchPatternTest.sh >> --- a/test/com/sun/jdi/CatchPatternTest.sh >> +++ b/test/com/sun/jdi/CatchPatternTest.sh >> @@ -87,7 +87,12 @@ >> cmd stop in ${classname}.partTwo >> runToBkpt >> cmd ignore uncaught java.lang.Throwable >> - cmd catch all java.lang.I* >> + # Instead of matching java.lang.I* we use two more specific >> + # patterns here. The reason is to avoid matching IncompatibleClassChangeError >> + # (or the subclass NoSuchMethodError) thrown by the >> + # java.lang.invoke infrastructure. >> + cmd catch all java.lang.Il* >> + cmd catch all java.lang.Ind* >> cmd cont >> cmd cont >> cmd cont >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Mon Aug 15 20:46:35 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Aug 2016 06:46:35 +1000 Subject: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found In-Reply-To: References: Message-ID: <80e01043-b3ac-0772-422e-4386f59dfe9d@oracle.com> Hi Staffan, Looks good. Though I do wonder how the matching logic works such that the superclass is considered. I suppose it is a "feature" to match on X and all subclasses of X, but probably should be a way to match on exactly X not subclasses. Anyway just idle thoughts. :) Thanks, David On 16/08/2016 4:15 AM, Staffan Larsen wrote: > All, > > Please review this fix for a test that starting failing after recent changes to java.lang.invoke. > > The test instructs jdb to break on all exceptions matching "java.lang.I*" (that's a capital 'i'). The semantics of that operation actually means "break on all exceptions which have a class name or superclass name matching this string". > > Some of the recent changes in java.lang.invoke now causes the code to throw numerous java.lang.NoSuchMethodErrors. This is a subclass of java.lang.IncompatibleClassChangeError, which matches "java.lang.I*". > > The net result is that jdb will break on a lot more places (all the NoSuchMethodError exceptions) than the test expects and the test fails. > > We can work around this in the test by changing this line: > > cmd catch all java.lang.I* > > to the following two lines: > > cmd catch all java.lang.Il* > cmd catch all java.lang.Ind* > > This will still match the exception types the test is looking for (IllegalArgumentException, IllegalMonitorStateException, and IndexOutOfBoundsException), but it will not match IncompatibleClassChangeError. > > Thanks, > /Staffan > > > diff --git a/test/com/sun/jdi/CatchPatternTest.sh b/test/com/sun/jdi/CatchPatternTest.sh > --- a/test/com/sun/jdi/CatchPatternTest.sh > +++ b/test/com/sun/jdi/CatchPatternTest.sh > @@ -87,7 +87,12 @@ > cmd stop in ${classname}.partTwo > runToBkpt > cmd ignore uncaught java.lang.Throwable > - cmd catch all java.lang.I* > + # Instead of matching java.lang.I* we use two more specific > + # patterns here. The reason is to avoid matching IncompatibleClassChangeError > + # (or the subclass NoSuchMethodError) thrown by the > + # java.lang.invoke infrastructure. > + cmd catch all java.lang.Il* > + cmd catch all java.lang.Ind* > cmd cont > cmd cont > cmd cont > From harsha.wardhana.b at oracle.com Tue Aug 16 06:08:30 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 16 Aug 2016 11:38:30 +0530 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object Message-ID: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> Hello, Please review and provide comments for fix for issue, https://bugs.openjdk.java.net/browse/JDK-8152589 having webrev located at http://cr.openjdk.java.net/~hb/8152589/webrev.00/ Fix details: 1. From nightly failures we see that LockThreadB was blocked on wrong object. We now do a repeated check with timeout if any given thread is blocked on expected object. It is possible that LockThreadB might still be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is invoked. 2. The logs from lock free logger was never printed. It is not being printed. 3. Any time we see failure, thread stack is being logged. This helps us ascertain if failure is in test case or in the component. 4. Even though we had lock free logger, several ex.printStackTrace() was used which could be responsible for failure. It is removed. 5. There were several places where tests continue to ran even after failure (testFailed flag). That is fixed. 6. Couple of other minor refactoring. Thanks Harsha From harsha.wardhana.b at oracle.com Tue Aug 16 06:15:38 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 16 Aug 2016 11:45:38 +0530 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: <0497B367-0700-4C9A-B26E-08475BF01796@oracle.com> References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> <19374B3B-6373-458F-B0A0-45D56798BDFE@oracle.com> <4d40553c-c8b1-ecbc-b9fc-7482f50449ce@oracle.com> <0497B367-0700-4C9A-B26E-08475BF01796@oracle.com> Message-ID: Yes. assertEQorGTE can be used. But using assertEQorLTE is better suited as it increase code readability. So I would like to leave that in place. On Saturday 13 August 2016 12:59 AM, Staffan Larsen wrote: > If you swap currUsage and peakUsage in the call to assertEQorLTE() you can use assertEQorGTE() and you won?t have to change CodeCacheUtils.java. Or am I missing something? > >> On 12 aug. 2016, at 17:26, Harsha Wardhana B wrote: >> >> Hi, >> >> Please review modified webrev incorporating Staffan's comments. >> >> http://cr.openjdk.java.net/~hb/8151345/webrev.01/ >> >> Thanks >> Harsha >> >> On Friday 12 August 2016 01:59 PM, Staffan Larsen wrote: >>> Harsha, >>> >>> Thanks for the explanation! With that in mind the new code looks correct, although I would probably make it even more obvious in which order getUsage() and getPeakUsage() is executed by calling them on separate lines before the call to assertEQorLTE() instead of relying on the order method parameters are evaluated. Relying on the order of evaluation is correct, but doing explicit calls would make it a lot more obvious that the order is important. >>> >>> Thanks, >>> /Staffan >>> >>>> On 12 aug. 2016, at 10:07, Harsha Wardhana B wrote: >>>> >>>> Hello, >>>> >>>> I forgot to put-in the fix details. >>>> >>>> The test was failing because of a race condition caused by the order in which MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage was invoked. It is possible that intermediate allocations can happen which can lead to getUsage > getPeakUsage if getUsage is called after getPeakUsage. The correct order would be to capture getUsage and then capture getPeakUsage in order to account for intermediate allocations. >>>> >>>> Thanks >>>> >>>> Harsha >>>> >>>> >>>> On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote: >>>>> Hello, >>>>> >>>>> Could one of you please review the below fix? >>>>> >>>>> Thanks >>>>> Harsha >>>>> >>>>> On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: >>>>>> Please use following alias for compiler tests (hotspot/test/compiler): >>>>>> >>>>>> hotspot-compiler-dev at openjdk.java.net >>>>>> >>>>>> Leonid >>>>>> >>>>>> >>>>>> On 08.08.2016 17:09, Harsha wardhana B wrote: >>>>>>> Gentle Reminder !! >>>>>>> >>>>>>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>>>>>>> Hello All, >>>>>>>> >>>>>>>> Please review the below simple test fix for the issue, >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>>>>>>> >>>>>>>> with webrev located at, >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Harsha >>>>>>>> From mallikarjuna.avaluri at oracle.com Tue Aug 16 06:19:03 2016 From: mallikarjuna.avaluri at oracle.com (Mallikarjuna Avaluri) Date: Tue, 16 Aug 2016 11:49:03 +0530 Subject: RFR 8160913: [TEST_BUG] javax/management/security/SecurityTest.java fails due to missing keyStore file In-Reply-To: References: Message-ID: Hi, Reminder, please help me with this review. Regards, Mallikarjuna Avaluri On 8/9/2016 11:11 AM, Mallikarjuna Avaluri wrote: > Hi all, > > Could you please review fix for following issue. > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8160913 > > Summary: [TEST_BUG] javax/management/security/SecurityTest.java fails > due to missing keyStore file > > Solution: Following files keystoreAgent, keystoreClient, > truststoreAgent and truststoreClient were created under > jdk/test/javax/management/ folder, > while test expects them under jdk/test/javax/management/security/ > path. Moved the files to correct folder. > > Webrev: > http://cr.openjdk.java.net/~bgopularam/mavaluri/rev/8160913/webrev.00/ > > > > > Thanks, > Mallikarjuna Avaluri > From staffan.larsen at oracle.com Tue Aug 16 07:47:55 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 16 Aug 2016 09:47:55 +0200 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> <19374B3B-6373-458F-B0A0-45D56798BDFE@oracle.com> <4d40553c-c8b1-ecbc-b9fc-7482f50449ce@oracle.com> <0497B367-0700-4C9A-B26E-08475BF01796@oracle.com> Message-ID: <0E7F7B57-FD3F-4B1A-B09C-DA16194FBF46@oracle.com> Ok. Reviewed. /Staffan > On 16 aug. 2016, at 08:15, Harsha Wardhana B wrote: > > Yes. assertEQorGTE can be used. But using assertEQorLTE is better suited as it increase code readability. So I would like to leave that in place. > > > On Saturday 13 August 2016 12:59 AM, Staffan Larsen wrote: >> If you swap currUsage and peakUsage in the call to assertEQorLTE() you can use assertEQorGTE() and you won?t have to change CodeCacheUtils.java. Or am I missing something? >> >>> On 12 aug. 2016, at 17:26, Harsha Wardhana B wrote: >>> >>> Hi, >>> >>> Please review modified webrev incorporating Staffan's comments. >>> >>> http://cr.openjdk.java.net/~hb/8151345/webrev.01/ >>> >>> Thanks >>> Harsha >>> >>> On Friday 12 August 2016 01:59 PM, Staffan Larsen wrote: >>>> Harsha, >>>> >>>> Thanks for the explanation! With that in mind the new code looks correct, although I would probably make it even more obvious in which order getUsage() and getPeakUsage() is executed by calling them on separate lines before the call to assertEQorLTE() instead of relying on the order method parameters are evaluated. Relying on the order of evaluation is correct, but doing explicit calls would make it a lot more obvious that the order is important. >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 12 aug. 2016, at 10:07, Harsha Wardhana B wrote: >>>>> >>>>> Hello, >>>>> >>>>> I forgot to put-in the fix details. >>>>> >>>>> The test was failing because of a race condition caused by the order in which MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage was invoked. It is possible that intermediate allocations can happen which can lead to getUsage > getPeakUsage if getUsage is called after getPeakUsage. The correct order would be to capture getUsage and then capture getPeakUsage in order to account for intermediate allocations. >>>>> >>>>> Thanks >>>>> >>>>> Harsha >>>>> >>>>> >>>>> On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote: >>>>>> Hello, >>>>>> >>>>>> Could one of you please review the below fix? >>>>>> >>>>>> Thanks >>>>>> Harsha >>>>>> >>>>>> On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: >>>>>>> Please use following alias for compiler tests (hotspot/test/compiler): >>>>>>> >>>>>>> hotspot-compiler-dev at openjdk.java.net >>>>>>> >>>>>>> Leonid >>>>>>> >>>>>>> >>>>>>> On 08.08.2016 17:09, Harsha wardhana B wrote: >>>>>>>> Gentle Reminder !! >>>>>>>> >>>>>>>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>>>>>>>> Hello All, >>>>>>>>> >>>>>>>>> Please review the below simple test fix for the issue, >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>>>>>>>> >>>>>>>>> with webrev located at, >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Harsha >>>>>>>>> > From staffan.larsen at oracle.com Tue Aug 16 07:53:56 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 16 Aug 2016 09:53:56 +0200 Subject: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found In-Reply-To: <80e01043-b3ac-0772-422e-4386f59dfe9d@oracle.com> References: <80e01043-b3ac-0772-422e-4386f59dfe9d@oracle.com> Message-ID: <249550CE-5EF4-42AE-BE26-3D2F19A14329@oracle.com> Thanks David! The matching logic is not that complicated (but it took me the better part of a day to figure all of this out.) The debugger sets a filter for which exceptions should be reported. Part of that filter includes a class reference. If the exception class IsInstanceOf() the class in the filter, the exception is reported to the debugger. When using patterns for matching, the debugger sets up such filters for all classes that match the pattern (this does sound a bit inefficient). /Staffan > On 15 aug. 2016, at 22:46, David Holmes wrote: > > Hi Staffan, > > Looks good. > > Though I do wonder how the matching logic works such that the superclass is considered. I suppose it is a "feature" to match on X and all subclasses of X, but probably should be a way to match on exactly X not subclasses. Anyway just idle thoughts. :) > > Thanks, > David > > On 16/08/2016 4:15 AM, Staffan Larsen wrote: >> All, >> >> Please review this fix for a test that starting failing after recent changes to java.lang.invoke. >> >> The test instructs jdb to break on all exceptions matching "java.lang.I*" (that's a capital 'i'). The semantics of that operation actually means "break on all exceptions which have a class name or superclass name matching this string". >> >> Some of the recent changes in java.lang.invoke now causes the code to throw numerous java.lang.NoSuchMethodErrors. This is a subclass of java.lang.IncompatibleClassChangeError, which matches "java.lang.I*". >> >> The net result is that jdb will break on a lot more places (all the NoSuchMethodError exceptions) than the test expects and the test fails. >> >> We can work around this in the test by changing this line: >> >> cmd catch all java.lang.I* >> >> to the following two lines: >> >> cmd catch all java.lang.Il* >> cmd catch all java.lang.Ind* >> >> This will still match the exception types the test is looking for (IllegalArgumentException, IllegalMonitorStateException, and IndexOutOfBoundsException), but it will not match IncompatibleClassChangeError. >> >> Thanks, >> /Staffan >> >> >> diff --git a/test/com/sun/jdi/CatchPatternTest.sh b/test/com/sun/jdi/CatchPatternTest.sh >> --- a/test/com/sun/jdi/CatchPatternTest.sh >> +++ b/test/com/sun/jdi/CatchPatternTest.sh >> @@ -87,7 +87,12 @@ >> cmd stop in ${classname}.partTwo >> runToBkpt >> cmd ignore uncaught java.lang.Throwable >> - cmd catch all java.lang.I* >> + # Instead of matching java.lang.I* we use two more specific >> + # patterns here. The reason is to avoid matching IncompatibleClassChangeError >> + # (or the subclass NoSuchMethodError) thrown by the >> + # java.lang.invoke infrastructure. >> + cmd catch all java.lang.Il* >> + cmd catch all java.lang.Ind* >> cmd cont >> cmd cont >> cmd cont >> From weijun.wang at oracle.com Tue Aug 16 08:00:31 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 16 Aug 2016 16:00:31 +0800 Subject: RFR 8160913: [TEST_BUG] javax/management/security/SecurityTest.java fails due to missing keyStore file In-Reply-To: References: Message-ID: <9ad9d938-0a5f-464d-29f8-5fad731f8f33@oracle.com> Looks fine to me. Thanks Max On 8/16/2016 14:19, Mallikarjuna Avaluri wrote: > Hi, > > Reminder, please help me with this review. > > > Regards, > > Mallikarjuna Avaluri > > > On 8/9/2016 11:11 AM, Mallikarjuna Avaluri wrote: >> Hi all, >> >> Could you please review fix for following issue. >> >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8160913 >> >> Summary: [TEST_BUG] javax/management/security/SecurityTest.java fails >> due to missing keyStore file >> >> Solution: Following files keystoreAgent, keystoreClient, >> truststoreAgent and truststoreClient were created under >> jdk/test/javax/management/ folder, >> while test expects them under jdk/test/javax/management/security/ >> path. Moved the files to correct folder. >> >> Webrev: >> http://cr.openjdk.java.net/~bgopularam/mavaluri/rev/8160913/webrev.00/ >> >> >> >> >> Thanks, >> Mallikarjuna Avaluri >> > From david.holmes at oracle.com Tue Aug 16 08:02:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Aug 2016 18:02:10 +1000 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> Message-ID: <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> Hi Harsha, On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: > Hello, > > Please review and provide comments for fix for issue, > > https://bugs.openjdk.java.net/browse/JDK-8152589 > > having webrev located at > > http://cr.openjdk.java.net/~hb/8152589/webrev.00/ These changes look quite good (though I have to admit I struggle to read the lambda and stream code :) ). Note that like many of these kinds of tests there is an issue with WaitingThread because it does not wait in a loop and so is susceptible to spurious wakeups. The way to fix that is to add a "notified" variable and then do: while (!notified) wait(); and set notified before the notify(). Thanks, David > Fix details: > > 1. From nightly failures we see that LockThreadB was blocked on wrong > object. We now do a repeated check with timeout if any given thread is > blocked on expected object. It is possible that LockThreadB might still > be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is invoked. > > 2. The logs from lock free logger was never printed. It is not being > printed. > > 3. Any time we see failure, thread stack is being logged. This helps us > ascertain if failure is in test case or in the component. > > 4. Even though we had lock free logger, several ex.printStackTrace() was > used which could be responsible for failure. It is removed. > > 5. There were several places where tests continue to ran even after > failure (testFailed flag). That is fixed. > > 6. Couple of other minor refactoring. > > Thanks > > Harsha > From harsha.wardhana.b at oracle.com Tue Aug 16 08:08:20 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 16 Aug 2016 13:38:20 +0530 Subject: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot In-Reply-To: <0E7F7B57-FD3F-4B1A-B09C-DA16194FBF46@oracle.com> References: <6e15998b-81a8-0f9e-37c2-12b9d1fd3df6@oracle.com> <57A892B6.3010703@oracle.com> <9ee73dae-84c5-6b27-5bab-fcf47015ef17@oracle.com> <19374B3B-6373-458F-B0A0-45D56798BDFE@oracle.com> <4d40553c-c8b1-ecbc-b9fc-7482f50449ce@oracle.com> <0497B367-0700-4C9A-B26E-08475BF01796@oracle.com> <0E7F7B57-FD3F-4B1A-B09C-DA16194FBF46@oracle.com> Message-ID: <26817096-662d-03f1-b921-c157d6c0562a@oracle.com> Thanks for the Review, Staffan. -Harsha On Tuesday 16 August 2016 01:17 PM, Staffan Larsen wrote: > Ok. Reviewed. > > /Staffan > >> On 16 aug. 2016, at 08:15, Harsha Wardhana B wrote: >> >> Yes. assertEQorGTE can be used. But using assertEQorLTE is better suited as it increase code readability. So I would like to leave that in place. >> >> >> On Saturday 13 August 2016 12:59 AM, Staffan Larsen wrote: >>> If you swap currUsage and peakUsage in the call to assertEQorLTE() you can use assertEQorGTE() and you won?t have to change CodeCacheUtils.java. Or am I missing something? >>> >>>> On 12 aug. 2016, at 17:26, Harsha Wardhana B wrote: >>>> >>>> Hi, >>>> >>>> Please review modified webrev incorporating Staffan's comments. >>>> >>>> http://cr.openjdk.java.net/~hb/8151345/webrev.01/ >>>> >>>> Thanks >>>> Harsha >>>> >>>> On Friday 12 August 2016 01:59 PM, Staffan Larsen wrote: >>>>> Harsha, >>>>> >>>>> Thanks for the explanation! With that in mind the new code looks correct, although I would probably make it even more obvious in which order getUsage() and getPeakUsage() is executed by calling them on separate lines before the call to assertEQorLTE() instead of relying on the order method parameters are evaluated. Relying on the order of evaluation is correct, but doing explicit calls would make it a lot more obvious that the order is important. >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>>> On 12 aug. 2016, at 10:07, Harsha Wardhana B wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I forgot to put-in the fix details. >>>>>> >>>>>> The test was failing because of a race condition caused by the order in which MemoryPoolMXBean.getUsage and MemoryPoolMXBean.getPeakUsage was invoked. It is possible that intermediate allocations can happen which can lead to getUsage > getPeakUsage if getUsage is called after getPeakUsage. The correct order would be to capture getUsage and then capture getPeakUsage in order to account for intermediate allocations. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Harsha >>>>>> >>>>>> >>>>>> On Thursday 11 August 2016 12:02 PM, Harsha Wardhana B wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could one of you please review the below fix? >>>>>>> >>>>>>> Thanks >>>>>>> Harsha >>>>>>> >>>>>>> On Monday 08 August 2016 07:49 PM, Leonid Mesnik wrote: >>>>>>>> Please use following alias for compiler tests (hotspot/test/compiler): >>>>>>>> >>>>>>>> hotspot-compiler-dev at openjdk.java.net >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>>>> >>>>>>>> On 08.08.2016 17:09, Harsha wardhana B wrote: >>>>>>>>> Gentle Reminder !! >>>>>>>>> >>>>>>>>> On 8/4/2016 9:49 PM, Harsha Wardhana B wrote: >>>>>>>>>> Hello All, >>>>>>>>>> >>>>>>>>>> Please review the below simple test fix for the issue, >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151345 >>>>>>>>>> >>>>>>>>>> with webrev located at, >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~hb/8151345/webrev.00/ >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Harsha >>>>>>>>>> From yasuenag at gmail.com Tue Aug 16 12:31:47 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 16 Aug 2016 21:31:47 +0900 Subject: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap In-Reply-To: References: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> Message-ID: Hi all, Have you checked changes for this issue? http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/hotspot/ http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ For example, ParallelScavengeHeap.java overrides printOn() method. This method shows addresses of each memory regions. My proposal shows memory region of G1CollectedHeap and region size. Please review and sponsor for it. If it is not enough, please tell me. Thanks, Yasumasa On 2016/08/11 23:15, Yasumasa Suenaga wrote: > Hi Jini, > > I added this check in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ > > > Thanks, > > Yasumasa > > > On 2016/08/11 15:33, Jini Susan George wrote: >> Thank you for this fix, Yasumasa. This issue was manifested through the 'universe' command in clhsdb also, and your change fixes that. It would be great if you could modify BasicLauncherTest.java to have some testing done for this also. >> >> Thank you, >> Jini (Not a Reviewer). >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Thursday, August 11, 2016 10:03 AM >>> To: Yasumasa Suenaga; serviceability-dev at openjdk.java.net; hotspot-gc- >>> dev at openjdk.java.net >>> Subject: Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle >>> G1CollectedHeap >>> >>> Hi Yasumasa, >>> >>> Adding in GC folk. >>> >>> I agree with the need to override the printOn method, but can't comment >>> on the details of what you are actually printing. >>> >>> Thanks, >>> David >>> >>> On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> When I chose "Heap Parameters" menu in HSDB, I got following value: >>>> -------------------- >>>> Heap Parameters: >>>> unknown subtype of CollectedHeap @ 0x00007f4d4c030510 >>>> (0x00000006c6e00000,0x00000007c0000000) >>>> -------------------- >>>> >>>> I think it should not be "unknown subtype". >>>> >>>> This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). >>>> This method is overrided in ParallelScavengeHeap and GenCollectedHeap. >>>> However, G1CollectedHeap does not override. >>>> >>>> I think G1CollectedHeap should override this method. >>>> >>>> I uploaded a webrev for this issue. >>>> Could you review it? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ >>>> >>>> I'm jdk 9 committer, but I cannot access JPRT. >>>> So I need a sponsor. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> From harsha.wardhana.b at oracle.com Tue Aug 16 13:33:39 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 16 Aug 2016 19:03:39 +0530 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> Message-ID: <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> Hi David, Agreed that we could fix WaitingThread the way you have said, but in recent past, there aren't any issues reported w.r.t WaitingThread. This test has been fixed several times (3-4) for intermittent failures and hence I would not like to meddle with code that is not causing any problems even though there is scope for refactoring. The issue reported was with LockThreadB and hence I have provided possible fix for the same. Thanks Harsha On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: > Hi Harsha, > > On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >> Hello, >> >> Please review and provide comments for fix for issue, >> >> https://bugs.openjdk.java.net/browse/JDK-8152589 >> >> having webrev located at >> >> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ > > These changes look quite good (though I have to admit I struggle to > read the lambda and stream code :) ). > > Note that like many of these kinds of tests there is an issue with > WaitingThread because it does not wait in a loop and so is susceptible > to spurious wakeups. The way to fix that is to add a "notified" > variable and then do: > > while (!notified) > wait(); > > and set notified before the notify(). > > Thanks, > David > >> Fix details: >> >> 1. From nightly failures we see that LockThreadB was blocked on wrong >> object. We now do a repeated check with timeout if any given thread is >> blocked on expected object. It is possible that LockThreadB might still >> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >> invoked. >> >> 2. The logs from lock free logger was never printed. It is not being >> printed. >> >> 3. Any time we see failure, thread stack is being logged. This helps us >> ascertain if failure is in test case or in the component. >> >> 4. Even though we had lock free logger, several ex.printStackTrace() was >> used which could be responsible for failure. It is removed. >> >> 5. There were several places where tests continue to ran even after >> failure (testFailed flag). That is fixed. >> >> 6. Couple of other minor refactoring. >> >> Thanks >> >> Harsha >> From david.holmes at oracle.com Wed Aug 17 03:01:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Aug 2016 13:01:21 +1000 Subject: Setting JVMTI Capabilities when VM is in "Live Phase" In-Reply-To: References: <3d486133-a635-638c-fcc2-18230c694b2f@oracle.com> <716a0ec1-b6d9-0c18-4a55-ffb889dcc633@oracle.com> Message-ID: <352ff2e6-c8f4-cfe3-fa67-4e63387b6f80@oracle.com> On 17/08/2016 6:57 AM, Leela Mohan wrote: > Your thoughts on this will be helpful. > > Thanks, > Leela > > [ Removed "serviceability-dev at openjdk.net" mailing alias added > "hotspot-dev" since i am getting failed mail delivery notification ] Added back - it is openjdk.java.net, not openjdk.net David ----- > On Fri, Aug 12, 2016 at 4:33 PM, Daniel D. Daugherty < > daniel.daugherty at oracle.com> wrote: > >> On 8/12/16 5:27 PM, Leela Mohan wrote: >> >> Hi Daniel, >> >> Actually, I was thinking about the case where compiler choose not to have >> complete "de-opt" state. For ex: Local pruning. I can also think of other >> cases which need callback events like, posting exceptions to the agent. >> >> JVMTI requests for examining/changing the stack frame would conservatively >> de-optimize the compile methods but not all de-optimizable locations can >> restore the java state user expect. >> >> What are the expectations for VM for these cases ? >> >> >> I think we'll have to wait for someone more current in how the compilers >> interact with JVM/TI to chime in here. I stopped actively working on >> JVM/TI back in 2010 or so... :-) >> >> Dan >> >> >> >> Thanks, >> Leela >> >> On Fri, Aug 12, 2016 at 4:04 PM, Daniel D. Daugherty < >> daniel.daugherty at oracle.com> wrote: >> >>> On 8/12/16 4:21 PM, Leela Mohan wrote: >>> >>>> Hi experts, >>>> >>>> It looks like, we don't disallow setting capabilities when VM is in >>>> "JVMTI_PHASE_LIVE". And, I notice, for every new compilation of method, >>>> ciEnv caches the JVMTI state and expects those assumptions to be true >>>> during the compilation. Otherwise, dump the compiled method. >>>> >>>> However, we don't seem to do anything with the methods which were >>>> compiled >>>> before setting the capability. >>>> >>>> What is the understanding? >>>> >>>> Thanks, >>>> Leela >>>> >>> >>> Hi Leela, >>> >>> I'm guessing that you are talking about this capability: >>> >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.ht >>> ml#jvmtiCapabilities.can_generate_compiled_method_load_events >>> >>> and this event: >>> >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.ht >>> ml#CompiledMethodLoad >>> >>> >>> The can_generate_compiled_method_load_events capability needs to be added >>> in order to generate CompiledMethodLoad events. Capabilities are added via >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.ht >>> ml#AddCapabilities >>> which can be called from different JVM/TI phases. Different VM >>> implementations >>> can require that certain capabilities can only be added in certain JVM/TI >>> phases. >>> However, if AddCapabilities() does not return a JVM/TI error when a >>> capability >>> is added in a phase, e.g., the live phase, then you can safely assume that >>> the capability has been added. >>> >>> >>> In your example, it sounds like the capability is added in the live phase >>> because you are seeing events generated for newly compiled methods. In >>> order >>> to see synthetic events for methods that were compiled before you added >>> the >>> capability, your agent needs to use a different function: >>> >>> http://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.ht >>> ml#GenerateEvents >>> >>> The documentation for Compiled Method Load has this line: >>> >>>> These events can be sent after their initial occurrence with >>> GenerateEvents. >>> >>> and that sounds just like your situation. >>> >>> Hope this helps. >>> >>> Dan >>> >>> >> >> From david.holmes at oracle.com Wed Aug 17 03:32:43 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Aug 2016 13:32:43 +1000 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> Message-ID: <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: > Hi David, > > Agreed that we could fix WaitingThread the way you have said, but in > recent past, there aren't any issues reported w.r.t WaitingThread. Nor are there likely to be - that's what makes spurious wakeup bugs so difficult to detect! > This test has been fixed several times (3-4) for intermittent failures > and hence I would not like to meddle with code that is not causing any > problems even though there is scope for refactoring. It isn't refactoring it is fixing and we have fixed several tests in a similar way. > The issue reported was with LockThreadB and hence I have provided > possible fix for the same. That doesn't preclude fixing other issues with the test at the same time. David > Thanks > > Harsha > > > On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >> Hi Harsha, >> >> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>> Hello, >>> >>> Please review and provide comments for fix for issue, >>> >>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>> >>> having webrev located at >>> >>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >> >> These changes look quite good (though I have to admit I struggle to >> read the lambda and stream code :) ). >> >> Note that like many of these kinds of tests there is an issue with >> WaitingThread because it does not wait in a loop and so is susceptible >> to spurious wakeups. The way to fix that is to add a "notified" >> variable and then do: >> >> while (!notified) >> wait(); >> >> and set notified before the notify(). >> >> Thanks, >> David >> >>> Fix details: >>> >>> 1. From nightly failures we see that LockThreadB was blocked on wrong >>> object. We now do a repeated check with timeout if any given thread is >>> blocked on expected object. It is possible that LockThreadB might still >>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>> invoked. >>> >>> 2. The logs from lock free logger was never printed. It is not being >>> printed. >>> >>> 3. Any time we see failure, thread stack is being logged. This helps us >>> ascertain if failure is in test case or in the component. >>> >>> 4. Even though we had lock free logger, several ex.printStackTrace() was >>> used which could be responsible for failure. It is removed. >>> >>> 5. There were several places where tests continue to ran even after >>> failure (testFailed flag). That is fixed. >>> >>> 6. Couple of other minor refactoring. >>> >>> Thanks >>> >>> Harsha >>> > From harsha.wardhana.b at oracle.com Wed Aug 17 06:15:32 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 17 Aug 2016 11:45:32 +0530 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> Message-ID: <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> Hi David, I will incorporate changes suggested by you. Let's wait for few more review comments and then I will send consolidated webrev. Regards Harsha On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: > On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >> Hi David, >> >> Agreed that we could fix WaitingThread the way you have said, but in >> recent past, there aren't any issues reported w.r.t WaitingThread. > > Nor are there likely to be - that's what makes spurious wakeup bugs so > difficult to detect! > >> This test has been fixed several times (3-4) for intermittent failures >> and hence I would not like to meddle with code that is not causing any >> problems even though there is scope for refactoring. > > It isn't refactoring it is fixing and we have fixed several tests in a > similar way. > >> The issue reported was with LockThreadB and hence I have provided >> possible fix for the same. > > That doesn't preclude fixing other issues with the test at the same time. > > David > >> Thanks >> >> Harsha >> >> >> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>> Hi Harsha, >>> >>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>> Hello, >>>> >>>> Please review and provide comments for fix for issue, >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>> >>>> having webrev located at >>>> >>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>> >>> These changes look quite good (though I have to admit I struggle to >>> read the lambda and stream code :) ). >>> >>> Note that like many of these kinds of tests there is an issue with >>> WaitingThread because it does not wait in a loop and so is susceptible >>> to spurious wakeups. The way to fix that is to add a "notified" >>> variable and then do: >>> >>> while (!notified) >>> wait(); >>> >>> and set notified before the notify(). >>> >>> Thanks, >>> David >>> >>>> Fix details: >>>> >>>> 1. From nightly failures we see that LockThreadB was blocked on wrong >>>> object. We now do a repeated check with timeout if any given thread is >>>> blocked on expected object. It is possible that LockThreadB might >>>> still >>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>>> invoked. >>>> >>>> 2. The logs from lock free logger was never printed. It is not being >>>> printed. >>>> >>>> 3. Any time we see failure, thread stack is being logged. This >>>> helps us >>>> ascertain if failure is in test case or in the component. >>>> >>>> 4. Even though we had lock free logger, several >>>> ex.printStackTrace() was >>>> used which could be responsible for failure. It is removed. >>>> >>>> 5. There were several places where tests continue to ran even after >>>> failure (testFailed flag). That is fixed. >>>> >>>> 6. Couple of other minor refactoring. >>>> >>>> Thanks >>>> >>>> Harsha >>>> >> From dmitry.samersoff at oracle.com Wed Aug 17 07:51:40 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 17 Aug 2016 10:51:40 +0300 Subject: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools Message-ID: Everybody, Please review the changes: http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From sharath.ballal at oracle.com Wed Aug 17 16:12:03 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 17 Aug 2016 09:12:03 -0700 (PDT) Subject: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. In-Reply-To: <8ad9f953-205a-c331-e642-46016eefc740@oracle.com> References: <8ad9f953-205a-c331-e642-46016eefc740@oracle.com> Message-ID: Hello Dmitry, Thanks for the review. I have done the changes, pls have a look: http://cr.openjdk.java.net/~sballal/8163346/webrev.01/ -Sharath Ballal -----Original Message----- From: Dmitry Samersoff Sent: Wednesday, August 10, 2016 1:16 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. Sharath, As soon as you request a heap dump of LingeredApp, LingeredApp should contains the object with extended characters in it's name. So please: 1. Inherit LingeredApp (See LingeredAppWithDeadlock as an example) and add public static int \u00CB = 1; 2. Copy BasicLauncherTest to HeapDumpWitExtCharsTest.java and change it according to you needs (i.e. remove everything but heapDumpTest) 3. Remove Test8028623.java -Dmitry On 2016-08-08 12:37, Sharath Ballal wrote: > Hello, > > Pls review the following fix for modifying the testcase > jmap-hashcode/Test8028623.java to use LingeredApp. > > > > http://cr.openjdk.java.net/~sballal/8163346/webrev.00/ > > > > Link to bug: https://bugs.openjdk.java.net/browse/JDK-8163346 > > > > -Sharath Ballal > > > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From amit.sapre at oracle.com Thu Aug 18 05:53:56 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Wed, 17 Aug 2016 22:53:56 -0700 (PDT) Subject: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly In-Reply-To: References: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> <0607b181-0227-bb91-4b71-f141ae1798c9@oracle.com> Message-ID: Guys, I need one more person to review these changes. Kindly help with the review. Thanks, Amit -----Original Message----- From: David Holmes Sent: Thursday, August 11, 2016 5:55 AM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly On 10/08/2016 8:46 PM, Amit Sapre wrote: > Hello, > Well for some reason, unknown to me, JNI code checker is not > complaining for exception thrown by SetObjectArrayElement. It complains for any pending exceptions before calling SetObjectArrayElement. > > I have added exceptions checks after calling SetObjectArrayElement. The updated changes are in this webrev. > > http://cr.openjdk.java.net/~sballal/sponsorship/8162530/webrev.02/ This looks fine to me. Thanks, David > Thanks, > Amit > > > > -----Original Message----- > From: David Holmes > Sent: Wednesday, August 03, 2016 5:50 AM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8162530 : > src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c > doesn't handle JNI exceptions properly > > Hi Amit, > > On 2/08/2016 7:49 PM, Amit Sapre wrote: >> Hello, >> I have made changes as David suggested. >> >> Here is the new webrev link. >> http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ > > If the changes are required to pass a JNI code checker then you will also need to check for exceptions from SetObjectArrayElement. While ArrayStoreException should not be possible in this code, I can't tell for certain that the passed in arrays are ensured to have the required lengths. > > Thanks, > David > >> Thanks, >> Amit >> >> -----Original Message----- >> From: David Holmes >> Sent: Monday, August 01, 2016 12:33 PM >> To: Amit Sapre; serviceability-dev >> Subject: Re: RFR : JDK-8162530 : >> src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c >> doesn't handle JNI exceptions properly >> >> Hi Amit, >> >> On 1/08/2016 4:10 PM, Amit Sapre wrote: >>> Hello, >>> >>> >>> >>> Please review JNI exception handling related changes. >>> >>> Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 >>> >>> Webrev : >>> http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ >> >> Sorry but that's wrong way to fix this. We should never just blindly clear exceptions and continue as if they never happened. If an exception is pending after one of these JNI calls the method should return immediately and allow the exception to propagate to the java code. >> >> Thanks, >> David >> >>> >>> >>> Thanks, >>> >>> Amit >>> From staffan.larsen at oracle.com Thu Aug 18 08:42:28 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 18 Aug 2016 10:42:28 +0200 Subject: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly In-Reply-To: References: <0d1257e5-f4c1-4709-99f0-14d5eebcc7ed@default> <0607b181-0227-bb91-4b71-f141ae1798c9@oracle.com> Message-ID: <331205A1-A93C-4504-8072-2CDC780FEF0A@oracle.com> Looks good! Thanks, /Staffan > On 18 aug. 2016, at 07:53, Amit Sapre wrote: > > Guys, > I need one more person to review these changes. Kindly help with the review. > Thanks, > Amit > > -----Original Message----- > From: David Holmes > Sent: Thursday, August 11, 2016 5:55 AM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8162530 : src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly > > On 10/08/2016 8:46 PM, Amit Sapre wrote: >> Hello, >> Well for some reason, unknown to me, JNI code checker is not >> complaining for exception thrown by SetObjectArrayElement. It complains for any pending exceptions before calling SetObjectArrayElement. >> >> I have added exceptions checks after calling SetObjectArrayElement. The updated changes are in this webrev. >> >> http://cr.openjdk.java.net/~sballal/sponsorship/8162530/webrev.02/ > > > This looks fine to me. > > Thanks, > David > >> Thanks, >> Amit >> >> >> >> -----Original Message----- >> From: David Holmes >> Sent: Wednesday, August 03, 2016 5:50 AM >> To: Amit Sapre; serviceability-dev >> Subject: Re: RFR : JDK-8162530 : >> src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c >> doesn't handle JNI exceptions properly >> >> Hi Amit, >> >> On 2/08/2016 7:49 PM, Amit Sapre wrote: >>> Hello, >>> I have made changes as David suggested. >>> >>> Here is the new webrev link. >>> http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.01/ >> >> If the changes are required to pass a JNI code checker then you will also need to check for exceptions from SetObjectArrayElement. While ArrayStoreException should not be possible in this code, I can't tell for certain that the passed in arrays are ensured to have the required lengths. >> >> Thanks, >> David >> >>> Thanks, >>> Amit >>> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Monday, August 01, 2016 12:33 PM >>> To: Amit Sapre; serviceability-dev >>> Subject: Re: RFR : JDK-8162530 : >>> src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c >>> doesn't handle JNI exceptions properly >>> >>> Hi Amit, >>> >>> On 1/08/2016 4:10 PM, Amit Sapre wrote: >>>> Hello, >>>> >>>> >>>> >>>> Please review JNI exception handling related changes. >>>> >>>> Bug id : https://bugs.openjdk.java.net/browse/JDK-8162530 >>>> >>>> Webrev : >>>> http://cr.openjdk.java.net/~hb/sponsorship/8162530/webrev.00/ >>> >>> Sorry but that's wrong way to fix this. We should never just blindly clear exceptions and continue as if they never happened. If an exception is pending after one of these JNI calls the method should return immediately and allow the exception to propagate to the java code. >>> >>> Thanks, >>> David >>> >>>> >>>> >>>> Thanks, >>>> >>>> Amit >>>> From yasuenag at gmail.com Thu Aug 18 13:51:12 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 18 Aug 2016 22:51:12 +0900 Subject: RFR: JDK-8164319: CLHSDB dumpcodecache throws StackOverflowError Message-ID: Hi all, I encountered StackOverflowError when I run dumpcodecache command in CLHSDB: ------------ hsdb> dumpcodecache Exception in thread "main" java.lang.StackOverflowError at sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) at sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) at sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) at sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) at sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) : ------------ CodeBlob#getName() calls itself recursively. Thus it occurs StackOverflowError. http://hg.openjdk.java.net/jdk9/hs/hotspot/file/e99e410e78e1/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java#l117 I uploaded webrev for this issue. Could you reivew it? http://cr.openjdk.java.net/~ysuenaga/JDK-8164319/webrev.00/ I also need a sponsor. Thanks, Yasumasa From mark.reinhold at oracle.com Thu Aug 18 21:56:51 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 18 Aug 2016 14:56:51 -0700 Subject: OpenJDK Governing Board CFV: New Serviceability Group Lead: Staffan Larsen In-Reply-To: <20160812172717.338810722eggemoggin.niobe.net> References: <20160812172717.338810722eggemoggin.niobe.net> Message-ID: <20160818145651.208412019eggemoggin.niobe.net> 2016/8/12 17:27:17 -0700, mark.reinhold at oracle.com: > Dan Daugherty recently resigned as the Serviceability Group Lead [1]. > Staffan Larsen was voted in as the new Lead shortly thereafter [2]. > > Governing Board members: Please vote on whether to ratify this change, > as required by the Bylaws [3]. Votes are due in one week, by 01:00 UTC > next Saturday, 20 August 2016. Votes must be cast in the open by > replying to this message. > > For Simple Majority voting instructions, see [4]. Thank you for your votes. A majority has voted in favor of ratification. Staffan Larsen is now the Lead of the Serviceability Group. - Mark From david.holmes at oracle.com Fri Aug 19 01:44:48 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Aug 2016 11:44:48 +1000 Subject: RFR: JDK-8164319: CLHSDB dumpcodecache throws StackOverflowError In-Reply-To: References: Message-ID: <141e6432-66b5-5cc2-bf9c-a08b548ad1d5@oracle.com> On 18/08/2016 11:51 PM, Yasumasa Suenaga wrote: > Hi all, > > I encountered StackOverflowError when I run dumpcodecache command in > CLHSDB: > > ------------ > hsdb> dumpcodecache > Exception in thread "main" java.lang.StackOverflowError > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > : > ------------ > > CodeBlob#getName() calls itself recursively. > Thus it occurs StackOverflowError. > http://hg.openjdk.java.net/jdk9/hs/hotspot/file/e99e410e78e1/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java#l117 > > > I uploaded webrev for this issue. > Could you reivew it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8164319/webrev.00/ Looks good. Bug was introduced by a refactoring of the code. > I also need a sponsor. Will do so if noone else claims it before the US weekend. :) Thanks, David > > Thanks, > > Yasumasa From dmitry.samersoff at oracle.com Fri Aug 19 05:00:15 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 19 Aug 2016 08:00:15 +0300 Subject: RFR: JDK-8164319: CLHSDB dumpcodecache throws StackOverflowError In-Reply-To: References: Message-ID: <79af3d55-b079-66c4-b5e3-269c1768000c@oracle.com> Yasumasa, Looks good for me! -Dmitry On 2016-08-18 16:51, Yasumasa Suenaga wrote: > Hi all, > > I encountered StackOverflowError when I run dumpcodecache command in > CLHSDB: > > ------------ > hsdb> dumpcodecache > Exception in thread "main" java.lang.StackOverflowError > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > at > sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) > > : > ------------ > > CodeBlob#getName() calls itself recursively. > Thus it occurs StackOverflowError. > http://hg.openjdk.java.net/jdk9/hs/hotspot/file/e99e410e78e1/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java#l117 > > > I uploaded webrev for this issue. > Could you reivew it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8164319/webrev.00/ > > I also need a sponsor. > > > Thanks, > > Yasumasa -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Fri Aug 19 05:22:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Aug 2016 15:22:00 +1000 Subject: RFR: JDK-8164319: CLHSDB dumpcodecache throws StackOverflowError In-Reply-To: <79af3d55-b079-66c4-b5e3-269c1768000c@oracle.com> References: <79af3d55-b079-66c4-b5e3-269c1768000c@oracle.com> Message-ID: <0c113c59-ee0d-f219-623b-855aed6a195c@oracle.com> Thanks Dmitry! I've submitted this to JPRT. David On 19/08/2016 3:00 PM, Dmitry Samersoff wrote: > Yasumasa, > > Looks good for me! > > -Dmitry > > On 2016-08-18 16:51, Yasumasa Suenaga wrote: >> Hi all, >> >> I encountered StackOverflowError when I run dumpcodecache command in >> CLHSDB: >> >> ------------ >> hsdb> dumpcodecache >> Exception in thread "main" java.lang.StackOverflowError >> at >> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >> >> at >> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >> >> at >> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >> >> at >> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >> >> at >> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >> >> : >> ------------ >> >> CodeBlob#getName() calls itself recursively. >> Thus it occurs StackOverflowError. >> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/e99e410e78e1/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java#l117 >> >> >> I uploaded webrev for this issue. >> Could you reivew it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8164319/webrev.00/ >> >> I also need a sponsor. >> >> >> Thanks, >> >> Yasumasa > > From yasuenag at gmail.com Fri Aug 19 07:15:24 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 19 Aug 2016 16:15:24 +0900 Subject: RFR: JDK-8164319: CLHSDB dumpcodecache throws StackOverflowError In-Reply-To: <0c113c59-ee0d-f219-623b-855aed6a195c@oracle.com> References: <79af3d55-b079-66c4-b5e3-269c1768000c@oracle.com> <0c113c59-ee0d-f219-623b-855aed6a195c@oracle.com> Message-ID: <2d1fd04c-2572-7c47-a050-b4f04eac413f@gmail.com> Thanks David and Dmitry! Yasumasa On 2016/08/19 14:22, David Holmes wrote: > Thanks Dmitry! I've submitted this to JPRT. > > David > > On 19/08/2016 3:00 PM, Dmitry Samersoff wrote: >> Yasumasa, >> >> Looks good for me! >> >> -Dmitry >> >> On 2016-08-18 16:51, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> I encountered StackOverflowError when I run dumpcodecache command in >>> CLHSDB: >>> >>> ------------ >>> hsdb> dumpcodecache >>> Exception in thread "main" java.lang.StackOverflowError >>> at >>> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >>> >>> at >>> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >>> >>> at >>> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >>> >>> at >>> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >>> >>> at >>> sun.jvm.hotspot.code.CodeBlob.getName(jdk.hotspot.agent at 9-ea/CodeBlob.java:118) >>> >>> : >>> ------------ >>> >>> CodeBlob#getName() calls itself recursively. >>> Thus it occurs StackOverflowError. >>> http://hg.openjdk.java.net/jdk9/hs/hotspot/file/e99e410e78e1/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java#l117 >>> >>> >>> I uploaded webrev for this issue. >>> Could you reivew it? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8164319/webrev.00/ >>> >>> I also need a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >> >> From dmitry.samersoff at oracle.com Fri Aug 19 10:20:35 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 19 Aug 2016 13:20:35 +0300 Subject: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. In-Reply-To: References: <8ad9f953-205a-c331-e642-46016eefc740@oracle.com> Message-ID: <9223accd-8611-7b2c-dd00-1a136783b4ff@oracle.com> Sharath, Looks good for me. Please, move LingeredAppWithExtendedChars.java to the test directory, it's test-specific code and it shouldn't be in the library (no need for re-review). -Dmitry On 2016-08-17 19:12, Sharath Ballal wrote: > Hello Dmitry, > Thanks for the review. I have done the changes, pls have a look: > > http://cr.openjdk.java.net/~sballal/8163346/webrev.01/ > > -Sharath Ballal > > > -----Original Message----- > From: Dmitry Samersoff > Sent: Wednesday, August 10, 2016 1:16 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. > > Sharath, > > As soon as you request a heap dump of LingeredApp, LingeredApp should contains the object with extended characters in it's name. > > So please: > > 1. Inherit LingeredApp (See LingeredAppWithDeadlock as an example) and add > > public static int \u00CB = 1; > > 2. Copy BasicLauncherTest to HeapDumpWitExtCharsTest.java and change it according to you needs (i.e. remove everything but > heapDumpTest) > > 3. Remove Test8028623.java > > -Dmitry > > > On 2016-08-08 12:37, Sharath Ballal wrote: >> Hello, >> >> Pls review the following fix for modifying the testcase >> jmap-hashcode/Test8028623.java to use LingeredApp. >> >> >> >> http://cr.openjdk.java.net/~sballal/8163346/webrev.00/ >> >> >> >> Link to bug: https://bugs.openjdk.java.net/browse/JDK-8163346 >> >> >> >> -Sharath Ballal >> >> >> >> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From erik.gahlin at oracle.com Sat Aug 20 18:49:11 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sat, 20 Aug 2016 20:49:11 +0200 Subject: 8164523: Clean up metadata for event based tracing Message-ID: <57B8A627.40504@oracle.com> Hi, Could I have review of this fix to the event tracing metadata. The patch touches many files, but it doesn't change the control flow, only class and field names. Webrev: http://cr.openjdk.java.net/~egahlin/8164523/ Bug: https://bugs.openjdk.java.net/browse/JDK-8164523 Thanks Erik From claes.redestad at oracle.com Sat Aug 20 20:21:37 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 20 Aug 2016 22:21:37 +0200 Subject: 8164523: Clean up metadata for event based tracing In-Reply-To: <57B8A627.40504@oracle.com> References: <57B8A627.40504@oracle.com> Message-ID: <57B8BBD1.6000609@oracle.com> +1 /Claes On 2016-08-20 20:49, Erik Gahlin wrote: > Hi, > > Could I have review of this fix to the event tracing metadata. The patch > touches many files, but it doesn't change the control flow, only class > and field names. > > Webrev: > http://cr.openjdk.java.net/~egahlin/8164523/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8164523 > > Thanks > Erik From harsha.wardhana.b at oracle.com Mon Aug 22 01:51:09 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 22 Aug 2016 07:21:09 +0530 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: References: Message-ID: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> Hello All, Please find revised webrev located at, http://cr.openjdk.java.net/~hb/8131061/webrev.01/ The new patch has below changes. 1. AgentProvider is made abstract class. 2. Loading SNMP Agent provider is done in a AccessController.doPreviliged block. Thanks Harsha On Friday 12 August 2016 10:31 AM, Harsha Wardhana B wrote: > > Hi All, > > Please review fix for issue, > > JDK-8131061 - Use > of -Dcom.sun.management.snmp needs to be examined for modules > > with webrev located at, > > http://cr.openjdk.java.net/~hb/8131061/webrev.00/ > > Regards > > Harsha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Mon Aug 22 03:29:32 2016 From: jini.george at oracle.com (Jini Susan George) Date: Sun, 21 Aug 2016 20:29:32 -0700 (PDT) Subject: RFR: 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" Message-ID: <8aec9a50-f21d-498f-8098-7b8cb22b6e30@default> Hello, Could I please get a review for: https://bugs.openjdk.java.net/browse/JDK-8163150 Webrev: http://cr.openjdk.java.net/~jgeorge/8163150/webrev.00/ The test BasicLauncherTest.java includes code leveraged from Yasumasa's webrev for JDK-8163581. Thanks, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.gronlund at oracle.com Mon Aug 22 08:25:29 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 22 Aug 2016 01:25:29 -0700 (PDT) Subject: 8164523: Clean up metadata for event based tracing In-Reply-To: <57B8A627.40504@oracle.com> References: <57B8A627.40504@oracle.com> Message-ID: <369b8823-2d2c-4e18-988f-19b6aada13ac@default> Hi Erik, This looks good, thanks for cleaning this up. Thanks Markus -----Original Message----- From: Erik Gahlin Sent: den 20 augusti 2016 20:49 To: serviceability-dev at openjdk.java.net Subject: 8164523: Clean up metadata for event based tracing Hi, Could I have review of this fix to the event tracing metadata. The patch touches many files, but it doesn't change the control flow, only class and field names. Webrev: http://cr.openjdk.java.net/~egahlin/8164523/ Bug: https://bugs.openjdk.java.net/browse/JDK-8164523 Thanks Erik From harsha.wardhana.b at oracle.com Mon Aug 22 08:30:48 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 22 Aug 2016 14:00:48 +0530 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c Message-ID: Hello All, Please review the below parfait fixes for DiagnosticCommandImpl.c Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ Regards Harsha From harsha.wardhana.b at oracle.com Mon Aug 22 08:48:32 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 22 Aug 2016 14:18:32 +0530 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> Message-ID: <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> Hello, Please review the below webrev incorporating David's comments. http://cr.openjdk.java.net/~hb/8152589/webrev.01/ Regards Harsha On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: > Hi David, > > I will incorporate changes suggested by you. Let's wait for few more > review comments and then I will send consolidated webrev. > > Regards > Harsha > > On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>> Hi David, >>> >>> Agreed that we could fix WaitingThread the way you have said, but in >>> recent past, there aren't any issues reported w.r.t WaitingThread. >> >> Nor are there likely to be - that's what makes spurious wakeup bugs >> so difficult to detect! >> >>> This test has been fixed several times (3-4) for intermittent failures >>> and hence I would not like to meddle with code that is not causing any >>> problems even though there is scope for refactoring. >> >> It isn't refactoring it is fixing and we have fixed several tests in >> a similar way. >> >>> The issue reported was with LockThreadB and hence I have provided >>> possible fix for the same. >> >> That doesn't preclude fixing other issues with the test at the same >> time. >> >> David >> >>> Thanks >>> >>> Harsha >>> >>> >>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>> Hi Harsha, >>>> >>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>> Hello, >>>>> >>>>> Please review and provide comments for fix for issue, >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>> >>>>> having webrev located at >>>>> >>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>> >>>> These changes look quite good (though I have to admit I struggle to >>>> read the lambda and stream code :) ). >>>> >>>> Note that like many of these kinds of tests there is an issue with >>>> WaitingThread because it does not wait in a loop and so is susceptible >>>> to spurious wakeups. The way to fix that is to add a "notified" >>>> variable and then do: >>>> >>>> while (!notified) >>>> wait(); >>>> >>>> and set notified before the notify(). >>>> >>>> Thanks, >>>> David >>>> >>>>> Fix details: >>>>> >>>>> 1. From nightly failures we see that LockThreadB was blocked on wrong >>>>> object. We now do a repeated check with timeout if any given >>>>> thread is >>>>> blocked on expected object. It is possible that LockThreadB might >>>>> still >>>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>>>> invoked. >>>>> >>>>> 2. The logs from lock free logger was never printed. It is not being >>>>> printed. >>>>> >>>>> 3. Any time we see failure, thread stack is being logged. This >>>>> helps us >>>>> ascertain if failure is in test case or in the component. >>>>> >>>>> 4. Even though we had lock free logger, several >>>>> ex.printStackTrace() was >>>>> used which could be responsible for failure. It is removed. >>>>> >>>>> 5. There were several places where tests continue to ran even after >>>>> failure (testFailed flag). That is fixed. >>>>> >>>>> 6. Couple of other minor refactoring. >>>>> >>>>> Thanks >>>>> >>>>> Harsha >>>>> >>> > From amit.sapre at oracle.com Mon Aug 22 09:09:12 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Mon, 22 Aug 2016 02:09:12 -0700 (PDT) Subject: RFR : JDK-8066635 - Fix deprecation warnings in java.management module Message-ID: Hello, Please review changes for fixing deprecation warnings. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8066635 Webrev : http://cr.openjdk.java.net/~sballal/sponsorship/8066635/webrev.00/ Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.larsson at oracle.com Mon Aug 22 14:38:36 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 22 Aug 2016 16:38:36 +0200 Subject: 8164523: Clean up metadata for event based tracing In-Reply-To: <57B8A627.40504@oracle.com> References: <57B8A627.40504@oracle.com> Message-ID: Hi, On 08/20/2016 08:49 PM, Erik Gahlin wrote: > Hi, > > Could I have review of this fix to the event tracing metadata. The > patch touches many files, but it doesn't change the control flow, only > class and field names. > > Webrev: > http://cr.openjdk.java.net/~egahlin/8164523/ Looks good to me! Thanks, Marcus > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8164523 > > Thanks > Erik From mandy.chung at oracle.com Mon Aug 22 21:58:01 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 22 Aug 2016 14:58:01 -0700 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> Message-ID: <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> Hi Harsha, This looks reasonable. Some comments: sun/management/Agent.java 567 ServiceLoader providers = ServiceLoader.load(AgentProvider.class); It should call ServiceLoader::loadInstalled since it should only load the providers from the platform modules. You can also simplify line 567-570 to: for (AgentProvider provider : ServiceLoader.loadInstalled(AgentProvider.class)) { : } sun/management/spi/AgentProvider.java 78 public abstract void startAgent(String port, Properties props); The port parameter should be ?int?. There are a few references to ?Agent? that should be ?agent?, as it?s not a type name. Mandy > On Aug 21, 2016, at 6:51 PM, Harsha Wardhana B wrote: > > Hello All, > > Please find revised webrev located at, > > http://cr.openjdk.java.net/~hb/8131061/webrev.01/ > > The new patch has below changes. > > 1. AgentProvider is made abstract class. > 2. Loading SNMP Agent provider is done in a AccessController.doPreviliged block. > > Thanks > Harsha > > On Friday 12 August 2016 10:31 AM, Harsha Wardhana B wrote: >> Hi All, >> >> Please review fix for issue, >> >> JDK-8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules >> with webrev located at, >> >> http://cr.openjdk.java.net/~hb/8131061/webrev.00/ >> >> Regards >> >> Harsha > From dmitry.samersoff at oracle.com Tue Aug 23 06:14:19 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 23 Aug 2016 09:14:19 +0300 Subject: RFR: 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" In-Reply-To: <8aec9a50-f21d-498f-8098-7b8cb22b6e30@default> References: <8aec9a50-f21d-498f-8098-7b8cb22b6e30@default> Message-ID: Jini, Looks good for me. -Dmitry On 2016-08-22 06:29, Jini Susan George wrote: > Hello, > > > > Could I please get a review for: > > > > https://bugs.openjdk.java.net/browse/JDK-8163150 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8163150/webrev.00/ > > > > The test BasicLauncherTest.java includes code leveraged from Yasumasa?s > webrev for JDK-8163581. > > > > Thanks, > > - Jini Susan George > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Tue Aug 23 06:17:05 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Aug 2016 16:17:05 +1000 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> Message-ID: <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> Hi Harsha, On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: > Hello, > > Please review the below webrev incorporating David's comments. > > http://cr.openjdk.java.net/~hb/8152589/webrev.01/ Using a static isNotified field isn't exactly what I had in mind, I was thinking of something more encapsulated - something I thought already existed in other tests, but now I can't find it. Eg: /* synchronization helper for two-thread wait/notify interaction */ static class WaitObject { boolean isNotified = false; public void await() throws InterruptedException { while (!isNotified) wait(); isNotified = false; } public void doNotify() { isNotified = true; notify(); } } then OBJC would be a WaitObject and you would do: synchronized(OBJC) { log("WaitingThread about to wait on objC"); try { // Signal checker thread, about to wait on objC. waiting = false; p.arriveAndAwaitAdvance(); // Phase 1 (waiting) waiting = true; OBJC.doWait(); } catch (InterruptedException e) { ... etc. Minor nits: - why did you move the @library ? - @Override, if used, should be applied consistently - if you want to capitalize objA, objB, objC then ensure you also update it in the comments and log statements (it really isn't necessary to capitalize them, that is suggested for compile-time constants and these are not - they are just static final variables). Thanks, David > Regards > > Harsha > > > On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >> Hi David, >> >> I will incorporate changes suggested by you. Let's wait for few more >> review comments and then I will send consolidated webrev. >> >> Regards >> Harsha >> >> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>> Hi David, >>>> >>>> Agreed that we could fix WaitingThread the way you have said, but in >>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>> >>> Nor are there likely to be - that's what makes spurious wakeup bugs >>> so difficult to detect! >>> >>>> This test has been fixed several times (3-4) for intermittent failures >>>> and hence I would not like to meddle with code that is not causing any >>>> problems even though there is scope for refactoring. >>> >>> It isn't refactoring it is fixing and we have fixed several tests in >>> a similar way. >>> >>>> The issue reported was with LockThreadB and hence I have provided >>>> possible fix for the same. >>> >>> That doesn't preclude fixing other issues with the test at the same >>> time. >>> >>> David >>> >>>> Thanks >>>> >>>> Harsha >>>> >>>> >>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>> Hi Harsha, >>>>> >>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>> Hello, >>>>>> >>>>>> Please review and provide comments for fix for issue, >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>> >>>>>> having webrev located at >>>>>> >>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>> >>>>> These changes look quite good (though I have to admit I struggle to >>>>> read the lambda and stream code :) ). >>>>> >>>>> Note that like many of these kinds of tests there is an issue with >>>>> WaitingThread because it does not wait in a loop and so is susceptible >>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>> variable and then do: >>>>> >>>>> while (!notified) >>>>> wait(); >>>>> >>>>> and set notified before the notify(). >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Fix details: >>>>>> >>>>>> 1. From nightly failures we see that LockThreadB was blocked on wrong >>>>>> object. We now do a repeated check with timeout if any given >>>>>> thread is >>>>>> blocked on expected object. It is possible that LockThreadB might >>>>>> still >>>>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>>>>> invoked. >>>>>> >>>>>> 2. The logs from lock free logger was never printed. It is not being >>>>>> printed. >>>>>> >>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>> helps us >>>>>> ascertain if failure is in test case or in the component. >>>>>> >>>>>> 4. Even though we had lock free logger, several >>>>>> ex.printStackTrace() was >>>>>> used which could be responsible for failure. It is removed. >>>>>> >>>>>> 5. There were several places where tests continue to ran even after >>>>>> failure (testFailed flag). That is fixed. >>>>>> >>>>>> 6. Couple of other minor refactoring. >>>>>> >>>>>> Thanks >>>>>> >>>>>> Harsha >>>>>> >>>> >> > From jini.george at oracle.com Tue Aug 23 06:18:13 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 22 Aug 2016 23:18:13 -0700 (PDT) Subject: RFR: 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" In-Reply-To: References: <8aec9a50-f21d-498f-8098-7b8cb22b6e30@default> Message-ID: <37e90ad4-9169-47b2-b746-8633fea72234@default> Thank you, Dmitry ! -jini > -----Original Message----- > From: Dmitry Samersoff > Sent: Tuesday, August 23, 2016 11:44 AM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR: 8163150: SA: CLHSDB printmdo throws an exception with > "java.lang.InternalError: missing reason for 22" > > Jini, > > Looks good for me. > > -Dmitry > > On 2016-08-22 06:29, Jini Susan George wrote: > > Hello, > > > > > > > > Could I please get a review for: > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8163150 > > > > > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8163150/webrev.00/ > > > > > > > > The test BasicLauncherTest.java includes code leveraged from Yasumasa?s > > webrev for JDK-8163581. > > > > > > > > Thanks, > > > > - Jini Susan George > > > > > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From david.holmes at oracle.com Tue Aug 23 07:11:18 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Aug 2016 17:11:18 +1000 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: References: Message-ID: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> Hi Harsha, On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: > Hello All, > > Please review the below parfait fixes for DiagnosticCommandImpl.c > > Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 > > webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ Looks functionally correct, but I wouldn't complain if you wanted to use a macro to reduce the duplication and verbosity. Even the: 109 if (obj == NULL) { 110 free(dcmd_arg_info_array); 111 return NULL; can be replaced by an exception-check as that is the only time JNU_NewObjectByName can return NULL. I also noticed an issue that was flagged in some other JNI code lately: 213 if (obj == NULL) { 214 free(dcmd_info_array); 215 JNU_ThrowOutOfMemoryError(env, 0); 216 return NULL; If obj == NULL then there is already a pending exception and we should not be throwing OOME. Thanks, David > Regards > > Harsha > From daniel.fuchs at oracle.com Tue Aug 23 10:41:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 23 Aug 2016 11:41:13 +0100 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> Message-ID: Hi, On 22/08/16 22:58, Mandy Chung wrote: > sun/management/spi/AgentProvider.java > 78 public abstract void startAgent(String port, Properties props); > > The port parameter should be ?int?. > I wonder about that. I wonder if the name of the agent provider should be the name of the property that starts it - for instance - we could have an agent provider whose name is "com.sun.management.snmp.port" - and the first parameter to startAgent would be the value associated with that property (we'd renamed the port parameter into e.g. propertyValue). Then it would be up to the agent provider to interpret the property value however it sees fit. In this example - a provider deployed as responding to the "com.sun.management.snmp.port" property would interpret the value of the property as the SNMP port number of the SNMP agent to start. Our implementation could still only look for an agent provider named "com.sun.management.snmp.port" (instead of "SnmpAgent") - but that could be extended in the future if we ever want to start more (different) agents. Also I'm not sure the AgentProvider should have a getPort() method. I don't see were it is used? Is it for debugging purposes? If so maybe it should be getAddress() and return a informal String. What do you think? best regards, -- daniel From marcus.larsson at oracle.com Tue Aug 23 11:17:47 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 23 Aug 2016 13:17:47 +0200 Subject: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <570D02CF.7070708@oracle.com> References: <5704B0B0.4010404@oracle.com> <570D02CF.7070708@oracle.com> Message-ID: <307928f7-55b3-999d-b3e8-ffd5966457a1@oracle.com> Hi, Still looking for a Reviewer for this. (Rebased webrev in-place.) Thanks, Marcus On 04/12/2016 04:14 PM, Marcus Larsson wrote: > Ping! > > On 04/06/2016 08:46 AM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add a warning for when tag >> selections in -Xlog or VM.log don't match any tag sets used in the VM. >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8150894 >> >> Testing: >> Internal VM tests with RBT >> >> Thanks, >> Marcus > From harsha.wardhana.b at oracle.com Tue Aug 23 12:17:32 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 23 Aug 2016 17:47:32 +0530 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> Message-ID: <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> Hi David, You approach to waiter object is a neat little abstraction and I will make it a point to use it in future fixes, if required. revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: > Hi Harsha, > > On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >> Hello, >> >> Please review the below webrev incorporating David's comments. >> >> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ > > Using a static isNotified field isn't exactly what I had in mind, I > was thinking of something more encapsulated - something I thought > already existed in other tests, but now I can't find it. Eg: > > /* synchronization helper for two-thread wait/notify interaction > */ > static class WaitObject { > boolean isNotified = false; > public void await() throws InterruptedException { > while (!isNotified) > wait(); > isNotified = false; > } > public void doNotify() { > isNotified = true; > notify(); > } > } > > then OBJC would be a WaitObject and you would do: > > synchronized(OBJC) { > log("WaitingThread about to wait on objC"); > try { > // Signal checker thread, about to wait on objC. > waiting = false; > p.arriveAndAwaitAdvance(); // Phase 1 (waiting) > waiting = true; > OBJC.doWait(); > } catch (InterruptedException e) { > ... > > etc. > > Minor nits: > - why did you move the @library ? It was suggested by NetBeans Jtreg plugin to fix tag order. > - @Override, if used, should be applied consistently Have applied the annotation consistently. > - if you want to capitalize objA, objB, objC then ensure you also > update it in the comments and log statements (it really isn't > necessary to capitalize them, that is suggested for compile-time > constants and these are not - they are just static final variables). Done. Thanks Harsha > > > Thanks, > David > >> Regards >> >> Harsha >> >> >> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>> Hi David, >>> >>> I will incorporate changes suggested by you. Let's wait for few more >>> review comments and then I will send consolidated webrev. >>> >>> Regards >>> Harsha >>> >>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>> Hi David, >>>>> >>>>> Agreed that we could fix WaitingThread the way you have said, but in >>>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>>> >>>> Nor are there likely to be - that's what makes spurious wakeup bugs >>>> so difficult to detect! >>>> >>>>> This test has been fixed several times (3-4) for intermittent >>>>> failures >>>>> and hence I would not like to meddle with code that is not causing >>>>> any >>>>> problems even though there is scope for refactoring. >>>> >>>> It isn't refactoring it is fixing and we have fixed several tests in >>>> a similar way. >>>> >>>>> The issue reported was with LockThreadB and hence I have provided >>>>> possible fix for the same. >>>> >>>> That doesn't preclude fixing other issues with the test at the same >>>> time. >>>> >>>> David >>>> >>>>> Thanks >>>>> >>>>> Harsha >>>>> >>>>> >>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>> Hi Harsha, >>>>>> >>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review and provide comments for fix for issue, >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>> >>>>>>> having webrev located at >>>>>>> >>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>> >>>>>> These changes look quite good (though I have to admit I struggle to >>>>>> read the lambda and stream code :) ). >>>>>> >>>>>> Note that like many of these kinds of tests there is an issue with >>>>>> WaitingThread because it does not wait in a loop and so is >>>>>> susceptible >>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>> variable and then do: >>>>>> >>>>>> while (!notified) >>>>>> wait(); >>>>>> >>>>>> and set notified before the notify(). >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Fix details: >>>>>>> >>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>> wrong >>>>>>> object. We now do a repeated check with timeout if any given >>>>>>> thread is >>>>>>> blocked on expected object. It is possible that LockThreadB might >>>>>>> still >>>>>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>>>>>> invoked. >>>>>>> >>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>> being >>>>>>> printed. >>>>>>> >>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>> helps us >>>>>>> ascertain if failure is in test case or in the component. >>>>>>> >>>>>>> 4. Even though we had lock free logger, several >>>>>>> ex.printStackTrace() was >>>>>>> used which could be responsible for failure. It is removed. >>>>>>> >>>>>>> 5. There were several places where tests continue to ran even after >>>>>>> failure (testFailed flag). That is fixed. >>>>>>> >>>>>>> 6. Couple of other minor refactoring. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Harsha >>>>>>> >>>>> >>> >> From dmitry.samersoff at oracle.com Tue Aug 23 12:34:43 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 23 Aug 2016 15:34:43 +0300 Subject: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools In-Reply-To: References: Message-ID: <12dc677b-e33c-0345-4680-e97cc1604cbe@oracle.com> On 2016-08-17 10:51, Dmitry Samersoff wrote: > Everybody, > > Please review the changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ > > -Dmitry > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From ioi.lam at oracle.com Tue Aug 23 13:10:25 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 23 Aug 2016 06:10:25 -0700 Subject: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools In-Reply-To: <12dc677b-e33c-0345-4680-e97cc1604cbe@oracle.com> References: <12dc677b-e33c-0345-4680-e97cc1604cbe@oracle.com> Message-ID: <57BC4B41.60305@oracle.com> Hi Dmitry, Why are you adding /test/lib: - * @library /lib/testlibrary + * @library /lib/testlibrary /test/lib The only class used by jdk/test/sun/tools/jps/*.java in /test/lib is here: TestJpsSanity.java:import jdk.test.lib.apps.LingeredApp; But TestJpsSanity.java is not use by this test -- I ran the test with your patch in a clean jtreg directory and the test passed, but I don't see TestJpsSanity.class, or any jdk.test.lib.* class. So I don't think you need to add /test/lib. - Ioi On 8/23/16 5:34 AM, Dmitry Samersoff wrote: > On 2016-08-17 10:51, Dmitry Samersoff wrote: >> Everybody, >> >> Please review the changes: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ >> >> -Dmitry >> > From yasuenag at gmail.com Tue Aug 23 13:17:14 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 23 Aug 2016 22:17:14 +0900 Subject: PING: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap In-Reply-To: References: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> Message-ID: <180629ce-a11a-26fb-bfe6-0739b4a5f60a@gmail.com> PING: Could you review and sponsor it? Yasumasa On 2016/08/16 21:31, Yasumasa Suenaga wrote: > Hi all, > > Have you checked changes for this issue? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/hotspot/ > http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ > > For example, ParallelScavengeHeap.java overrides printOn() method. > This method shows addresses of each memory regions. > > My proposal shows memory region of G1CollectedHeap and region size. > Please review and sponsor for it. If it is not enough, please tell me. > > > Thanks, > > Yasumasa > > > On 2016/08/11 23:15, Yasumasa Suenaga wrote: >> Hi Jini, >> >> I added this check in new webrev: >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/08/11 15:33, Jini Susan George wrote: >>> Thank you for this fix, Yasumasa. This issue was manifested through the 'universe' command in clhsdb also, and your change fixes that. It would be great if you could modify BasicLauncherTest.java to have some testing done for this also. >>> >>> Thank you, >>> Jini (Not a Reviewer). >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Thursday, August 11, 2016 10:03 AM >>>> To: Yasumasa Suenaga; serviceability-dev at openjdk.java.net; hotspot-gc- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle >>>> G1CollectedHeap >>>> >>>> Hi Yasumasa, >>>> >>>> Adding in GC folk. >>>> >>>> I agree with the need to override the printOn method, but can't comment >>>> on the details of what you are actually printing. >>>> >>>> Thanks, >>>> David >>>> >>>> On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> When I chose "Heap Parameters" menu in HSDB, I got following value: >>>>> -------------------- >>>>> Heap Parameters: >>>>> unknown subtype of CollectedHeap @ 0x00007f4d4c030510 >>>>> (0x00000006c6e00000,0x00000007c0000000) >>>>> -------------------- >>>>> >>>>> I think it should not be "unknown subtype". >>>>> >>>>> This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). >>>>> This method is overrided in ParallelScavengeHeap and GenCollectedHeap. >>>>> However, G1CollectedHeap does not override. >>>>> >>>>> I think G1CollectedHeap should override this method. >>>>> >>>>> I uploaded a webrev for this issue. >>>>> Could you review it? >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ >>>>> >>>>> I'm jdk 9 committer, but I cannot access JPRT. >>>>> So I need a sponsor. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> From harsha.wardhana.b at oracle.com Tue Aug 23 14:45:47 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 23 Aug 2016 20:15:47 +0530 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> Message-ID: Hi Daniel, The focus of this issue was to decouple hard-dependency between java.management module and jdk.snmp module since jdk.snmp is not a core module. There was not much focus on an 'Agent' Interface that could allow plugging in any Agent. Hence there was no discussions around the structure of such an interface. On Tuesday 23 August 2016 04:11 PM, Daniel Fuchs wrote: > Hi, > > On 22/08/16 22:58, Mandy Chung wrote: >> sun/management/spi/AgentProvider.java >> 78 public abstract void startAgent(String port, Properties props); >> >> The port parameter should be ?int?. >> > > I wonder about that. I wonder if the name of the agent provider > should be the name of the property that starts it - for > instance - we could have an agent provider whose name is > "com.sun.management.snmp.port" - and the first parameter to > startAgent would be the value associated with that > property (we'd renamed the port parameter into e.g. > propertyValue). Any effort towards creating such an interface will require participation from much larger audience and if required could be tracked via a separate JEP. I would like to consider that to be out-of-scope of current issue. > > Then it would be up to the agent provider to interpret the > property value however it sees fit. In this example - a > provider deployed as responding to the "com.sun.management.snmp.port" > property would interpret the value of the property as the SNMP > port number of the SNMP agent to start. > > Our implementation could still only look for an agent > provider named "com.sun.management.snmp.port" (instead of > "SnmpAgent") - but that could be extended in the future > if we ever want to start more (different) agents. > > Also I'm not sure the AgentProvider should have a getPort() method. > I don't see were it is used? Is it for debugging purposes? > If so maybe it should be getAddress() and return a informal String. > > What do you think? > Port can be made a part of env variables (Property) and we could have getProperty method to retrieve port no. But we have to draw a line somewhere as to when do we stop making this the generic interface that allows plugging in any Agent. Where do you think we should be drawing the line? > best regards, > > -- daniel Regards Harsha From daniel.fuchs at oracle.com Tue Aug 23 15:21:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 23 Aug 2016 16:21:29 +0100 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> Message-ID: On 23/08/16 15:45, Harsha Wardhana B wrote: > Hi Daniel, > > The focus of this issue was to decouple hard-dependency between > java.management module and jdk.snmp module since jdk.snmp is not a core > module. There was not much focus on an 'Agent' Interface that could > allow plugging in any Agent. Hence there was no discussions around the > structure of such an interface. > OK - sun/management/spi/AgentProvider.java is a private interface that only classes in the JDK can implement, and is not designed to be extended outside of the JDK, so I agree that what you have seems to be sufficient for the purpose of decoupling. Because nothing outside of the JDK can implement it then it can be revisited and amended later if we have other uses. +1 if Mandy is OK :-) cheers, -- daniel From jini.george at oracle.com Tue Aug 23 17:36:51 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 23 Aug 2016 10:36:51 -0700 (PDT) Subject: RFR: 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" In-Reply-To: <37e90ad4-9169-47b2-b746-8633fea72234@default> References: <8aec9a50-f21d-498f-8098-7b8cb22b6e30@default> <37e90ad4-9169-47b2-b746-8633fea72234@default> Message-ID: <4e561e7a-fa39-4b94-b746-bf4de6e17928@default> I need one more reviewer, please ! Thanks, Jini. > -----Original Message----- > From: Jini Susan George > Sent: Tuesday, August 23, 2016 11:48 AM > To: Dmitry Samersoff; serviceability-dev at openjdk.java.net > Subject: RE: RFR: 8163150: SA: CLHSDB printmdo throws an exception with > "java.lang.InternalError: missing reason for 22" > > Thank you, Dmitry ! > > -jini > > > -----Original Message----- > > From: Dmitry Samersoff > > Sent: Tuesday, August 23, 2016 11:44 AM > > To: Jini Susan George; serviceability-dev at openjdk.java.net > > Subject: Re: RFR: 8163150: SA: CLHSDB printmdo throws an exception with > > "java.lang.InternalError: missing reason for 22" > > > > Jini, > > > > Looks good for me. > > > > -Dmitry > > > > On 2016-08-22 06:29, Jini Susan George wrote: > > > Hello, > > > > > > > > > > > > Could I please get a review for: > > > > > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8163150 > > > > > > > > > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8163150/webrev.00/ > > > > > > > > > > > > The test BasicLauncherTest.java includes code leveraged from > Yasumasa?s > > > webrev for JDK-8163581. > > > > > > > > > > > > Thanks, > > > > > > - Jini Susan George > > > > > > > > > > > > > > > -- > > Dmitry Samersoff > > Oracle Java development team, Saint Petersburg, Russia > > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Tue Aug 23 19:02:15 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 23 Aug 2016 22:02:15 +0300 Subject: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools In-Reply-To: <57BC4B41.60305@oracle.com> References: <12dc677b-e33c-0345-4680-e97cc1604cbe@oracle.com> <57BC4B41.60305@oracle.com> Message-ID: <938232c7-c206-f0db-7446-78960537ad2b@oracle.com> Ioi, Thank you for review. Hmm. It looks like changes below solves the problem. - * @build jdk.testlibrary.* JpsHelper JpsBase + * @build JpsHelper JpsBase I'm running rbt job to verify it. -Dmitry On 2016-08-23 16:10, Ioi Lam wrote: > Hi Dmitry, > > Why are you adding /test/lib: > > - * @library /lib/testlibrary > + * @library /lib/testlibrary /test/lib > > The only class used by jdk/test/sun/tools/jps/*.java in /test/lib is here: > > TestJpsSanity.java:import jdk.test.lib.apps.LingeredApp; > > But TestJpsSanity.java is not use by this test -- I ran the test with > your patch in a clean jtreg directory and the test passed, but I don't > see TestJpsSanity.class, or any jdk.test.lib.* class. > > So I don't think you need to add /test/lib. > > - Ioi > > On 8/23/16 5:34 AM, Dmitry Samersoff wrote: >> On 2016-08-17 10:51, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review the changes: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ >>> >>> -Dmitry >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From christian.tornqvist at oracle.com Tue Aug 23 19:10:20 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 23 Aug 2016 15:10:20 -0400 Subject: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools In-Reply-To: <938232c7-c206-f0db-7446-78960537ad2b@oracle.com> References: <12dc677b-e33c-0345-4680-e97cc1604cbe@oracle.com> <57BC4B41.60305@oracle.com> <938232c7-c206-f0db-7446-78960537ad2b@oracle.com> Message-ID: <1f8101d1fd71$feb399d0$fc1acd70$@oracle.com> Hi Dmitry, You don't need to explicitly build JpsHelper, I also noticed that you're using ProcessTools and OutputAnalyzer from /lib/testlibrary , would it make sense to change this to use the /test/lib ones and simply have: @library /test/lib ? Thanks, Christian -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Dmitry Samersoff Sent: Tuesday, August 23, 2016 3:02 PM To: Ioi Lam ; serviceability-dev at openjdk.java.net; hotspot-runtime-dev Subject: Re: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools Ioi, Thank you for review. Hmm. It looks like changes below solves the problem. - * @build jdk.testlibrary.* JpsHelper JpsBase + * @build JpsHelper JpsBase I'm running rbt job to verify it. -Dmitry On 2016-08-23 16:10, Ioi Lam wrote: > Hi Dmitry, > > Why are you adding /test/lib: > > - * @library /lib/testlibrary > + * @library /lib/testlibrary /test/lib > > The only class used by jdk/test/sun/tools/jps/*.java in /test/lib is here: > > TestJpsSanity.java:import jdk.test.lib.apps.LingeredApp; > > But TestJpsSanity.java is not use by this test -- I ran the test with > your patch in a clean jtreg directory and the test passed, but I don't > see TestJpsSanity.class, or any jdk.test.lib.* class. > > So I don't think you need to add /test/lib. > > - Ioi > > On 8/23/16 5:34 AM, Dmitry Samersoff wrote: >> On 2016-08-17 10:51, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review the changes: >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ >>> >>> -Dmitry >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mandy.chung at oracle.com Tue Aug 23 19:40:13 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 23 Aug 2016 12:40:13 -0700 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> Message-ID: <476E2856-F1E6-4F61-8389-CF395231F5EC@oracle.com> > On Aug 23, 2016, at 8:21 AM, Daniel Fuchs wrote: > > On 23/08/16 15:45, Harsha Wardhana B wrote: >> Hi Daniel, >> >> The focus of this issue was to decouple hard-dependency between >> java.management module and jdk.snmp module since jdk.snmp is not a core >> module. There was not much focus on an 'Agent' Interface that could >> allow plugging in any Agent. Hence there was no discussions around the >> structure of such an interface. >> > > OK - sun/management/spi/AgentProvider.java is a private > interface that only classes in the JDK can implement, and > is not designed to be extended outside of the JDK, so I > agree that what you have seems to be sufficient for the purpose > of decoupling. Because nothing outside of the JDK can implement > it then it can be revisited and amended later if we have other uses. > Correct this is a private interface that can be changed in any future release. This work allows the SNMP management agent be loaded via service binding rather than requiring the module be explicitly added to the module graph. Daniel is closer to the snmp agent implementation and I agree that AgentProvider can be simplified. See my comment inlined below. > On Aug 23, 2016, at 3:41 AM, Daniel Fuchs wrote: > > On 22/08/16 22:58, Mandy Chung wrote: >> sun/management/spi/AgentProvider.java >> 78 public abstract void startAgent(String port, Properties props); >> >> The port parameter should be ?int?. >> > > I wonder about that. I wonder if the name of the agent provider > should be the name of the property that starts it - for > instance - we could have an agent provider whose name is ?com.sun.management.snmp.port" ?com.sun.management.snmp.port? be the provider name seems confusing (it?s an agent but not a port). I considered naming it with ?com.sun.management.snmp.Agent? but since the name is private interface, a simple name would work. > - and the first parameter to > startAgent would be the value associated with that > property (we'd renamed the port parameter into e.g. > propertyValue). > > Then it would be up to the agent provider to interpret the > property value however it sees fit. In this example - a > provider deployed as responding to the "com.sun.management.snmp.port" > property would interpret the value of the property as the SNMP > port number of the SNMP agent to start. > > Our implementation could still only look for an agent > provider named "com.sun.management.snmp.port" (instead of > "SnmpAgent") - but that could be extended in the future > if we ever want to start more (different) agents. > While it?s easy to rev the interface multiple agents, we should wait until it?s really needed. I wasn?t aware of any customer using SNMP management support. IMO we should consider if SNMP support should be deprecated for removal. So I would keep the change minimal. > Also I'm not sure the AgentProvider should have a getPort() method. > I don't see were it is used? Is it for debugging purposes? > If so maybe it should be getAddress() and return a informal String. > Good point - it should be an address rather than a port number. If it?s not used, let?s drop it. I also suggest to drop the ?port? parameter and the snmp agent can get the ?com.sun.management.snmp.port? property from the specified props. public abstract void startAgent(Properties props); Harsha - are you okay with that? Mandy From david.holmes at oracle.com Wed Aug 24 01:25:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Aug 2016 11:25:14 +1000 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> Message-ID: On 23/08/2016 10:17 PM, Harsha Wardhana B wrote: > Hi David, > > You approach to waiter object is a neat little abstraction and I will > make it a point to use it in future fixes, if required. Note it only works for a single waiting thread. :) > revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ This looks good, thanks for your patience with this. Cheers, David > On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >> Hi Harsha, >> >> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>> Hello, >>> >>> Please review the below webrev incorporating David's comments. >>> >>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >> >> Using a static isNotified field isn't exactly what I had in mind, I >> was thinking of something more encapsulated - something I thought >> already existed in other tests, but now I can't find it. Eg: >> >> /* synchronization helper for two-thread wait/notify interaction >> */ >> static class WaitObject { >> boolean isNotified = false; >> public void await() throws InterruptedException { >> while (!isNotified) >> wait(); >> isNotified = false; >> } >> public void doNotify() { >> isNotified = true; >> notify(); >> } >> } >> >> then OBJC would be a WaitObject and you would do: >> >> synchronized(OBJC) { >> log("WaitingThread about to wait on objC"); >> try { >> // Signal checker thread, about to wait on objC. >> waiting = false; >> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >> waiting = true; >> OBJC.doWait(); >> } catch (InterruptedException e) { >> ... >> >> etc. >> >> Minor nits: >> - why did you move the @library ? > It was suggested by NetBeans Jtreg plugin to fix tag order. >> - @Override, if used, should be applied consistently > Have applied the annotation consistently. >> - if you want to capitalize objA, objB, objC then ensure you also >> update it in the comments and log statements (it really isn't >> necessary to capitalize them, that is suggested for compile-time >> constants and these are not - they are just static final variables). > Done. > > Thanks > Harsha >> >> >> Thanks, >> David >> >>> Regards >>> >>> Harsha >>> >>> >>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>> Hi David, >>>> >>>> I will incorporate changes suggested by you. Let's wait for few more >>>> review comments and then I will send consolidated webrev. >>>> >>>> Regards >>>> Harsha >>>> >>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>> Hi David, >>>>>> >>>>>> Agreed that we could fix WaitingThread the way you have said, but in >>>>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>>>> >>>>> Nor are there likely to be - that's what makes spurious wakeup bugs >>>>> so difficult to detect! >>>>> >>>>>> This test has been fixed several times (3-4) for intermittent >>>>>> failures >>>>>> and hence I would not like to meddle with code that is not causing >>>>>> any >>>>>> problems even though there is scope for refactoring. >>>>> >>>>> It isn't refactoring it is fixing and we have fixed several tests in >>>>> a similar way. >>>>> >>>>>> The issue reported was with LockThreadB and hence I have provided >>>>>> possible fix for the same. >>>>> >>>>> That doesn't preclude fixing other issues with the test at the same >>>>> time. >>>>> >>>>> David >>>>> >>>>>> Thanks >>>>>> >>>>>> Harsha >>>>>> >>>>>> >>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>> Hi Harsha, >>>>>>> >>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review and provide comments for fix for issue, >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>> >>>>>>>> having webrev located at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>> >>>>>>> These changes look quite good (though I have to admit I struggle to >>>>>>> read the lambda and stream code :) ). >>>>>>> >>>>>>> Note that like many of these kinds of tests there is an issue with >>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>> susceptible >>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>> variable and then do: >>>>>>> >>>>>>> while (!notified) >>>>>>> wait(); >>>>>>> >>>>>>> and set notified before the notify(). >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Fix details: >>>>>>>> >>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>>> wrong >>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>> thread is >>>>>>>> blocked on expected object. It is possible that LockThreadB might >>>>>>>> still >>>>>>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>>>>>>> invoked. >>>>>>>> >>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>> being >>>>>>>> printed. >>>>>>>> >>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>> helps us >>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>> >>>>>>>> 4. Even though we had lock free logger, several >>>>>>>> ex.printStackTrace() was >>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>> >>>>>>>> 5. There were several places where tests continue to ran even after >>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>> >>>>>>>> 6. Couple of other minor refactoring. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Harsha >>>>>>>> >>>>>> >>>> >>> > From harsha.wardhana.b at oracle.com Wed Aug 24 04:37:20 2016 From: harsha.wardhana.b at oracle.com (harsha.wardhana.b at oracle.com) Date: Wed, 24 Aug 2016 04:37:20 +0000 (UTC) Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> Message-ID: Thanks David. Harsha On Wed, Aug 24, 2016 at 6:55 AM +0530, "David Holmes" wrote: On 23/08/2016 10:17 PM, Harsha Wardhana B wrote: > Hi David, > > You approach to waiter object is a neat little abstraction and I will > make it a point to use it in future fixes, if required. Note it only works for a single waiting thread. :) > revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ This looks good, thanks for your patience with this. Cheers, David > On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >> Hi Harsha, >> >> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>> Hello, >>> >>> Please review the below webrev incorporating David's comments. >>> >>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >> >> Using a static isNotified field isn't exactly what I had in mind, I >> was thinking of something more encapsulated - something I thought >> already existed in other tests, but now I can't find it. Eg: >> >> /* synchronization helper for two-thread wait/notify interaction >> */ >> static class WaitObject { >> boolean isNotified = false; >> public void await() throws InterruptedException { >> while (!isNotified) >> wait(); >> isNotified = false; >> } >> public void doNotify() { >> isNotified = true; >> notify(); >> } >> } >> >> then OBJC would be a WaitObject and you would do: >> >> synchronized(OBJC) { >> log("WaitingThread about to wait on objC"); >> try { >> // Signal checker thread, about to wait on objC. >> waiting = false; >> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >> waiting = true; >> OBJC.doWait(); >> } catch (InterruptedException e) { >> ... >> >> etc. >> >> Minor nits: >> - why did you move the @library ? > It was suggested by NetBeans Jtreg plugin to fix tag order. >> - @Override, if used, should be applied consistently > Have applied the annotation consistently. >> - if you want to capitalize objA, objB, objC then ensure you also >> update it in the comments and log statements (it really isn't >> necessary to capitalize them, that is suggested for compile-time >> constants and these are not - they are just static final variables). > Done. > > Thanks > Harsha >> >> >> Thanks, >> David >> >>> Regards >>> >>> Harsha >>> >>> >>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>> Hi David, >>>> >>>> I will incorporate changes suggested by you. Let's wait for few more >>>> review comments and then I will send consolidated webrev. >>>> >>>> Regards >>>> Harsha >>>> >>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>> Hi David, >>>>>> >>>>>> Agreed that we could fix WaitingThread the way you have said, but in >>>>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>>>> >>>>> Nor are there likely to be - that's what makes spurious wakeup bugs >>>>> so difficult to detect! >>>>> >>>>>> This test has been fixed several times (3-4) for intermittent >>>>>> failures >>>>>> and hence I would not like to meddle with code that is not causing >>>>>> any >>>>>> problems even though there is scope for refactoring. >>>>> >>>>> It isn't refactoring it is fixing and we have fixed several tests in >>>>> a similar way. >>>>> >>>>>> The issue reported was with LockThreadB and hence I have provided >>>>>> possible fix for the same. >>>>> >>>>> That doesn't preclude fixing other issues with the test at the same >>>>> time. >>>>> >>>>> David >>>>> >>>>>> Thanks >>>>>> >>>>>> Harsha >>>>>> >>>>>> >>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>> Hi Harsha, >>>>>>> >>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review and provide comments for fix for issue, >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>> >>>>>>>> having webrev located at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>> >>>>>>> These changes look quite good (though I have to admit I struggle to >>>>>>> read the lambda and stream code :) ). >>>>>>> >>>>>>> Note that like many of these kinds of tests there is an issue with >>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>> susceptible >>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>> variable and then do: >>>>>>> >>>>>>> while (!notified) >>>>>>> wait(); >>>>>>> >>>>>>> and set notified before the notify(). >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Fix details: >>>>>>>> >>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>>> wrong >>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>> thread is >>>>>>>> blocked on expected object. It is possible that LockThreadB might >>>>>>>> still >>>>>>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>>>>>>> invoked. >>>>>>>> >>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>> being >>>>>>>> printed. >>>>>>>> >>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>> helps us >>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>> >>>>>>>> 4. Even though we had lock free logger, several >>>>>>>> ex.printStackTrace() was >>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>> >>>>>>>> 5. There were several places where tests continue to ran even after >>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>> >>>>>>>> 6. Couple of other minor refactoring. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Harsha >>>>>>>> >>>>>> >>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Aug 24 05:58:01 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 24 Aug 2016 11:28:01 +0530 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: <476E2856-F1E6-4F61-8389-CF395231F5EC@oracle.com> References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> <476E2856-F1E6-4F61-8389-CF395231F5EC@oracle.com> Message-ID: <5d84e9ca-1a7f-b3b2-1a0b-27fce0ad364c@oracle.com> On Wednesday 24 August 2016 01:10 AM, Mandy Chung wrote: >> On Aug 23, 2016, at 8:21 AM, Daniel Fuchs wrote: >> >> On 23/08/16 15:45, Harsha Wardhana B wrote: >>> Hi Daniel, >>> >>> The focus of this issue was to decouple hard-dependency between >>> java.management module and jdk.snmp module since jdk.snmp is not a core >>> module. There was not much focus on an 'Agent' Interface that could >>> allow plugging in any Agent. Hence there was no discussions around the >>> structure of such an interface. >>> >> OK - sun/management/spi/AgentProvider.java is a private >> interface that only classes in the JDK can implement, and >> is not designed to be extended outside of the JDK, so I >> agree that what you have seems to be sufficient for the purpose >> of decoupling. Because nothing outside of the JDK can implement >> it then it can be revisited and amended later if we have other uses. >> > Correct this is a private interface that can be changed in any future release. This work allows the SNMP management agent be loaded via service binding rather than requiring the module be explicitly added to the module graph. > > Daniel is closer to the snmp agent implementation and I agree that AgentProvider can be simplified. See my comment inlined below. > >> On Aug 23, 2016, at 3:41 AM, Daniel Fuchs wrote: >> >> On 22/08/16 22:58, Mandy Chung wrote: >>> sun/management/spi/AgentProvider.java >>> 78 public abstract void startAgent(String port, Properties props); >>> >>> The port parameter should be ?int?. >>> >> I wonder about that. I wonder if the name of the agent provider >> should be the name of the property that starts it - for >> instance - we could have an agent provider whose name is ?com.sun.management.snmp.port" > ?com.sun.management.snmp.port? be the provider name seems confusing (it?s an agent but not a port). I considered naming it with ?com.sun.management.snmp.Agent? but since the name is private interface, a simple name would work. > >> - and the first parameter to >> startAgent would be the value associated with that >> property (we'd renamed the port parameter into e.g. >> propertyValue). >> >> Then it would be up to the agent provider to interpret the >> property value however it sees fit. In this example - a >> provider deployed as responding to the "com.sun.management.snmp.port" >> property would interpret the value of the property as the SNMP >> port number of the SNMP agent to start. >> >> Our implementation could still only look for an agent >> provider named "com.sun.management.snmp.port" (instead of >> "SnmpAgent") - but that could be extended in the future >> if we ever want to start more (different) agents. >> > While it?s easy to rev the interface multiple agents, we should wait until it?s really needed. > > I wasn?t aware of any customer using SNMP management support. IMO we should consider if SNMP support should be deprecated for removal. So I would keep the change minimal. > >> Also I'm not sure the AgentProvider should have a getPort() method. >> I don't see were it is used? Is it for debugging purposes? >> If so maybe it should be getAddress() and return a informal String. >> > Good point - it should be an address rather than a port number. If it?s not used, let?s drop it. I also suggest to drop the ?port? parameter and the snmp agent can get the ?com.sun.management.snmp.port? property from the specified props. > > public abstract void startAgent(Properties props); > > Harsha - are you okay with that? Yes. I am fine with it. > > Mandy Harsha From jini.george at oracle.com Wed Aug 24 06:10:51 2016 From: jini.george at oracle.com (Jini Susan George) Date: Tue, 23 Aug 2016 23:10:51 -0700 (PDT) Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE Message-ID: Hi all, Could you please review the fix for: Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ I took the liberty to do some module related cleanups in the test also while fixing this issue. Thank you, - Jini Susan George -------------- next part -------------- An HTML attachment was scrubbed... URL: From harsha.wardhana.b at oracle.com Wed Aug 24 06:18:34 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 24 Aug 2016 11:48:34 +0530 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> Message-ID: <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> Hi David, On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: > Hi Harsha, > > On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >> Hello All, >> >> Please review the below parfait fixes for DiagnosticCommandImpl.c >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >> >> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ > > Looks functionally correct, but I wouldn't complain if you wanted to > use a macro to reduce the duplication and verbosity. Even the: > > 109 if (obj == NULL) { > 110 free(dcmd_arg_info_array); > 111 return NULL; > > can be replaced by an exception-check as that is the only time > JNU_NewObjectByName can return NULL. I am not sure if using macro here is good practice since it will be specific to the function and it will encapsulate the local variable within it. Also, it will reduce code readability. Hence I would like to leave it as is. > > I also noticed an issue that was flagged in some other JNI code lately: > > 213 if (obj == NULL) { > 214 free(dcmd_info_array); > 215 JNU_ThrowOutOfMemoryError(env, 0); > 216 return NULL; > > If obj == NULL then there is already a pending exception and we should > not be throwing OOME. > Sure. This needs to be fixed. > Thanks, > David > >> Regards >> >> Harsha >> Harsha From robbin.ehn at oracle.com Wed Aug 24 06:28:12 2016 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 24 Aug 2016 08:28:12 +0200 Subject: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools In-Reply-To: References: Message-ID: Hi Dmitry, Looks good, thanks for fixing! /Robbin On 08/17/2016 09:51 AM, Dmitry Samersoff wrote: > Everybody, > > Please review the changes: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ > > -Dmitry > From amit.sapre at oracle.com Wed Aug 24 06:37:51 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Tue, 23 Aug 2016 23:37:51 -0700 (PDT) Subject: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module In-Reply-To: References: Message-ID: <28eda504-3c5a-4763-b2ee-902c7b3a3dac@default> From: Amit Sapre Sent: Monday, August 22, 2016 2:39 PM To: serviceability-dev Subject: RFR : JDK-8066635 - Fix deprecation warnings in java.management module Hello, Please review changes for fixing deprecation warnings. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8066635 Webrev : http://cr.openjdk.java.net/~sballal/sponsorship/8066635/webrev.00/ Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Aug 24 06:54:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Aug 2016 16:54:09 +1000 Subject: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module In-Reply-To: <28eda504-3c5a-4763-b2ee-902c7b3a3dac@default> References: <28eda504-3c5a-4763-b2ee-902c7b3a3dac@default> Message-ID: Hi Amit, On 24/08/2016 4:37 PM, Amit Sapre wrote: > > *From:*Amit Sapre > *Sent:* Monday, August 22, 2016 2:39 PM > *To:* serviceability-dev > *Subject:* RFR : JDK-8066635 - Fix deprecation warnings in > java.management module > > Hello, > > Please review changes for fixing deprecation warnings. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8066635 > > Webrev : http://cr.openjdk.java.net/~sballal/sponsorship/8066635/webrev.00/ Marking the methods @Deprecated fixes the problem. Another option would be converting the interface methods to default methods that throw the UnsupportOperationException and then delete them from the DefaultMBeanServerInterceptor class. Your call. If you leave as-is then consider this Reviewed. Thanks, David > > > Amit > From staffan.larsen at oracle.com Wed Aug 24 07:03:51 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 24 Aug 2016 09:03:51 +0200 Subject: RFR: 8163150: SA: CLHSDB printmdo throws an exception with "java.lang.InternalError: missing reason for 22" In-Reply-To: <4e561e7a-fa39-4b94-b746-bf4de6e17928@default> References: <8aec9a50-f21d-498f-8098-7b8cb22b6e30@default> <37e90ad4-9169-47b2-b746-8633fea72234@default> <4e561e7a-fa39-4b94-b746-bf4de6e17928@default> Message-ID: <01DF92E5-39B0-4A7E-9CD8-F4E0B2A6BB9A@oracle.com> Looks good. Thanks, /Staffan > On 23 aug. 2016, at 19:36, Jini Susan George wrote: > > I need one more reviewer, please ! > > Thanks, > Jini. > >> -----Original Message----- >> From: Jini Susan George >> Sent: Tuesday, August 23, 2016 11:48 AM >> To: Dmitry Samersoff; serviceability-dev at openjdk.java.net >> Subject: RE: RFR: 8163150: SA: CLHSDB printmdo throws an exception with >> "java.lang.InternalError: missing reason for 22" >> >> Thank you, Dmitry ! >> >> -jini >> >>> -----Original Message----- >>> From: Dmitry Samersoff >>> Sent: Tuesday, August 23, 2016 11:44 AM >>> To: Jini Susan George; serviceability-dev at openjdk.java.net >>> Subject: Re: RFR: 8163150: SA: CLHSDB printmdo throws an exception with >>> "java.lang.InternalError: missing reason for 22" >>> >>> Jini, >>> >>> Looks good for me. >>> >>> -Dmitry >>> >>> On 2016-08-22 06:29, Jini Susan George wrote: >>>> Hello, >>>> >>>> >>>> >>>> Could I please get a review for: >>>> >>>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8163150 >>>> >>>> >>>> >>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8163150/webrev.00/ >>>> >>>> >>>> >>>> The test BasicLauncherTest.java includes code leveraged from >> Yasumasa?s >>>> webrev for JDK-8163581. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> - Jini Susan George >>>> >>>> >>>> >>> >>> >>> -- >>> Dmitry Samersoff >>> Oracle Java development team, Saint Petersburg, Russia >>> * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Aug 24 11:42:46 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 24 Aug 2016 14:42:46 +0300 Subject: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools In-Reply-To: <1f8101d1fd71$feb399d0$fc1acd70$@oracle.com> References: <12dc677b-e33c-0345-4680-e97cc1604cbe@oracle.com> <57BC4B41.60305@oracle.com> <938232c7-c206-f0db-7446-78960537ad2b@oracle.com> <1f8101d1fd71$feb399d0$fc1acd70$@oracle.com> Message-ID: <9fc8324f-4f49-bb09-4f97-ba478d5368be@oracle.com> Christian, Thank you for the review. Please see updated webrev: http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.03/ I still have no ideas why this @build construction works with @run driver but doesn't work with @run main/othervm. Is there a chance to have all such knowledge documented? > You don't need to explicitly build JpsHelper, I would prefer to leave it as is - it's harmless but highlights TestJpsJar dependency. > would it make sense to change this to use the /test/lib ones and I'd tried it[1] and it doesn't work. jtreg claims that package jdk.test.lib doesn't exist.[2] 1. http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.02.bad/ 2. http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.02.bad/TestJpsClass.jtr -Dmitry On 2016-08-23 22:10, Christian Tornqvist wrote: > Hi Dmitry, > > You don't need to explicitly build JpsHelper, > I also noticed that > you're using ProcessTools and OutputAnalyzer from /lib/testlibrary , > would it make sense to change this to use the /test/lib ones and > simply have: > > @library /test/lib > > ? > > Thanks, Christian -----Original Message----- From: > hotspot-runtime-dev > [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of > Dmitry Samersoff Sent: Tuesday, August 23, 2016 3:02 PM To: Ioi Lam > ; serviceability-dev at openjdk.java.net; > hotspot-runtime-dev Subject: > Re: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java > fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools > > Ioi, > > Thank you for review. > > Hmm. It looks like changes below solves the problem. > > - * @build jdk.testlibrary.* JpsHelper JpsBase + * @build JpsHelper > JpsBase > > I'm running rbt job to verify it. > > -Dmitry > > On 2016-08-23 16:10, Ioi Lam wrote: >> Hi Dmitry, >> >> Why are you adding /test/lib: >> >> - * @library /lib/testlibrary + * @library /lib/testlibrary >> /test/lib >> >> The only class used by jdk/test/sun/tools/jps/*.java in /test/lib >> is here: >> >> TestJpsSanity.java:import jdk.test.lib.apps.LingeredApp; >> >> But TestJpsSanity.java is not use by this test -- I ran the test >> with your patch in a clean jtreg directory and the test passed, but >> I don't see TestJpsSanity.class, or any jdk.test.lib.* class. >> >> So I don't think you need to add /test/lib. >> >> - Ioi >> >> On 8/23/16 5:34 AM, Dmitry Samersoff wrote: >>> On 2016-08-17 10:51, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review the changes: >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ >>>> >>>> -Dmitry >>>> >>> >> > > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, > Russia * I would love to change the world, but they won't give me the > sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From stefan.johansson at oracle.com Wed Aug 24 14:09:46 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 24 Aug 2016 16:09:46 +0200 Subject: PING: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap In-Reply-To: <180629ce-a11a-26fb-bfe6-0739b4a5f60a@gmail.com> References: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> <180629ce-a11a-26fb-bfe6-0739b4a5f60a@gmail.com> Message-ID: Hi Yasumasa, Your change looks good. There might be more information that we want to add here in the future, but this is a good start. I would personally prefer the region info on its own line, but I don't have a very strong opinion. I can sponsor the change. Thanks, Stefan On 2016-08-23 15:17, Yasumasa Suenaga wrote: > PING: Could you review and sponsor it? > > Yasumasa > > On 2016/08/16 21:31, Yasumasa Suenaga wrote: >> Hi all, >> >> Have you checked changes for this issue? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/hotspot/ >> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ >> >> For example, ParallelScavengeHeap.java overrides printOn() method. >> This method shows addresses of each memory regions. >> >> My proposal shows memory region of G1CollectedHeap and region size. >> Please review and sponsor for it. If it is not enough, please tell me. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2016/08/11 23:15, Yasumasa Suenaga wrote: >>> Hi Jini, >>> >>> I added this check in new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/08/11 15:33, Jini Susan George wrote: >>>> Thank you for this fix, Yasumasa. This issue was manifested through >>>> the 'universe' command in clhsdb also, and your change fixes that. >>>> It would be great if you could modify BasicLauncherTest.java to >>>> have some testing done for this also. >>>> >>>> Thank you, >>>> Jini (Not a Reviewer). >>>> >>>>> -----Original Message----- >>>>> From: David Holmes >>>>> Sent: Thursday, August 11, 2016 10:03 AM >>>>> To: Yasumasa Suenaga; serviceability-dev at openjdk.java.net; >>>>> hotspot-gc- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle >>>>> G1CollectedHeap >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> Adding in GC folk. >>>>> >>>>> I agree with the need to override the printOn method, but can't >>>>> comment >>>>> on the details of what you are actually printing. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> When I chose "Heap Parameters" menu in HSDB, I got following value: >>>>>> -------------------- >>>>>> Heap Parameters: >>>>>> unknown subtype of CollectedHeap @ 0x00007f4d4c030510 >>>>>> (0x00000006c6e00000,0x00000007c0000000) >>>>>> -------------------- >>>>>> >>>>>> I think it should not be "unknown subtype". >>>>>> >>>>>> This value is shown by >>>>>> sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). >>>>>> This method is overrided in ParallelScavengeHeap and >>>>>> GenCollectedHeap. >>>>>> However, G1CollectedHeap does not override. >>>>>> >>>>>> I think G1CollectedHeap should override this method. >>>>>> >>>>>> I uploaded a webrev for this issue. >>>>>> Could you review it? >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ >>>>>> >>>>>> I'm jdk 9 committer, but I cannot access JPRT. >>>>>> So I need a sponsor. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> From yasuenag at gmail.com Wed Aug 24 14:19:20 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 24 Aug 2016 23:19:20 +0900 Subject: PING: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap In-Reply-To: References: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> <180629ce-a11a-26fb-bfe6-0739b4a5f60a@gmail.com> Message-ID: <9070293d-b78e-4435-12fd-903a8e62aad1@gmail.com> Thanks Stefan! I'm waiting a second reviewer. Yasumasa On 2016/08/24 23:09, Stefan Johansson wrote: > Hi Yasumasa, > > Your change looks good. There might be more information that we want to add here in the future, but this is a good start. I would personally prefer the region info on its own line, but I don't have a very strong opinion. > > I can sponsor the change. > > Thanks, > Stefan > > > On 2016-08-23 15:17, Yasumasa Suenaga wrote: >> PING: Could you review and sponsor it? >> >> Yasumasa >> >> On 2016/08/16 21:31, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Have you checked changes for this issue? >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/hotspot/ >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ >>> >>> For example, ParallelScavengeHeap.java overrides printOn() method. >>> This method shows addresses of each memory regions. >>> >>> My proposal shows memory region of G1CollectedHeap and region size. >>> Please review and sponsor for it. If it is not enough, please tell me. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2016/08/11 23:15, Yasumasa Suenaga wrote: >>>> Hi Jini, >>>> >>>> I added this check in new webrev: >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/08/11 15:33, Jini Susan George wrote: >>>>> Thank you for this fix, Yasumasa. This issue was manifested through the 'universe' command in clhsdb also, and your change fixes that. It would be great if you could modify BasicLauncherTest.java to have some testing done for this also. >>>>> >>>>> Thank you, >>>>> Jini (Not a Reviewer). >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes >>>>>> Sent: Thursday, August 11, 2016 10:03 AM >>>>>> To: Yasumasa Suenaga; serviceability-dev at openjdk.java.net; hotspot-gc- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle >>>>>> G1CollectedHeap >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> Adding in GC folk. >>>>>> >>>>>> I agree with the need to override the printOn method, but can't comment >>>>>> on the details of what you are actually printing. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> When I chose "Heap Parameters" menu in HSDB, I got following value: >>>>>>> -------------------- >>>>>>> Heap Parameters: >>>>>>> unknown subtype of CollectedHeap @ 0x00007f4d4c030510 >>>>>>> (0x00000006c6e00000,0x00000007c0000000) >>>>>>> -------------------- >>>>>>> >>>>>>> I think it should not be "unknown subtype". >>>>>>> >>>>>>> This value is shown by sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). >>>>>>> This method is overrided in ParallelScavengeHeap and GenCollectedHeap. >>>>>>> However, G1CollectedHeap does not override. >>>>>>> >>>>>>> I think G1CollectedHeap should override this method. >>>>>>> >>>>>>> I uploaded a webrev for this issue. >>>>>>> Could you review it? >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ >>>>>>> >>>>>>> I'm jdk 9 committer, but I cannot access JPRT. >>>>>>> So I need a sponsor. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> > From serguei.spitsyn at oracle.com Wed Aug 24 20:22:22 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Aug 2016 13:22:22 -0700 Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" In-Reply-To: References: Message-ID: <57BE01FE.8070800@oracle.com> Hi Alexander, It is great that you developed a test coverage for this feature. Just wanted to let you know that I'm reviewing your fix now. Did you get any other reviews yet? Thanks, Serguei On 8/12/16 05:55, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only change (adding a new test): > > CR: https://bugs.openjdk.java.net/browse/JDK-8148103 > Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/ > > The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. > > It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. > > When started the debuggee reports its loaded modules to the test. > The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. > For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. > Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. > > Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. > The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. > > Best regards, > Alexander From david.holmes at oracle.com Wed Aug 24 22:11:47 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Aug 2016 08:11:47 +1000 Subject: PING: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle G1CollectedHeap In-Reply-To: <9070293d-b78e-4435-12fd-903a8e62aad1@gmail.com> References: <442a1564-4b55-a012-86b5-ccb4c713cc1e@gmail.com> <34b3b2df-ebe2-49e5-001d-ce717acfcbf3@oracle.com> <180629ce-a11a-26fb-bfe6-0739b4a5f60a@gmail.com> <9070293d-b78e-4435-12fd-903a8e62aad1@gmail.com> Message-ID: On 25/08/2016 12:19 AM, Yasumasa Suenaga wrote: > Thanks Stefan! > > I'm waiting a second reviewer. Stefan has covered as the GC aspect (thanks!) I have Reviewed in the more general sense. Thanks, David > > Yasumasa > > > On 2016/08/24 23:09, Stefan Johansson wrote: >> Hi Yasumasa, >> >> Your change looks good. There might be more information that we want >> to add here in the future, but this is a good start. I would >> personally prefer the region info on its own line, but I don't have a >> very strong opinion. >> >> I can sponsor the change. >> >> Thanks, >> Stefan >> >> >> On 2016-08-23 15:17, Yasumasa Suenaga wrote: >>> PING: Could you review and sponsor it? >>> >>> Yasumasa >>> >>> On 2016/08/16 21:31, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Have you checked changes for this issue? >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/hotspot/ >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ >>>> >>>> For example, ParallelScavengeHeap.java overrides printOn() method. >>>> This method shows addresses of each memory regions. >>>> >>>> My proposal shows memory region of G1CollectedHeap and region size. >>>> Please review and sponsor for it. If it is not enough, please tell me. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2016/08/11 23:15, Yasumasa Suenaga wrote: >>>>> Hi Jini, >>>>> >>>>> I added this check in new webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.01/jdk/ >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2016/08/11 15:33, Jini Susan George wrote: >>>>>> Thank you for this fix, Yasumasa. This issue was manifested >>>>>> through the 'universe' command in clhsdb also, and your change >>>>>> fixes that. It would be great if you could modify >>>>>> BasicLauncherTest.java to have some testing done for this also. >>>>>> >>>>>> Thank you, >>>>>> Jini (Not a Reviewer). >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes >>>>>>> Sent: Thursday, August 11, 2016 10:03 AM >>>>>>> To: Yasumasa Suenaga; serviceability-dev at openjdk.java.net; >>>>>>> hotspot-gc- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR: JDK-8163581: Heap Parameters in HSDB cannot handle >>>>>>> G1CollectedHeap >>>>>>> >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> Adding in GC folk. >>>>>>> >>>>>>> I agree with the need to override the printOn method, but can't >>>>>>> comment >>>>>>> on the details of what you are actually printing. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 10/08/2016 10:20 PM, Yasumasa Suenaga wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> When I chose "Heap Parameters" menu in HSDB, I got following value: >>>>>>>> -------------------- >>>>>>>> Heap Parameters: >>>>>>>> unknown subtype of CollectedHeap @ 0x00007f4d4c030510 >>>>>>>> (0x00000006c6e00000,0x00000007c0000000) >>>>>>>> -------------------- >>>>>>>> >>>>>>>> I think it should not be "unknown subtype". >>>>>>>> >>>>>>>> This value is shown by >>>>>>>> sun.jvm.hotspot.gc.shared.CollectedHeap#printOn(). >>>>>>>> This method is overrided in ParallelScavengeHeap and >>>>>>>> GenCollectedHeap. >>>>>>>> However, G1CollectedHeap does not override. >>>>>>>> >>>>>>>> I think G1CollectedHeap should override this method. >>>>>>>> >>>>>>>> I uploaded a webrev for this issue. >>>>>>>> Could you review it? >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8163581/webrev.00/ >>>>>>>> >>>>>>>> I'm jdk 9 committer, but I cannot access JPRT. >>>>>>>> So I need a sponsor. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >> From harsha.wardhana.b at oracle.com Thu Aug 25 06:40:16 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 25 Aug 2016 12:10:16 +0530 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: <5d84e9ca-1a7f-b3b2-1a0b-27fce0ad364c@oracle.com> References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> <476E2856-F1E6-4F61-8389-CF395231F5EC@oracle.com> <5d84e9ca-1a7f-b3b2-1a0b-27fce0ad364c@oracle.com> Message-ID: <140fa4e0-a3e6-5144-3125-27c06fb0e3d2@oracle.com> Hi All, Please review modified webrev located at, http://cr.openjdk.java.net/~hb/8131061/webrev.02/ Regards Harsha On Wednesday 24 August 2016 11:28 AM, Harsha Wardhana B wrote: > > > On Wednesday 24 August 2016 01:10 AM, Mandy Chung wrote: >>> On Aug 23, 2016, at 8:21 AM, Daniel Fuchs >>> wrote: >>> >>> On 23/08/16 15:45, Harsha Wardhana B wrote: >>>> Hi Daniel, >>>> >>>> The focus of this issue was to decouple hard-dependency between >>>> java.management module and jdk.snmp module since jdk.snmp is not a >>>> core >>>> module. There was not much focus on an 'Agent' Interface that could >>>> allow plugging in any Agent. Hence there was no discussions around the >>>> structure of such an interface. >>>> >>> OK - sun/management/spi/AgentProvider.java is a private >>> interface that only classes in the JDK can implement, and >>> is not designed to be extended outside of the JDK, so I >>> agree that what you have seems to be sufficient for the purpose >>> of decoupling. Because nothing outside of the JDK can implement >>> it then it can be revisited and amended later if we have other uses. >>> >> Correct this is a private interface that can be changed in any future >> release. This work allows the SNMP management agent be loaded via >> service binding rather than requiring the module be explicitly added >> to the module graph. >> >> Daniel is closer to the snmp agent implementation and I agree that >> AgentProvider can be simplified. See my comment inlined below. >> >>> On Aug 23, 2016, at 3:41 AM, Daniel Fuchs >>> wrote: >>> >>> On 22/08/16 22:58, Mandy Chung wrote: >>>> sun/management/spi/AgentProvider.java >>>> 78 public abstract void startAgent(String port, Properties >>>> props); >>>> >>>> The port parameter should be ?int?. >>>> >>> I wonder about that. I wonder if the name of the agent provider >>> should be the name of the property that starts it - for >>> instance - we could have an agent provider whose name is >>> ?com.sun.management.snmp.port" >> ?com.sun.management.snmp.port? be the provider name seems confusing >> (it?s an agent but not a port). I considered naming it with >> ?com.sun.management.snmp.Agent? but since the name is private >> interface, a simple name would work. >> >>> - and the first parameter to >>> startAgent would be the value associated with that >>> property (we'd renamed the port parameter into e.g. >>> propertyValue). >>> >>> Then it would be up to the agent provider to interpret the >>> property value however it sees fit. In this example - a >>> provider deployed as responding to the "com.sun.management.snmp.port" >>> property would interpret the value of the property as the SNMP >>> port number of the SNMP agent to start. >>> >>> Our implementation could still only look for an agent >>> provider named "com.sun.management.snmp.port" (instead of >>> "SnmpAgent") - but that could be extended in the future >>> if we ever want to start more (different) agents. >>> >> While it?s easy to rev the interface multiple agents, we should wait >> until it?s really needed. >> >> I wasn?t aware of any customer using SNMP management support. IMO we >> should consider if SNMP support should be deprecated for removal. So >> I would keep the change minimal. >> >>> Also I'm not sure the AgentProvider should have a getPort() method. >>> I don't see were it is used? Is it for debugging purposes? >>> If so maybe it should be getAddress() and return a informal String. >>> >> Good point - it should be an address rather than a port number. If >> it?s not used, let?s drop it. I also suggest to drop the ?port? >> parameter and the snmp agent can get the >> ?com.sun.management.snmp.port? property from the specified props. >> >> public abstract void startAgent(Properties props); >> >> Harsha - are you okay with that? > Yes. I am fine with it. >> >> Mandy > Harsha From marcus.larsson at oracle.com Thu Aug 25 07:51:48 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 25 Aug 2016 09:51:48 +0200 Subject: [PING] Re: RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <307928f7-55b3-999d-b3e8-ffd5966457a1@oracle.com> References: <5704B0B0.4010404@oracle.com> <570D02CF.7070708@oracle.com> <307928f7-55b3-999d-b3e8-ffd5966457a1@oracle.com> Message-ID: <85b62937-09e4-f5e5-86c4-c02ee487c63c@oracle.com> On 08/23/2016 01:17 PM, Marcus Larsson wrote: > Hi, > > Still looking for a Reviewer for this. (Rebased webrev in-place.) > > Thanks, > Marcus > > > On 04/12/2016 04:14 PM, Marcus Larsson wrote: >> Ping! >> >> On 04/06/2016 08:46 AM, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to add a warning for when tag >>> selections in -Xlog or VM.log don't match any tag sets used in the VM. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8150894 >>> >>> Testing: >>> Internal VM tests with RBT >>> >>> Thanks, >>> Marcus >> > From staffan.larsen at oracle.com Thu Aug 25 08:15:38 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 25 Aug 2016 10:15:38 +0200 Subject: [PING] RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <85b62937-09e4-f5e5-86c4-c02ee487c63c@oracle.com> References: <5704B0B0.4010404@oracle.com> <570D02CF.7070708@oracle.com> <307928f7-55b3-999d-b3e8-ffd5966457a1@oracle.com> <85b62937-09e4-f5e5-86c4-c02ee487c63c@oracle.com> Message-ID: <4467DDF3-0FE6-4891-AF50-087944881D98@oracle.com> Looks ok to me. /Staffan > On 25 aug. 2016, at 09:51, Marcus Larsson wrote: > > > On 08/23/2016 01:17 PM, Marcus Larsson wrote: >> Hi, >> >> Still looking for a Reviewer for this. (Rebased webrev in-place.) >> >> Thanks, >> Marcus >> >> >> On 04/12/2016 04:14 PM, Marcus Larsson wrote: >>> Ping! >>> >>> On 04/06/2016 08:46 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to add a warning for when tag selections in -Xlog or VM.log don't match any tag sets used in the VM. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8150894 >>>> >>>> Testing: >>>> Internal VM tests with RBT >>>> >>>> Thanks, >>>> Marcus >>> >> > From marcus.larsson at oracle.com Thu Aug 25 08:18:52 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Thu, 25 Aug 2016 10:18:52 +0200 Subject: [PING] RFR: 8150894: Unused -Xlog tag sequences are silently ignored. In-Reply-To: <4467DDF3-0FE6-4891-AF50-087944881D98@oracle.com> References: <5704B0B0.4010404@oracle.com> <570D02CF.7070708@oracle.com> <307928f7-55b3-999d-b3e8-ffd5966457a1@oracle.com> <85b62937-09e4-f5e5-86c4-c02ee487c63c@oracle.com> <4467DDF3-0FE6-4891-AF50-087944881D98@oracle.com> Message-ID: Thanks Staffan! Marcus On 08/25/2016 10:15 AM, Staffan Larsen wrote: > Looks ok to me. > > /Staffan > >> On 25 aug. 2016, at 09:51, Marcus Larsson wrote: >> >> >> On 08/23/2016 01:17 PM, Marcus Larsson wrote: >>> Hi, >>> >>> Still looking for a Reviewer for this. (Rebased webrev in-place.) >>> >>> Thanks, >>> Marcus >>> >>> >>> On 04/12/2016 04:14 PM, Marcus Larsson wrote: >>>> Ping! >>>> >>>> On 04/06/2016 08:46 AM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to add a warning for when tag selections in -Xlog or VM.log don't match any tag sets used in the VM. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8150894/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8150894 >>>>> >>>>> Testing: >>>>> Internal VM tests with RBT >>>>> >>>>> Thanks, >>>>> Marcus From harsha.wardhana.b at oracle.com Thu Aug 25 08:19:34 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 25 Aug 2016 13:49:34 +0530 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> Message-ID: Hello All, Please find below the revised webrev below. http://cr.openjdk.java.net/~hb/8161448/webrev.01/ Regards Harsha On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: > Hi David, > > > On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >> Hi Harsha, >> >> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>> Hello All, >>> >>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>> >>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >> >> Looks functionally correct, but I wouldn't complain if you wanted to >> use a macro to reduce the duplication and verbosity. Even the: >> >> 109 if (obj == NULL) { >> 110 free(dcmd_arg_info_array); >> 111 return NULL; >> >> can be replaced by an exception-check as that is the only time >> JNU_NewObjectByName can return NULL. > I am not sure if using macro here is good practice since it will be > specific to the function and it will encapsulate the local variable > within it. Also, it will reduce code readability. Hence I would like > to leave it as is. >> >> I also noticed an issue that was flagged in some other JNI code lately: >> >> 213 if (obj == NULL) { >> 214 free(dcmd_info_array); >> 215 JNU_ThrowOutOfMemoryError(env, 0); >> 216 return NULL; >> >> If obj == NULL then there is already a pending exception and we >> should not be throwing OOME. >> > Sure. This needs to be fixed. >> Thanks, >> David >> >>> Regards >>> >>> Harsha >>> > Harsha From daniel.fuchs at oracle.com Thu Aug 25 08:45:14 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 25 Aug 2016 09:45:14 +0100 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: <140fa4e0-a3e6-5144-3125-27c06fb0e3d2@oracle.com> References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> <476E2856-F1E6-4F61-8389-CF395231F5EC@oracle.com> <5d84e9ca-1a7f-b3b2-1a0b-27fce0ad364c@oracle.com> <140fa4e0-a3e6-5144-3125-27c06fb0e3d2@oracle.com> Message-ID: <97b16fcc-e321-dfa9-1e7c-6a0b242704f5@oracle.com> On 25/08/16 07:40, Harsha Wardhana B wrote: > Hi All, > > Please review modified webrev located at, > > http://cr.openjdk.java.net/~hb/8131061/webrev.02/ > > Regards > > Harsha Hi Harsha, Looks good to me! best regards, -- daniel > > > On Wednesday 24 August 2016 11:28 AM, Harsha Wardhana B wrote: >> >> >> On Wednesday 24 August 2016 01:10 AM, Mandy Chung wrote: >>>> On Aug 23, 2016, at 8:21 AM, Daniel Fuchs >>>> wrote: >>>> >>>> On 23/08/16 15:45, Harsha Wardhana B wrote: >>>>> Hi Daniel, >>>>> >>>>> The focus of this issue was to decouple hard-dependency between >>>>> java.management module and jdk.snmp module since jdk.snmp is not a >>>>> core >>>>> module. There was not much focus on an 'Agent' Interface that could >>>>> allow plugging in any Agent. Hence there was no discussions around the >>>>> structure of such an interface. >>>>> >>>> OK - sun/management/spi/AgentProvider.java is a private >>>> interface that only classes in the JDK can implement, and >>>> is not designed to be extended outside of the JDK, so I >>>> agree that what you have seems to be sufficient for the purpose >>>> of decoupling. Because nothing outside of the JDK can implement >>>> it then it can be revisited and amended later if we have other uses. >>>> >>> Correct this is a private interface that can be changed in any future >>> release. This work allows the SNMP management agent be loaded via >>> service binding rather than requiring the module be explicitly added >>> to the module graph. >>> >>> Daniel is closer to the snmp agent implementation and I agree that >>> AgentProvider can be simplified. See my comment inlined below. >>> >>>> On Aug 23, 2016, at 3:41 AM, Daniel Fuchs >>>> wrote: >>>> >>>> On 22/08/16 22:58, Mandy Chung wrote: >>>>> sun/management/spi/AgentProvider.java >>>>> 78 public abstract void startAgent(String port, Properties >>>>> props); >>>>> >>>>> The port parameter should be ?int?. >>>>> >>>> I wonder about that. I wonder if the name of the agent provider >>>> should be the name of the property that starts it - for >>>> instance - we could have an agent provider whose name is >>>> ?com.sun.management.snmp.port" >>> ?com.sun.management.snmp.port? be the provider name seems confusing >>> (it?s an agent but not a port). I considered naming it with >>> ?com.sun.management.snmp.Agent? but since the name is private >>> interface, a simple name would work. >>> >>>> - and the first parameter to >>>> startAgent would be the value associated with that >>>> property (we'd renamed the port parameter into e.g. >>>> propertyValue). >>>> >>>> Then it would be up to the agent provider to interpret the >>>> property value however it sees fit. In this example - a >>>> provider deployed as responding to the "com.sun.management.snmp.port" >>>> property would interpret the value of the property as the SNMP >>>> port number of the SNMP agent to start. >>>> >>>> Our implementation could still only look for an agent >>>> provider named "com.sun.management.snmp.port" (instead of >>>> "SnmpAgent") - but that could be extended in the future >>>> if we ever want to start more (different) agents. >>>> >>> While it?s easy to rev the interface multiple agents, we should wait >>> until it?s really needed. >>> >>> I wasn?t aware of any customer using SNMP management support. IMO we >>> should consider if SNMP support should be deprecated for removal. So >>> I would keep the change minimal. >>> >>>> Also I'm not sure the AgentProvider should have a getPort() method. >>>> I don't see were it is used? Is it for debugging purposes? >>>> If so maybe it should be getAddress() and return a informal String. >>>> >>> Good point - it should be an address rather than a port number. If >>> it?s not used, let?s drop it. I also suggest to drop the ?port? >>> parameter and the snmp agent can get the >>> ?com.sun.management.snmp.port? property from the specified props. >>> >>> public abstract void startAgent(Properties props); >>> >>> Harsha - are you okay with that? >> Yes. I am fine with it. >>> >>> Mandy >> Harsha > From sharath.ballal at oracle.com Thu Aug 25 10:14:03 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 25 Aug 2016 03:14:03 -0700 (PDT) Subject: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. In-Reply-To: <1422f4e1-1d40-4693-9412-4ee06c9b1499@default> References: <8ad9f953-205a-c331-e642-46016eefc740@oracle.com> <9223accd-8611-7b2c-dd00-1a136783b4ff@oracle.com> <1422f4e1-1d40-4693-9412-4ee06c9b1499@default> Message-ID: Dmitry has reviewed this fix of changes in the testcase. Could anybody else review it as a second reviewer ? -Sharath Ballal -----Original Message----- From: Sharath Ballal Sent: Monday, August 22, 2016 9:57 PM To: Dmitry Samersoff Cc: Arvind Aprameya Subject: RE: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. Hi Dmitry, I have made the suggested changes. As discussed, I have also excluded HeapDumpTest.java from running on MAC OS to avoid hitting JDK-8160376 - DebuggerException: Can't attach symbolicator to the process Webrev: http://cr.openjdk.java.net/~sballal/8163346/webrev.02/ Rbt: https://jdash.se.oracle.com/rbt/rbt-sharath.ballal-dev_agentpath-20160822-0952-21583 -Sharath Ballal -----Original Message----- From: Dmitry Samersoff Sent: Friday, August 19, 2016 3:51 PM To: Sharath Ballal; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. Sharath, Looks good for me. Please, move LingeredAppWithExtendedChars.java to the test directory, it's test-specific code and it shouldn't be in the library (no need for re-review). -Dmitry On 2016-08-17 19:12, Sharath Ballal wrote: > Hello Dmitry, > Thanks for the review. I have done the changes, pls have a look: > > http://cr.openjdk.java.net/~sballal/8163346/webrev.01/ > > -Sharath Ballal > > > -----Original Message----- > From: Dmitry Samersoff > Sent: Wednesday, August 10, 2016 1:16 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. > > Sharath, > > As soon as you request a heap dump of LingeredApp, LingeredApp should contains the object with extended characters in it's name. > > So please: > > 1. Inherit LingeredApp (See LingeredAppWithDeadlock as an example) and > add > > public static int \u00CB = 1; > > 2. Copy BasicLauncherTest to HeapDumpWitExtCharsTest.java and change > it according to you needs (i.e. remove everything but > heapDumpTest) > > 3. Remove Test8028623.java > > -Dmitry > > > On 2016-08-08 12:37, Sharath Ballal wrote: >> Hello, >> >> Pls review the following fix for modifying the testcase >> jmap-hashcode/Test8028623.java to use LingeredApp. >> >> >> >> http://cr.openjdk.java.net/~sballal/8163346/webrev.00/ >> >> >> >> Link to bug: https://bugs.openjdk.java.net/browse/JDK-8163346 >> >> >> >> -Sharath Ballal >> >> >> >> >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alexander.kulyakhtin at oracle.com Thu Aug 25 11:56:15 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Thu, 25 Aug 2016 04:56:15 -0700 (PDT) Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" Message-ID: <7ef0724a-8ea2-4f1e-bd74-6cc17887a029@default> Hi Sergey, Most unfortunately, the test is failing on 32-bit machines only with https://bugs.openjdk.java.net/browse/JDK-8164490. It may well be a test issue, so I appreciate your looking at the test source. I was not able to locate any issue with the test and it runs fine on 64-bit machines. Perhaps, it has to do with any difference in JDWP strings representation on 32/64 machines? Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Cc: christian.tornqvist at oracle.com Sent: Wednesday, August 24, 2016 11:22:23 PM GMT +03:00 Iraq Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" Hi Alexander, It is great that you developed a test coverage for this feature. Just wanted to let you know that I'm reviewing your fix now. Did you get any other reviews yet? Thanks, Serguei On 8/12/16 05:55, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only change (adding a new test): > > CR: https://bugs.openjdk.java.net/browse/JDK-8148103 > Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/ > > The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. > > It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. > > When started the debuggee reports its loaded modules to the test. > The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. > For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. > Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. > > Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. > The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. > > Best regards, > Alexander From david.holmes at oracle.com Thu Aug 25 12:26:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Aug 2016 22:26:14 +1000 Subject: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. In-Reply-To: References: <8ad9f953-205a-c331-e642-46016eefc740@oracle.com> <9223accd-8611-7b2c-dd00-1a136783b4ff@oracle.com> <1422f4e1-1d40-4693-9412-4ee06c9b1499@default> Message-ID: Hi Sharath, I've taken a look at this refactoring of the test and it seems okay. Thanks, David On 25/08/2016 8:14 PM, Sharath Ballal wrote: > Dmitry has reviewed this fix of changes in the testcase. Could anybody else review it as a second reviewer ? > > > -Sharath Ballal > > > > -----Original Message----- > From: Sharath Ballal > Sent: Monday, August 22, 2016 9:57 PM > To: Dmitry Samersoff > Cc: Arvind Aprameya > Subject: RE: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. > > Hi Dmitry, > > I have made the suggested changes. As discussed, I have also excluded HeapDumpTest.java from running on MAC OS to avoid hitting > JDK-8160376 - DebuggerException: Can't attach symbolicator to the process > > Webrev: http://cr.openjdk.java.net/~sballal/8163346/webrev.02/ > > Rbt: https://jdash.se.oracle.com/rbt/rbt-sharath.ballal-dev_agentpath-20160822-0952-21583 > > > -Sharath Ballal > > > -----Original Message----- > From: Dmitry Samersoff > Sent: Friday, August 19, 2016 3:51 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. > > Sharath, > > Looks good for me. > > Please, move LingeredAppWithExtendedChars.java to the test directory, it's test-specific code and it shouldn't be in the library (no need for re-review). > > -Dmitry > > On 2016-08-17 19:12, Sharath Ballal wrote: >> Hello Dmitry, >> Thanks for the review. I have done the changes, pls have a look: >> >> http://cr.openjdk.java.net/~sballal/8163346/webrev.01/ >> >> -Sharath Ballal >> >> >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Wednesday, August 10, 2016 1:16 PM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. >> >> Sharath, >> >> As soon as you request a heap dump of LingeredApp, LingeredApp should contains the object with extended characters in it's name. >> >> So please: >> >> 1. Inherit LingeredApp (See LingeredAppWithDeadlock as an example) and >> add >> >> public static int \u00CB = 1; >> >> 2. Copy BasicLauncherTest to HeapDumpWitExtCharsTest.java and change >> it according to you needs (i.e. remove everything but >> heapDumpTest) >> >> 3. Remove Test8028623.java >> >> -Dmitry >> >> >> On 2016-08-08 12:37, Sharath Ballal wrote: >>> Hello, >>> >>> Pls review the following fix for modifying the testcase >>> jmap-hashcode/Test8028623.java to use LingeredApp. >>> >>> >>> >>> http://cr.openjdk.java.net/~sballal/8163346/webrev.00/ >>> >>> >>> >>> Link to bug: https://bugs.openjdk.java.net/browse/JDK-8163346 >>> >>> >>> >>> -Sharath Ballal >>> >>> >>> >>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > From harsha.wardhana.b at oracle.com Thu Aug 25 13:52:03 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Thu, 25 Aug 2016 19:22:03 +0530 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: <97b16fcc-e321-dfa9-1e7c-6a0b242704f5@oracle.com> References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> <476E2856-F1E6-4F61-8389-CF395231F5EC@oracle.com> <5d84e9ca-1a7f-b3b2-1a0b-27fce0ad364c@oracle.com> <140fa4e0-a3e6-5144-3125-27c06fb0e3d2@oracle.com> <97b16fcc-e321-dfa9-1e7c-6a0b242704f5@oracle.com> Message-ID: <6112f912-0a17-cefa-4d7d-f6f8ab9591a2@oracle.com> Thanks for the review Daniel. -Harsha On Thursday 25 August 2016 02:15 PM, Daniel Fuchs wrote: > On 25/08/16 07:40, Harsha Wardhana B wrote: >> Hi All, >> >> Please review modified webrev located at, >> >> http://cr.openjdk.java.net/~hb/8131061/webrev.02/ >> >> Regards >> >> Harsha > > Hi Harsha, > > Looks good to me! > > best regards, > > -- daniel > >> >> >> On Wednesday 24 August 2016 11:28 AM, Harsha Wardhana B wrote: >>> >>> >>> On Wednesday 24 August 2016 01:10 AM, Mandy Chung wrote: >>>>> On Aug 23, 2016, at 8:21 AM, Daniel Fuchs >>>>> wrote: >>>>> >>>>> On 23/08/16 15:45, Harsha Wardhana B wrote: >>>>>> Hi Daniel, >>>>>> >>>>>> The focus of this issue was to decouple hard-dependency between >>>>>> java.management module and jdk.snmp module since jdk.snmp is not a >>>>>> core >>>>>> module. There was not much focus on an 'Agent' Interface that could >>>>>> allow plugging in any Agent. Hence there was no discussions >>>>>> around the >>>>>> structure of such an interface. >>>>>> >>>>> OK - sun/management/spi/AgentProvider.java is a private >>>>> interface that only classes in the JDK can implement, and >>>>> is not designed to be extended outside of the JDK, so I >>>>> agree that what you have seems to be sufficient for the purpose >>>>> of decoupling. Because nothing outside of the JDK can implement >>>>> it then it can be revisited and amended later if we have other uses. >>>>> >>>> Correct this is a private interface that can be changed in any future >>>> release. This work allows the SNMP management agent be loaded via >>>> service binding rather than requiring the module be explicitly added >>>> to the module graph. >>>> >>>> Daniel is closer to the snmp agent implementation and I agree that >>>> AgentProvider can be simplified. See my comment inlined below. >>>> >>>>> On Aug 23, 2016, at 3:41 AM, Daniel Fuchs >>>>> wrote: >>>>> >>>>> On 22/08/16 22:58, Mandy Chung wrote: >>>>>> sun/management/spi/AgentProvider.java >>>>>> 78 public abstract void startAgent(String port, Properties >>>>>> props); >>>>>> >>>>>> The port parameter should be ?int?. >>>>>> >>>>> I wonder about that. I wonder if the name of the agent provider >>>>> should be the name of the property that starts it - for >>>>> instance - we could have an agent provider whose name is >>>>> ?com.sun.management.snmp.port" >>>> ?com.sun.management.snmp.port? be the provider name seems confusing >>>> (it?s an agent but not a port). I considered naming it with >>>> ?com.sun.management.snmp.Agent? but since the name is private >>>> interface, a simple name would work. >>>> >>>>> - and the first parameter to >>>>> startAgent would be the value associated with that >>>>> property (we'd renamed the port parameter into e.g. >>>>> propertyValue). >>>>> >>>>> Then it would be up to the agent provider to interpret the >>>>> property value however it sees fit. In this example - a >>>>> provider deployed as responding to the "com.sun.management.snmp.port" >>>>> property would interpret the value of the property as the SNMP >>>>> port number of the SNMP agent to start. >>>>> >>>>> Our implementation could still only look for an agent >>>>> provider named "com.sun.management.snmp.port" (instead of >>>>> "SnmpAgent") - but that could be extended in the future >>>>> if we ever want to start more (different) agents. >>>>> >>>> While it?s easy to rev the interface multiple agents, we should wait >>>> until it?s really needed. >>>> >>>> I wasn?t aware of any customer using SNMP management support. IMO we >>>> should consider if SNMP support should be deprecated for removal. So >>>> I would keep the change minimal. >>>> >>>>> Also I'm not sure the AgentProvider should have a getPort() method. >>>>> I don't see were it is used? Is it for debugging purposes? >>>>> If so maybe it should be getAddress() and return a informal String. >>>>> >>>> Good point - it should be an address rather than a port number. If >>>> it?s not used, let?s drop it. I also suggest to drop the ?port? >>>> parameter and the snmp agent can get the >>>> ?com.sun.management.snmp.port? property from the specified props. >>>> >>>> public abstract void startAgent(Properties props); >>>> >>>> Harsha - are you okay with that? >>> Yes. I am fine with it. >>>> >>>> Mandy >>> Harsha >> > From mandy.chung at oracle.com Thu Aug 25 14:44:36 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Aug 2016 07:44:36 -0700 Subject: RFR : 8131061 - Use of -Dcom.sun.management.snmp needs to be examined for modules In-Reply-To: <140fa4e0-a3e6-5144-3125-27c06fb0e3d2@oracle.com> References: <26688bd9-1884-d0bd-6362-5fc07d532f89@oracle.com> <27C0EB51-D3A4-4DD9-8C5F-6BD05AD3CAB9@oracle.com> <476E2856-F1E6-4F61-8389-CF395231F5EC@oracle.com> <5d84e9ca-1a7f-b3b2-1a0b-27fce0ad364c@oracle.com> <140fa4e0-a3e6-5144-3125-27c06fb0e3d2@oracle.com> Message-ID: > On Aug 24, 2016, at 11:40 PM, Harsha Wardhana B wrote: > > Hi All, > > Please review modified webrev located at, > > http://cr.openjdk.java.net/~hb/8131061/webrev.02/ +1 Mandy From sharath.ballal at oracle.com Thu Aug 25 17:23:58 2016 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 25 Aug 2016 10:23:58 -0700 (PDT) Subject: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. In-Reply-To: References: <8ad9f953-205a-c331-e642-46016eefc740@oracle.com> <9223accd-8611-7b2c-dd00-1a136783b4ff@oracle.com> <1422f4e1-1d40-4693-9412-4ee06c9b1499@default> Message-ID: <97beb226-8a42-4142-bfe2-d0bdf213d935@default> Thanks David. -Sharath Ballal -----Original Message----- From: David Holmes Sent: Thursday, August 25, 2016 5:56 PM To: Sharath Ballal; Dmitry Samersoff; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. Hi Sharath, I've taken a look at this refactoring of the test and it seems okay. Thanks, David On 25/08/2016 8:14 PM, Sharath Ballal wrote: > Dmitry has reviewed this fix of changes in the testcase. Could anybody else review it as a second reviewer ? > > > -Sharath Ballal > > > > -----Original Message----- > From: Sharath Ballal > Sent: Monday, August 22, 2016 9:57 PM > To: Dmitry Samersoff > Cc: Arvind Aprameya > Subject: RE: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. > > Hi Dmitry, > > I have made the suggested changes. As discussed, I have also excluded > HeapDumpTest.java from running on MAC OS to avoid hitting > JDK-8160376 - DebuggerException: Can't attach symbolicator to the > process > > Webrev: http://cr.openjdk.java.net/~sballal/8163346/webrev.02/ > > Rbt: > https://jdash.se.oracle.com/rbt/rbt-sharath.ballal-dev_agentpath-20160 > 822-0952-21583 > > > -Sharath Ballal > > > -----Original Message----- > From: Dmitry Samersoff > Sent: Friday, August 19, 2016 3:51 PM > To: Sharath Ballal; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. > > Sharath, > > Looks good for me. > > Please, move LingeredAppWithExtendedChars.java to the test directory, it's test-specific code and it shouldn't be in the library (no need for re-review). > > -Dmitry > > On 2016-08-17 19:12, Sharath Ballal wrote: >> Hello Dmitry, >> Thanks for the review. I have done the changes, pls have a look: >> >> http://cr.openjdk.java.net/~sballal/8163346/webrev.01/ >> >> -Sharath Ballal >> >> >> -----Original Message----- >> From: Dmitry Samersoff >> Sent: Wednesday, August 10, 2016 1:16 PM >> To: Sharath Ballal; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8163346: Update jmap-hashcode/Test8028623.java for better diagnostic of timeout. >> >> Sharath, >> >> As soon as you request a heap dump of LingeredApp, LingeredApp should contains the object with extended characters in it's name. >> >> So please: >> >> 1. Inherit LingeredApp (See LingeredAppWithDeadlock as an example) >> and add >> >> public static int \u00CB = 1; >> >> 2. Copy BasicLauncherTest to HeapDumpWitExtCharsTest.java and change >> it according to you needs (i.e. remove everything but >> heapDumpTest) >> >> 3. Remove Test8028623.java >> >> -Dmitry >> >> >> On 2016-08-08 12:37, Sharath Ballal wrote: >>> Hello, >>> >>> Pls review the following fix for modifying the testcase >>> jmap-hashcode/Test8028623.java to use LingeredApp. >>> >>> >>> >>> http://cr.openjdk.java.net/~sballal/8163346/webrev.00/ >>> >>> >>> >>> Link to bug: https://bugs.openjdk.java.net/browse/JDK-8163346 >>> >>> >>> >>> -Sharath Ballal >>> >>> >>> >>> >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. > From serguei.spitsyn at oracle.com Thu Aug 25 17:42:10 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Aug 2016 10:42:10 -0700 Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" In-Reply-To: <7ef0724a-8ea2-4f1e-bd74-6cc17887a029@default> References: <7ef0724a-8ea2-4f1e-bd74-6cc17887a029@default> Message-ID: <57BF2DF2.4000002@oracle.com> Hi Alexander, The error code 42 is INVALID_MODULE: *INVALID_MODULE* 42 Invalid module. It means that the moduleID passed to the JDWP is not correct. So that we have to check if the moduleID format is correct for 32-bit. The moduleID type is specified as: *moduleID* same as objectID Uniquely identifies an object in the target VM that is known to be a module object. The size of objectID is returned by the ViltualMachine(1) command IDSizes(7): Reply Data int /fieldIDSize/ fieldID size in bytes int /methodIDSize/ methodID size in bytes int /objectIDSize/ objectID size in bytes int /referenceTypeIDSize/ referenceTypeID size in bytes int /frameIDSize/ frameID size in bytes Please, let me know what you think. Thanks, Serguei On 8/25/16 04:56, Alexander Kulyakhtin wrote: > Hi Sergey, > > Most unfortunately, the test is failing on 32-bit machines only with https://bugs.openjdk.java.net/browse/JDK-8164490. > > It may well be a test issue, so I appreciate your looking at the test source. I was not able to locate any issue with the test and it runs fine on 64-bit machines. > Perhaps, it has to do with any difference in JDWP strings representation on 32/64 machines? > > Best regards, > Alexander > > ----- Original Message ----- > From: serguei.spitsyn at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net > Cc: christian.tornqvist at oracle.com > Sent: Wednesday, August 24, 2016 11:22:23 PM GMT +03:00 Iraq > Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" > > Hi Alexander, > > It is great that you developed a test coverage for this feature. > Just wanted to let you know that I'm reviewing your fix now. > Did you get any other reviews yet? > > Thanks, > Serguei > > > On 8/12/16 05:55, Alexander Kulyakhtin wrote: >> Hi, >> >> Could you, please, review the following test-only change (adding a new test): >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8148103 >> Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/ >> >> The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. >> >> It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. >> >> When started the debuggee reports its loaded modules to the test. >> The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. >> For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. >> Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. >> >> Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. >> The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. >> >> Best regards, >> Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Aug 25 19:28:36 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Aug 2016 12:28:36 -0700 Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" In-Reply-To: <57BF2DF2.4000002@oracle.com> References: <7ef0724a-8ea2-4f1e-bd74-6cc17887a029@default> <57BF2DF2.4000002@oracle.com> Message-ID: <57BF46E4.3060100@oracle.com> Alexander, The objectID size (and so, the moduleID size) must be always 8 bytes. I think, the following fragments have errors: JdwpCmd.java 80 protected void putRefId(long refId) { 81 if (Arch.is64()) { 82 data.putLong(refId); 83 } else { 84 data.putInt((int) refId); 85 } 86 } JdwpReply.java 70 protected long readRefId(DataInputStream ds) throws IOException { 71 if (Arch.is64()) { 72 return ds.readLong(); 73 } else { 74 return ds.readInt(); 75 } 76 } In both cases the ds.readLong() must be returned independently of the Arch.is64(). Thanks, Serguei On 8/25/16 10:42, serguei.spitsyn at oracle.com wrote: > Hi Alexander, > > The error code 42 is INVALID_MODULE: > *INVALID_MODULE* > > 42 > > Invalid module. > > > It means that the moduleID passed to the JDWP is not correct. > So that we have to check if the moduleID format is correct for 32-bit. > > > The moduleID type is specified as: > *moduleID* > > same as objectID > > Uniquely identifies an object in the target VM that is known to be a > module object. > > > > The size of objectID is returned by the ViltualMachine(1) command > IDSizes(7): > Reply Data > > > > > > > > int /fieldIDSize/ fieldID size in bytes > int /methodIDSize/ methodID size in bytes > int /objectIDSize/ objectID size in bytes > int /referenceTypeIDSize/ referenceTypeID size in bytes > int /frameIDSize/ frameID size in bytes > > > > Please, let me know what you think. > > Thanks, > Serguei > > > > On 8/25/16 04:56, Alexander Kulyakhtin wrote: >> Hi Sergey, >> >> Most unfortunately, the test is failing on 32-bit machines only withhttps://bugs.openjdk.java.net/browse/JDK-8164490. >> >> It may well be a test issue, so I appreciate your looking at the test source. I was not able to locate any issue with the test and it runs fine on 64-bit machines. >> Perhaps, it has to do with any difference in JDWP strings representation on 32/64 machines? >> >> Best regards, >> Alexander >> >> ----- Original Message ----- >> From:serguei.spitsyn at oracle.com >> To:alexander.kulyakhtin at oracle.com,serviceability-dev at openjdk.java.net >> Cc:christian.tornqvist at oracle.com >> Sent: Wednesday, August 24, 2016 11:22:23 PM GMT +03:00 Iraq >> Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" >> >> Hi Alexander, >> >> It is great that you developed a test coverage for this feature. >> Just wanted to let you know that I'm reviewing your fix now. >> Did you get any other reviews yet? >> >> Thanks, >> Serguei >> >> >> On 8/12/16 05:55, Alexander Kulyakhtin wrote: >>> Hi, >>> >>> Could you, please, review the following test-only change (adding a new test): >>> >>> CR:https://bugs.openjdk.java.net/browse/JDK-8148103 >>> Webrev:http://cr.openjdk.java.net/~akulyakh/8148103_02/ >>> >>> The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. >>> >>> It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. >>> >>> When started the debuggee reports its loaded modules to the test. >>> The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. >>> For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. >>> Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. >>> >>> Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. >>> The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. >>> >>> Best regards, >>> Alexander > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Aug 25 21:03:51 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Aug 2016 14:03:51 -0700 Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" In-Reply-To: References: Message-ID: <57BF5D37.8080504@oracle.com> Alexander, The fix is pretty good. Some comments besides the bug 8164490 we already discussed. test/serviceability/jdwp/AllModulesCommandTest.java 75 System.err.println("Could not launch the debuggee. Error: '" + line + "'"); A suggestion to replace "Error: " => Error at line: ". Otherwise, the line number will be confused with the error code. 81 // Etsablish JDWP socket connection A typo: Etsablish => Establish The verification in the assertClassLoader is pretty weak. It'd be nice to have more sophisticated verification. For instance, the following commands can be used for such verification: cmdset: ClassLoaderReference=14 , cmd: VisibleClasses=1 cmdset: ReferenceType=2, cmd: ClassLoader=2 cmdset: ReferenceType=2, cmd: Module=19 It is possible to iterate over all classes of the class loader to find at least one class with the given module and check if the class's class loader is the same as module's class loader. BTW, this would test the new jdwp command added for Jigsaw support: cmdset: ReferenceType=2, cmd: Module=19 But I leave it up to you as it looks unreasonably complicated. Maybe, you find a better approach. test/serviceability/jdwp/AllModulesCommandTestDebuggee.java 41 Set modNames = new HashSet<>(); 42 for (Module mod : Layer.boot().modules()) { 43 modNames.add(mod.getName()); 44 String info = String.format("module %s", mod.getName()); 45 write(info); 46 } The local modNames is not really used and can be removed (lines 41, 43). test/serviceability/jdwp/Arch.java It seems, this file/class is not really needed and can be removed. test/serviceability/jdwp/JdwpReply.java Nit: the empty lines 39 and 54 are not needed. Thanks, Serguei On 8/12/16 05:55, Alexander Kulyakhtin wrote: > Hi, > > Could you, please, review the following test-only change (adding a new test): > > CR: https://bugs.openjdk.java.net/browse/JDK-8148103 > Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/ > > The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. > > It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. > > When started the debuggee reports its loaded modules to the test. > The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. > For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. > Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. > > Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. > The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. > > Best regards, > Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Aug 25 22:31:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Aug 2016 08:31:51 +1000 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> Message-ID: On 25/08/2016 6:19 PM, Harsha Wardhana B wrote: > Hello All, > > Please find below the revised webrev below. > > http://cr.openjdk.java.net/~hb/8161448/webrev.01/ Functional changes seem okay. Exception management seems consistent. You have made numerous other incidental changes which not only make it harder to examine this incrementally, but in most cases are wrong: 36 "JMX interface to diagnostic framework notifications " 37 "is not supported by this VM"); The indentation is wrong after splitting the line. The strings should line up. 62 /* According to ISO C it is perfectly legal for malloc to return zero if 63 * called with a zero argument */ A multi-line comment should end with the */ on its own line. 70 dcmdArgInfoCls = (*env)->FindClass( 71 env, "com/sun/management/internal/DiagnosticCommandArgumentInfo"); This indent is wrong, the original was correct. 183 args = getDiagnosticCommandArgumentInfoArray( 184 env, (*env)->GetObjectArrayElement(env,commands,i), 185 dcmd_info_array[i].num_arguments); Indent is wrong, original was correct. 207 obj = JNU_NewObjectByName( 208 env, "com/sun/management/internal/DiagnosticCommandInfo", 209 "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;" 210 "Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;" 211 "ZLjava/util/List;)V", 212 jname, jdesc, jimpact, 213 dcmd_info_array[i].permission_class==NULL?NULL: 214 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_class), 215 dcmd_info_array[i].permission_name==NULL?NULL: 216 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_name), 217 dcmd_info_array[i].permission_action==NULL?NULL: 218 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_action), 219 dcmd_info_array[i].enabled, args); Again indent is wrong (yes those really long strings are a pain but that's life) and the original was more correct ie NewObjectByName(env on first line, then other args line up underneath. However if you are going to fix layout in this bit of code then please add spaces around the operators ie: cmd_info_array[i].permission_class == NULL ? NULL : (*env)->NewStringUTF(env,dcmd_info_array[i].permission_class), Thanks, David > Regards > > Harsha > > > On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >> Hi David, >> >> >> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>> Hi Harsha, >>> >>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>> Hello All, >>>> >>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>> >>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>> >>> Looks functionally correct, but I wouldn't complain if you wanted to >>> use a macro to reduce the duplication and verbosity. Even the: >>> >>> 109 if (obj == NULL) { >>> 110 free(dcmd_arg_info_array); >>> 111 return NULL; >>> >>> can be replaced by an exception-check as that is the only time >>> JNU_NewObjectByName can return NULL. >> I am not sure if using macro here is good practice since it will be >> specific to the function and it will encapsulate the local variable >> within it. Also, it will reduce code readability. Hence I would like >> to leave it as is. >>> >>> I also noticed an issue that was flagged in some other JNI code lately: >>> >>> 213 if (obj == NULL) { >>> 214 free(dcmd_info_array); >>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>> 216 return NULL; >>> >>> If obj == NULL then there is already a pending exception and we >>> should not be throwing OOME. >>> >> Sure. This needs to be fixed. >>> Thanks, >>> David >>> >>>> Regards >>>> >>>> Harsha >>>> >> Harsha > From dmitry.samersoff at oracle.com Fri Aug 26 08:35:30 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 26 Aug 2016 11:35:30 +0300 Subject: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools In-Reply-To: <9fc8324f-4f49-bb09-4f97-ba478d5368be@oracle.com> References: <12dc677b-e33c-0345-4680-e97cc1604cbe@oracle.com> <57BC4B41.60305@oracle.com> <938232c7-c206-f0db-7446-78960537ad2b@oracle.com> <1f8101d1fd71$feb399d0$fc1acd70$@oracle.com> <9fc8324f-4f49-bb09-4f97-ba478d5368be@oracle.com> Message-ID: <1056deb7-ab07-78c6-c6c6-f8c7c0a93213@oracle.com> Christian, Ioi, Are you OK with this changes? http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.03/ -Dmitry On 2016-08-24 14:42, Dmitry Samersoff wrote: > Christian, > > Thank you for the review. > > Please see updated webrev: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.03/ > > I still have no ideas why this @build construction works with > @run driver but doesn't work with @run main/othervm. > > Is there a chance to have all such knowledge documented? > >> You don't need to explicitly build JpsHelper, > > I would prefer to leave it as is - it's harmless but highlights > TestJpsJar dependency. > >> would it make sense to change this to use the /test/lib ones and > > I'd tried it[1] and it doesn't work. jtreg claims that package > jdk.test.lib doesn't exist.[2] > > > 1. > http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.02.bad/ > > 2. > http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.02.bad/TestJpsClass.jtr > > -Dmitry > > On 2016-08-23 22:10, Christian Tornqvist wrote: >> Hi Dmitry, >> >> You don't need to explicitly build JpsHelper, >> I also noticed that >> you're using ProcessTools and OutputAnalyzer from /lib/testlibrary , >> would it make sense to change this to use the /test/lib ones and >> simply have: >> >> @library /test/lib >> >> ? >> >> Thanks, Christian -----Original Message----- From: >> hotspot-runtime-dev >> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of >> Dmitry Samersoff Sent: Tuesday, August 23, 2016 3:02 PM To: Ioi Lam >> ; serviceability-dev at openjdk.java.net; >> hotspot-runtime-dev Subject: >> Re: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java >> fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools >> >> Ioi, >> >> Thank you for review. >> >> Hmm. It looks like changes below solves the problem. >> >> - * @build jdk.testlibrary.* JpsHelper JpsBase + * @build JpsHelper >> JpsBase >> >> I'm running rbt job to verify it. >> >> -Dmitry >> >> On 2016-08-23 16:10, Ioi Lam wrote: >>> Hi Dmitry, >>> >>> Why are you adding /test/lib: >>> >>> - * @library /lib/testlibrary + * @library /lib/testlibrary >>> /test/lib >>> >>> The only class used by jdk/test/sun/tools/jps/*.java in /test/lib >>> is here: >>> >>> TestJpsSanity.java:import jdk.test.lib.apps.LingeredApp; >>> >>> But TestJpsSanity.java is not use by this test -- I ran the test >>> with your patch in a clean jtreg directory and the test passed, but >>> I don't see TestJpsSanity.class, or any jdk.test.lib.* class. >>> >>> So I don't think you need to add /test/lib. >>> >>> - Ioi >>> >>> On 8/23/16 5:34 AM, Dmitry Samersoff wrote: >>>> On 2016-08-17 10:51, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review the changes: >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ >>>>> >>>>> -Dmitry >>>>> >>>> >>> >> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >> Russia * I would love to change the world, but they won't give me the >> sources. >> > > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Fri Aug 26 11:00:15 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 26 Aug 2016 14:00:15 +0300 Subject: RFR(S): 8163994: Nightly test crashed in jvmtiAllocate Message-ID: Everybody, Please review the fix. http://cr.openjdk.java.net/~dsamersoff/JDK-8163994/webrev.02/ *Problem* Under some circumstances, when JVMTI_ERROR_WRONG_PHASE(112) is received, jvmtiAllocate could be called after call to cbEarlyVMDeath. cbEarlyVMDeath set gdata->jvmti to NULL, so jvmtiAllocate crashes. The problem appears only once in nightly testing and I was not able to reproduce it locally. *Solution* Guard added to jvmtiAllocate to get meaningful error message instead of crash. These fix doesn't fix root cause - JVMTI_ERROR_WRONG_PHASE problem is going to be addressed under JDK-8134103. -Dmitry -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From ioi.lam at oracle.com Fri Aug 26 13:16:56 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 26 Aug 2016 06:16:56 -0700 Subject: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools In-Reply-To: <1056deb7-ab07-78c6-c6c6-f8c7c0a93213@oracle.com> References: <12dc677b-e33c-0345-4680-e97cc1604cbe@oracle.com> <57BC4B41.60305@oracle.com> <938232c7-c206-f0db-7446-78960537ad2b@oracle.com> <1f8101d1fd71$feb399d0$fc1acd70$@oracle.com> <9fc8324f-4f49-bb09-4f97-ba478d5368be@oracle.com> <1056deb7-ab07-78c6-c6c6-f8c7c0a93213@oracle.com> Message-ID: <57C04148.5080502@oracle.com> Looks good. Thanks Dmitry! - Ioi On 8/26/16 1:35 AM, Dmitry Samersoff wrote: > Christian, Ioi, > > Are you OK with this changes? > > http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.03/ > > -Dmitry > > > On 2016-08-24 14:42, Dmitry Samersoff wrote: >> Christian, >> >> Thank you for the review. >> >> Please see updated webrev: >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.03/ >> >> I still have no ideas why this @build construction works with >> @run driver but doesn't work with @run main/othervm. >> >> Is there a chance to have all such knowledge documented? >> >>> You don't need to explicitly build JpsHelper, >> I would prefer to leave it as is - it's harmless but highlights >> TestJpsJar dependency. >> >>> would it make sense to change this to use the /test/lib ones and >> I'd tried it[1] and it doesn't work. jtreg claims that package >> jdk.test.lib doesn't exist.[2] >> >> >> 1. >> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.02.bad/ >> >> 2. >> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.02.bad/TestJpsClass.jtr >> >> -Dmitry >> >> On 2016-08-23 22:10, Christian Tornqvist wrote: >>> Hi Dmitry, >>> >>> You don't need to explicitly build JpsHelper, >>> I also noticed that >>> you're using ProcessTools and OutputAnalyzer from /lib/testlibrary , >>> would it make sense to change this to use the /test/lib ones and >>> simply have: >>> >>> @library /test/lib >>> >>> ? >>> >>> Thanks, Christian -----Original Message----- From: >>> hotspot-runtime-dev >>> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of >>> Dmitry Samersoff Sent: Tuesday, August 23, 2016 3:02 PM To: Ioi Lam >>> ; serviceability-dev at openjdk.java.net; >>> hotspot-runtime-dev Subject: >>> Re: PING! Re: RFR(XS): JDK-8160923: sun/tools/jps/TestJpsJar.java >>> fails due to ClassNotFoundException: jdk.testlibrary.ProcessTools >>> >>> Ioi, >>> >>> Thank you for review. >>> >>> Hmm. It looks like changes below solves the problem. >>> >>> - * @build jdk.testlibrary.* JpsHelper JpsBase + * @build JpsHelper >>> JpsBase >>> >>> I'm running rbt job to verify it. >>> >>> -Dmitry >>> >>> On 2016-08-23 16:10, Ioi Lam wrote: >>>> Hi Dmitry, >>>> >>>> Why are you adding /test/lib: >>>> >>>> - * @library /lib/testlibrary + * @library /lib/testlibrary >>>> /test/lib >>>> >>>> The only class used by jdk/test/sun/tools/jps/*.java in /test/lib >>>> is here: >>>> >>>> TestJpsSanity.java:import jdk.test.lib.apps.LingeredApp; >>>> >>>> But TestJpsSanity.java is not use by this test -- I ran the test >>>> with your patch in a clean jtreg directory and the test passed, but >>>> I don't see TestJpsSanity.class, or any jdk.test.lib.* class. >>>> >>>> So I don't think you need to add /test/lib. >>>> >>>> - Ioi >>>> >>>> On 8/23/16 5:34 AM, Dmitry Samersoff wrote: >>>>> On 2016-08-17 10:51, Dmitry Samersoff wrote: >>>>>> Everybody, >>>>>> >>>>>> Please review the changes: >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8160923/webrev.01/ >>>>>> >>>>>> -Dmitry >>>>>> >>> >>> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, >>> Russia * I would love to change the world, but they won't give me the >>> sources. >>> >> > From chris.plummer at oracle.com Fri Aug 26 21:35:34 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 26 Aug 2016 14:35:34 -0700 Subject: RFR(S): 8163994: Nightly test crashed in jvmtiAllocate In-Reply-To: References: Message-ID: Hi Dmitry, Although the fix is addressing the specific issue described in the bug, what about the general issue of referencing gdata after a call to cbEarlyVMDeath(). Do more references to gdata need to be protected? Also, is there the possibility of a multi-threading race condition here? Could gdata be cleared by another thread after it is checked? thanks, Chris On 8/26/16 4:00 AM, Dmitry Samersoff wrote: > Everybody, > > Please review the fix. > > http://cr.openjdk.java.net/~dsamersoff/JDK-8163994/webrev.02/ > > *Problem* > > Under some circumstances, when JVMTI_ERROR_WRONG_PHASE(112) is received, > jvmtiAllocate could be called after call to cbEarlyVMDeath. > > cbEarlyVMDeath set gdata->jvmti to NULL, so jvmtiAllocate crashes. > > The problem appears only once in nightly testing and I was not able to > reproduce it locally. > > *Solution* > > Guard added to jvmtiAllocate to get meaningful error message instead of > crash. > > These fix doesn't fix root cause - JVMTI_ERROR_WRONG_PHASE problem is > going to be addressed under JDK-8134103. > > -Dmitry > From mandy.chung at oracle.com Sat Aug 27 01:44:15 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Aug 2016 18:44:15 -0700 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: References: Message-ID: <402A09DB-4DC0-4D5D-B1E4-197D3179C7E2@oracle.com> > On Aug 23, 2016, at 11:10 PM, Jini Susan George wrote: > > Hi all, > > Could you please review the fix for: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 > Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ > > I took the liberty to do some module related cleanups in the test also while fixing this issue. > The @module cleanup looks fine to workaround https://bugs.openjdk.java.net/browse/CODETOOLS-7901761 What causes the test to throw NPE? It's unclear to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Sun Aug 28 12:47:16 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 28 Aug 2016 21:47:16 +0900 Subject: RFR: JDK-8164913: JVMTI.agent_load dcmd should show useful error message Message-ID: Hi all, If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we will get "Command executed successfully". However, it implies error in JVMTIAgentLoadDCmd. This message is from JCmd.java when jcmd does not receive output from target VM. So we should send error message from JVMTIAgentLoadDCmd. I uploaded a webrev for it. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8164913/webrev.00/ I cannot access JPRT. So I need a sponsor. Thanks, Yasumasa From david.holmes at oracle.com Mon Aug 29 01:14:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Aug 2016 11:14:19 +1000 Subject: RFR(S): 8163994: Nightly test crashed in jvmtiAllocate In-Reply-To: References: Message-ID: <290c1d74-97ee-95d0-1b20-01d5aebdab48@oracle.com> On 27/08/2016 7:35 AM, Chris Plummer wrote: > Hi Dmitry, > > Although the fix is addressing the specific issue described in the bug, > what about the general issue of referencing gdata after a call to > cbEarlyVMDeath(). Do more references to gdata need to be protected? > > Also, is there the possibility of a multi-threading race condition here? > Could gdata be cleared by another thread after it is checked? Certainly. This really isn't fixing anything just adding a bailout check before the crashing code. We can still crash and not be any the wiser as to why. Not sure I really see the point of doing this instead of closing this as a dup of JDK-8134103 and fixing things properly. David > thanks, > > Chris > > On 8/26/16 4:00 AM, Dmitry Samersoff wrote: >> Everybody, >> >> Please review the fix. >> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8163994/webrev.02/ >> >> *Problem* >> >> Under some circumstances, when JVMTI_ERROR_WRONG_PHASE(112) is received, >> jvmtiAllocate could be called after call to cbEarlyVMDeath. >> >> cbEarlyVMDeath set gdata->jvmti to NULL, so jvmtiAllocate crashes. >> >> The problem appears only once in nightly testing and I was not able to >> reproduce it locally. >> >> *Solution* >> >> Guard added to jvmtiAllocate to get meaningful error message instead of >> crash. >> >> These fix doesn't fix root cause - JVMTI_ERROR_WRONG_PHASE problem is >> going to be addressed under JDK-8134103. >> >> -Dmitry >> > From david.holmes at oracle.com Mon Aug 29 03:59:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Aug 2016 13:59:21 +1000 Subject: RFR: JDK-8164913: JVMTI.agent_load dcmd should show useful error message In-Reply-To: References: Message-ID: Hi Yasumasa, On 28/08/2016 10:47 PM, Yasumasa Suenaga wrote: > Hi all, > > If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we > will get > "Command executed successfully". However, it implies error in > JVMTIAgentLoadDCmd. > > This message is from JCmd.java when jcmd does not receive output from > target VM. > So we should send error message from JVMTIAgentLoadDCmd. > > I uploaded a webrev for it. Could you review it? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8164913/webrev.00/ This seems reasonable. src/share/vm/prims/jvmtiExport.cpp This comment no longer matches the code and should be deleted: 2412 // Agent_OnAttach executed so completion status is JNI_OK 2413 st->print_cr("return code: %d", result); Thanks, David > I cannot access JPRT. > So I need a sponsor. > > > Thanks, > > Yasumasa > From david.holmes at oracle.com Mon Aug 29 04:06:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Aug 2016 14:06:12 +1000 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: References: Message-ID: On 24/08/2016 4:10 PM, Jini Susan George wrote: > Hi all, > > Could you please review the fix for: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ > > I took the liberty to do some module related cleanups in the test also > while fixing this issue. So which change fixes the actual bug? As far as I can see if the output of the command is not as expected we return a null and that then leads to the NPE when calling String.contains. Seems to me that the test should be more resilient here and give a meaningful error message if the expected output is not seen. Thanks, David > > > Thank you, > > - Jini Susan George > > > From jini.george at oracle.com Mon Aug 29 04:14:13 2016 From: jini.george at oracle.com (Jini Susan George) Date: Sun, 28 Aug 2016 21:14:13 -0700 (PDT) Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: <402A09DB-4DC0-4D5D-B1E4-197D3179C7E2@oracle.com> References: <402A09DB-4DC0-4D5D-B1E4-197D3179C7E2@oracle.com> Message-ID: <6ff14da3-fb8c-4127-8244-aed1609ddf31@default> Thank you, Mandy. The test was throwing an NPE due to the option ?-XX:+UnlockDiagnosticVMOptions? not being used for TestInstanceKlassSizeForInterface.java in the release build. jcmd?s GC.class_stats requires this, and hence, parsing of the jcmd output was resulting in an NPE. ? Regards, Jini. ? From: Mandy Chung Sent: Saturday, August 27, 2016 7:14 AM To: Jini Susan George Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE ? ? On Aug 23, 2016, at 11:10 PM, Jini Susan George wrote: Hi all, ? Could you please review the fix for: ? Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ ? I took the liberty to do some module related cleanups in the test also while fixing this issue. ? ? The @module cleanup looks fine to workaround?https://bugs.openjdk.java.net/browse/CODETOOLS-7901761 ? What causes the test to throw NPE? ?It's unclear to me. ? Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Aug 29 04:29:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Aug 2016 14:29:40 +1000 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: <6ff14da3-fb8c-4127-8244-aed1609ddf31@default> References: <402A09DB-4DC0-4D5D-B1E4-197D3179C7E2@oracle.com> <6ff14da3-fb8c-4127-8244-aed1609ddf31@default> Message-ID: <9ad5ac72-e7fa-2559-fd9c-ac05e272e452@oracle.com> On 29/08/2016 2:14 PM, Jini Susan George wrote: > Thank you, Mandy. The test was throwing an NPE due to the option > ?-XX:+UnlockDiagnosticVMOptions? not being used for > TestInstanceKlassSizeForInterface.java in the release build. jcmd?s > GC.class_stats requires this, and hence, parsing of the jcmd output was > resulting in an NPE. -XX:+UnlockDiagnosticVMOptions is for controlling access to a diagnostic VM flag. I don't see any such flags being used. -XX:+UnlockDiagnosticVMOptions should not be controlling internal behaviour independent of a VM flag! While I see the check in ClassStatsDCmd::execute I see absolutely no reason that it should be constrained this way! This behaviour does not make sense to me. David > > > Regards, > > Jini. > > > > *From:*Mandy Chung > *Sent:* Saturday, August 27, 2016 7:14 AM > *To:* Jini Susan George > *Cc:* serviceability-dev at openjdk.java.net > *Subject:* Re: RFR:(S): 8164562: > serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > > > > > > On Aug 23, 2016, at 11:10 PM, Jini Susan George > wrote: > > Hi all, > > > > Could you please review the fix for: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ > > > > I took the liberty to do some module related cleanups in the test > also while fixing this issue. > > > > > > The @module cleanup looks fine to > workaround https://bugs.openjdk.java.net/browse/CODETOOLS-7901761 > > > > What causes the test to throw NPE? It's unclear to me. > > > > Mandy > From david.holmes at oracle.com Mon Aug 29 04:34:42 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Aug 2016 14:34:42 +1000 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: <9ad5ac72-e7fa-2559-fd9c-ac05e272e452@oracle.com> References: <402A09DB-4DC0-4D5D-B1E4-197D3179C7E2@oracle.com> <6ff14da3-fb8c-4127-8244-aed1609ddf31@default> <9ad5ac72-e7fa-2559-fd9c-ac05e272e452@oracle.com> Message-ID: On 29/08/2016 2:29 PM, David Holmes wrote: > On 29/08/2016 2:14 PM, Jini Susan George wrote: >> Thank you, Mandy. The test was throwing an NPE due to the option >> ?-XX:+UnlockDiagnosticVMOptions? not being used for >> TestInstanceKlassSizeForInterface.java in the release build. jcmd?s >> GC.class_stats requires this, and hence, parsing of the jcmd output was >> resulting in an NPE. > > -XX:+UnlockDiagnosticVMOptions is for controlling access to a diagnostic > VM flag. I don't see any such flags being used. > -XX:+UnlockDiagnosticVMOptions should not be controlling internal > behaviour independent of a VM flag! > > While I see the check in ClassStatsDCmd::execute I see absolutely no > reason that it should be constrained this way! > > This behaviour does not make sense to me. I see it was added by: https://bugs.openjdk.java.net/browse/JDK-6479360 but I still see no reason for it. Perhaps Ioi can enlighten us? David > David > >> >> >> Regards, >> >> Jini. >> >> >> >> *From:*Mandy Chung >> *Sent:* Saturday, August 27, 2016 7:14 AM >> *To:* Jini Susan George >> *Cc:* serviceability-dev at openjdk.java.net >> *Subject:* Re: RFR:(S): 8164562: >> serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE >> >> >> >> >> >> On Aug 23, 2016, at 11:10 PM, Jini Susan George > > wrote: >> >> Hi all, >> >> >> >> Could you please review the fix for: >> >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 >> >> Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ >> >> >> >> I took the liberty to do some module related cleanups in the test >> also while fixing this issue. >> >> >> >> >> >> The @module cleanup looks fine to >> workaround https://bugs.openjdk.java.net/browse/CODETOOLS-7901761 >> >> >> >> What causes the test to throw NPE? It's unclear to me. >> >> >> >> Mandy >> From harsha.wardhana.b at oracle.com Mon Aug 29 10:12:36 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 29 Aug 2016 15:42:36 +0530 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> Message-ID: <711214c4-a5b5-f4f3-51b2-1a235e053809@oracle.com> Hi David, The reason I fixed the indent was to maintain 80 character line width. I am not too familiar with coding conventions being followed w.r.t indentations. Could you point me to coding conventions for native code if we are following anything of that sort Thanks Harsha On Friday 26 August 2016 04:01 AM, David Holmes wrote: > On 25/08/2016 6:19 PM, Harsha Wardhana B wrote: >> Hello All, >> >> Please find below the revised webrev below. >> >> http://cr.openjdk.java.net/~hb/8161448/webrev.01/ > > Functional changes seem okay. Exception management seems consistent. > > You have made numerous other incidental changes which not only make it > harder to examine this incrementally, but in most cases are wrong: > > 36 "JMX interface to diagnostic framework > notifications " > 37 "is not supported by this VM"); > > The indentation is wrong after splitting the line. The strings should > line up. > > 62 /* According to ISO C it is perfectly legal for malloc to > return zero if > 63 * called with a zero argument */ > > A multi-line comment should end with the */ on its own line. > > 70 dcmdArgInfoCls = (*env)->FindClass( > 71 env, > "com/sun/management/internal/DiagnosticCommandArgumentInfo"); > > This indent is wrong, the original was correct. > > 183 args = getDiagnosticCommandArgumentInfoArray( > 184 env, (*env)->GetObjectArrayElement(env,commands,i), > 185 dcmd_info_array[i].num_arguments); > > Indent is wrong, original was correct. > > 207 obj = JNU_NewObjectByName( > 208 env, > "com/sun/management/internal/DiagnosticCommandInfo", > 209 "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;" > 210 "Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;" > 211 "ZLjava/util/List;)V", > 212 jname, jdesc, jimpact, > 213 dcmd_info_array[i].permission_class==NULL?NULL: > 214 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_class), > 215 dcmd_info_array[i].permission_name==NULL?NULL: > 216 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_name), > 217 dcmd_info_array[i].permission_action==NULL?NULL: > 218 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_action), > 219 dcmd_info_array[i].enabled, args); > > Again indent is wrong (yes those really long strings are a pain but > that's life) and the original was more correct ie NewObjectByName(env > on first line, then other args line up underneath. > > However if you are going to fix layout in this bit of code then please > add spaces around the operators ie: > > cmd_info_array[i].permission_class == NULL ? NULL : > > (*env)->NewStringUTF(env,dcmd_info_array[i].permission_class), > > Thanks, > David > >> Regards >> >> Harsha >> >> >> On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >>> Hi David, >>> >>> >>> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>>> Hi Harsha, >>>> >>>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>>> Hello All, >>>>> >>>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>>> >>>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>>> >>>> Looks functionally correct, but I wouldn't complain if you wanted to >>>> use a macro to reduce the duplication and verbosity. Even the: >>>> >>>> 109 if (obj == NULL) { >>>> 110 free(dcmd_arg_info_array); >>>> 111 return NULL; >>>> >>>> can be replaced by an exception-check as that is the only time >>>> JNU_NewObjectByName can return NULL. >>> I am not sure if using macro here is good practice since it will be >>> specific to the function and it will encapsulate the local variable >>> within it. Also, it will reduce code readability. Hence I would like >>> to leave it as is. >>>> >>>> I also noticed an issue that was flagged in some other JNI code >>>> lately: >>>> >>>> 213 if (obj == NULL) { >>>> 214 free(dcmd_info_array); >>>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>>> 216 return NULL; >>>> >>>> If obj == NULL then there is already a pending exception and we >>>> should not be throwing OOME. >>>> >>> Sure. This needs to be fixed. >>>> Thanks, >>>> David >>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>> Harsha >> From harsha.wardhana.b at oracle.com Mon Aug 29 10:35:36 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 29 Aug 2016 16:05:36 +0530 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> Message-ID: <69334caa-58ec-c768-455a-5f9c750fc804@oracle.com> Hello All, Could I get review from one more Reviewer? Thanks Harsha On Wednesday 24 August 2016 10:07 AM, harsha.wardhana.b at oracle.com wrote: > > Thanks David. > > Harsha > > > > > On Wed, Aug 24, 2016 at 6:55 AM +0530, "David Holmes" > > wrote: > > On 23/08/2016 10:17 PM, Harsha Wardhana B wrote: > > Hi David, > > > > You approach to waiter object is a neat little abstraction and I will > > make it a point to use it in future fixes, if required. > > Note it only works for a single waiting thread. :) > > > revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ > > This looks good, thanks for your patience with this. > > Cheers, > David > > > On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: > >> Hi Harsha, > >> > >> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: > >>> Hello, > >>> > >>> Please review the below webrev incorporating David's comments. > >>> > >>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ > >> > >> Using a static isNotified field isn't exactly what I had in mind, I > >> was thinking of something more encapsulated - something I thought > >> already existed in other tests, but now I can't find it. Eg: > >> > >> /* synchronization helper for two-thread wait/notify interaction > >> */ > >> static class WaitObject { > >> boolean isNotified = false; > >> public void await() throws InterruptedException { > >> while (!isNotified) > >> wait(); > >> isNotified = false; > >> } > >> public void doNotify() { > >> isNotified = true; > >> notify(); > >> } > >> } > >> > >> then OBJC would be a WaitObject and you would do: > >> > >> synchronized(OBJC) { > >> log("WaitingThread about to wait on objC"); > >> try { > >> // Signal checker thread, about to wait on objC. > >> waiting = false; > >> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) > >> waiting = true; > >> OBJC.doWait(); > >> } catch (InterruptedException e) { > >> ... > >> > >> etc. > >> > >> Minor nits: > >> - why did you move the @library ? > > It was suggested by NetBeans Jtreg plugin to fix tag order. > >> - @Override, if used, should be applied consistently > > Have applied the annotation consistently. > >> - if you want to capitalize objA, objB, objC then ensure you also > >> update it in the comments and log statements (it really isn't > >> necessary to capitalize them, that is suggested for compile-time > >> constants and these are not - they are just static final variables). > > Done. > > > > Thanks > > Harsha > >> > >> > >> Thanks, > >> David > >> > >>> Regards > >>> > >>> Harsha > >>> > >>> > >>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: > >>>> Hi David, > >>>> > >>>> I will incorporate changes suggested by you. Let's wait for few more > >>>> review comments and then I will send consolidated webrev. > >>>> > >>>> Regards > >>>> Harsha > >>>> > >>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: > >>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: > >>>>>> Hi David, > >>>>>> > >>>>>> Agreed that we could fix WaitingThread the way you have said, but in > >>>>>> recent past, there aren't any issues reported w.r.t WaitingThread. > >>>>> > >>>>> Nor are there likely to be - that's what makes spurious wakeup bugs > >>>>> so difficult to detect! > >>>>> > >>>>>> This test has been fixed several times (3-4) for intermittent > >>>>>> failures > >>>>>> and hence I would not like to meddle with code that is not causing > >>>>>> any > >>>>>> problems even though there is scope for refactoring. > >>>>> > >>>>> It isn't refactoring it is fixing and we have fixed several tests in > >>>>> a similar way. > >>>>> > >>>>>> The issue reported was with LockThreadB and hence I have provided > >>>>>> possible fix for the same. > >>>>> > >>>>> That doesn't preclude fixing other issues with the test at the same > >>>>> time. > >>>>> > >>>>> David > >>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Harsha > >>>>>> > >>>>>> > >>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: > >>>>>>> Hi Harsha, > >>>>>>> > >>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> Please review and provide comments for fix for issue, > >>>>>>>> > >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 > >>>>>>>> > >>>>>>>> having webrev located at > >>>>>>>> > >>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ > >>>>>>> > >>>>>>> These changes look quite good (though I have to admit I struggle to > >>>>>>> read the lambda and stream code :) ). > >>>>>>> > >>>>>>> Note that like many of these kinds of tests there is an issue with > >>>>>>> WaitingThread because it does not wait in a loop and so is > >>>>>>> susceptible > >>>>>>> to spurious wakeups. The way to fix that is to add a "notified" > >>>>>>> variable and then do: > >>>>>>> > >>>>>>> while (!notified) > >>>>>>> wait(); > >>>>>>> > >>>>>>> and set notified before the notify(). > >>>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>>> > >>>>>>>> Fix details: > >>>>>>>> > >>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on > >>>>>>>> wrong > >>>>>>>> object. We now do a repeated check with timeout if any given > >>>>>>>> thread is > >>>>>>>> blocked on expected object. It is possible that LockThreadB might > >>>>>>>> still > >>>>>>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is > >>>>>>>> invoked. > >>>>>>>> > >>>>>>>> 2. The logs from lock free logger was never printed. It is not > >>>>>>>> being > >>>>>>>> printed. > >>>>>>>> > >>>>>>>> 3. Any time we see failure, thread stack is being logged. This > >>>>>>>> helps us > >>>>>>>> ascertain if failure is in test case or in the component. > >>>>>>>> > >>>>>>>> 4. Even though we had lock free logger, several > >>>>>>>> ex.printStackTrace() was > >>>>>>>> used which could be responsible for failure. It is removed. > >>>>>>>> > >>>>>>>> 5. There were several places where tests continue to ran even after > >>>>>>>> failure (testFailed flag). That is fixed. > >>>>>>>> > >>>>>>>> 6. Couple of other minor refactoring. > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> > >>>>>>>> Harsha > >>>>>>>> > >>>>>> > >>>> > >>> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amit.sapre at oracle.com Mon Aug 29 05:55:13 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Sun, 28 Aug 2016 22:55:13 -0700 (PDT) Subject: RFR : JDK-8164609 : javax/management/remote/mandatory/notif/DeadListenerTest.java fails with AssertionError Message-ID: Hello, Please review a small test only change. Bug id : https://bugs.openjdk.java.net/browse/JDK-8164609 Webrev : http://cr.openjdk.java.net/~sballal/sponsorship/8164609/webrev.00/ PS : Based on triaging , it looked like a timing issue in test case, so the proposed changes are done only to increase the test timeout. If issue is still observed, will re-open the bug. Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Aug 29 06:27:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Aug 2016 16:27:14 +1000 Subject: RFR : JDK-8164609 : javax/management/remote/mandatory/notif/DeadListenerTest.java fails with AssertionError In-Reply-To: References: Message-ID: Hi Amit, On 29/08/2016 3:55 PM, Amit Sapre wrote: > Hello, > > Please review a small test only change. > > Bug id : https://bugs.openjdk.java.net/browse/JDK-8164609 > > Webrev : http://cr.openjdk.java.net/~sballal/sponsorship/8164609/webrev.00/ ! * Copyright (c) 2010, 2015, 2016, Oracle and/or its affiliates. All rights reserved. Copyright format is wrong - we only use first and last year, so just update the existing 2015 to be 2016. ! * @run main/othervm/timeout=120 -XX:+UsePerfData DeadListenerTest I think that is already the default timeout. Only set an explicit timeout if you need it to be longer - which I don't think you do here. Getting rid of the internal timeout mechanism is good. > PS : Based on triaging , it looked like a timing issue in test case, so > the proposed changes are done only to increase the test timeout. If > issue is still observed, will re-open the bug. Once a bug has had a changeset associated with it, it is considered Fixed and must not be reopened. Any subsequent test failures will require a new bug to be filed. Thanks, David > > > Thanks, > > Amit > From yasuenag at gmail.com Mon Aug 29 06:42:24 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 29 Aug 2016 15:42:24 +0900 Subject: RFR: JDK-8164913: JVMTI.agent_load dcmd should show useful error message In-Reply-To: References: Message-ID: <7958f997-7d44-29a7-5834-1b087c7452d4@gmail.com> > This comment no longer matches the code and should be deleted: > > 2412 // Agent_OnAttach executed so completion status is JNI_OK > 2413 st->print_cr("return code: %d", result); Thanks David! I removed it in new webrev. http://cr.openjdk.java.net/~ysuenaga/JDK-8164913/webrev.01/ Yasumasa On 2016/08/29 12:59, David Holmes wrote: > Hi Yasumasa, > > On 28/08/2016 10:47 PM, Yasumasa Suenaga wrote: >> Hi all, >> >> If we try to attach invalid JVMTI agent via JVMTI.agent_load dcmd, we >> will get >> "Command executed successfully". However, it implies error in >> JVMTIAgentLoadDCmd. >> >> This message is from JCmd.java when jcmd does not receive output from >> target VM. >> So we should send error message from JVMTIAgentLoadDCmd. >> >> I uploaded a webrev for it. Could you review it? >> >> http://cr.openjdk.java.net/~ysuenaga/JDK-8164913/webrev.00/ > > This seems reasonable. > > src/share/vm/prims/jvmtiExport.cpp > > This comment no longer matches the code and should be deleted: > > 2412 // Agent_OnAttach executed so completion status is JNI_OK > 2413 st->print_cr("return code: %d", result); > > Thanks, > David > >> I cannot access JPRT. >> So I need a sponsor. >> >> >> Thanks, >> >> Yasumasa >> From chris.plummer at oracle.com Mon Aug 29 06:43:30 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 28 Aug 2016 23:43:30 -0700 Subject: RFR(S): 8163994: Nightly test crashed in jvmtiAllocate In-Reply-To: <290c1d74-97ee-95d0-1b20-01d5aebdab48@oracle.com> References: <290c1d74-97ee-95d0-1b20-01d5aebdab48@oracle.com> Message-ID: On 8/28/16 6:14 PM, David Holmes wrote: > On 27/08/2016 7:35 AM, Chris Plummer wrote: >> Hi Dmitry, >> >> Although the fix is addressing the specific issue described in the bug, >> what about the general issue of referencing gdata after a call to >> cbEarlyVMDeath(). Do more references to gdata need to be protected? >> >> Also, is there the possibility of a multi-threading race condition here? >> Could gdata be cleared by another thread after it is checked? > > Certainly. This really isn't fixing anything just adding a bailout > check before the crashing code. We can still crash and not be any the > wiser as to why. > > Not sure I really see the point of doing this instead of closing this > as a dup of JDK-8134103 and fixing things properly. It it correct to say that Dmitry is fixing a bug exposed by JDK-8134103, or that he is temporarily working around something that is not a true bug, but is indirectly caused by JDK-8134103. I'm not sure, but the answer will dictate the correct course of action here. Chris > > David > >> thanks, >> >> Chris >> >> On 8/26/16 4:00 AM, Dmitry Samersoff wrote: >>> Everybody, >>> >>> Please review the fix. >>> >>> http://cr.openjdk.java.net/~dsamersoff/JDK-8163994/webrev.02/ >>> >>> *Problem* >>> >>> Under some circumstances, when JVMTI_ERROR_WRONG_PHASE(112) is >>> received, >>> jvmtiAllocate could be called after call to cbEarlyVMDeath. >>> >>> cbEarlyVMDeath set gdata->jvmti to NULL, so jvmtiAllocate crashes. >>> >>> The problem appears only once in nightly testing and I was not able to >>> reproduce it locally. >>> >>> *Solution* >>> >>> Guard added to jvmtiAllocate to get meaningful error message instead of >>> crash. >>> >>> These fix doesn't fix root cause - JVMTI_ERROR_WRONG_PHASE problem is >>> going to be addressed under JDK-8134103. >>> >>> -Dmitry >>> >> From david.holmes at oracle.com Mon Aug 29 06:56:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Aug 2016 16:56:01 +1000 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: <711214c4-a5b5-f4f3-51b2-1a235e053809@oracle.com> References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> <711214c4-a5b5-f4f3-51b2-1a235e053809@oracle.com> Message-ID: <681ee2b7-5175-b4a3-da67-43bc52abd12a@oracle.com> Hi Harsha, On 29/08/2016 8:12 PM, Harsha Wardhana B wrote: > Hi David, > > The reason I fixed the indent was to maintain 80 character line width. I > am not too familiar with coding conventions being followed w.r.t > indentations. Could you point me to coding conventions for native code > if we are following anything of that sort No hard and fast rules I'm afraid. The proposed Java style guide can also apply to native code: http://cr.openjdk.java.net/~alundblad/styleguide/index-v6.html and we have the hotspot coding guidelines: https://wiki.openjdk.java.net/display/HotSpot/StyleGuide A line length of 80 is only a guide (and many would says it is a guide from the 1970's!). There is also the general "rule" that unless something is terribly broken then consistency with the existing style is important - we don't want to have a dozen different styles at play in one file/class/method. The things you changed did not really need to be changed, but if you insist on changing them then I would strongly argue for a different style with regard to the indent ie instead of "JMX interface to diagnostic framework notifications " "is not supported by this VM"); it should be "JMX interface to diagnostic framework notifications " "is not supported by this VM"); And: 70 dcmdArgInfoCls = (*env)->FindClass( 71 env, "com/sun/management/internal/DiagnosticCommandArgumentInfo"); should be: 70 dcmdArgInfoCls = (*env)->FindClass(env, 71 "com/sun/management/internal/DiagnosticCommandArgumentInfo"); or if that is too jarring due to the length of line 71 then it could be: 70 dcmdArgInfoCls = 71 (*env)->FindClass(env, 72 "com/sun/management/internal/DiagnosticCommandArgumentInfo"); But unless something is really, really bad I would resist the urge to do these kinds of "clean ups" as they just obscure the real changes and make the review harder (and longer). Thanks, David > Thanks > Harsha > > On Friday 26 August 2016 04:01 AM, David Holmes wrote: >> On 25/08/2016 6:19 PM, Harsha Wardhana B wrote: >>> Hello All, >>> >>> Please find below the revised webrev below. >>> >>> http://cr.openjdk.java.net/~hb/8161448/webrev.01/ >> >> Functional changes seem okay. Exception management seems consistent. >> >> You have made numerous other incidental changes which not only make it >> harder to examine this incrementally, but in most cases are wrong: >> >> 36 "JMX interface to diagnostic framework >> notifications " >> 37 "is not supported by this VM"); >> >> The indentation is wrong after splitting the line. The strings should >> line up. >> >> 62 /* According to ISO C it is perfectly legal for malloc to >> return zero if >> 63 * called with a zero argument */ >> >> A multi-line comment should end with the */ on its own line. >> >> 70 dcmdArgInfoCls = (*env)->FindClass( >> 71 env, >> "com/sun/management/internal/DiagnosticCommandArgumentInfo"); >> >> This indent is wrong, the original was correct. >> >> 183 args = getDiagnosticCommandArgumentInfoArray( >> 184 env, (*env)->GetObjectArrayElement(env,commands,i), >> 185 dcmd_info_array[i].num_arguments); >> >> Indent is wrong, original was correct. >> >> 207 obj = JNU_NewObjectByName( >> 208 env, >> "com/sun/management/internal/DiagnosticCommandInfo", >> 209 "(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;" >> 210 "Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;" >> 211 "ZLjava/util/List;)V", >> 212 jname, jdesc, jimpact, >> 213 dcmd_info_array[i].permission_class==NULL?NULL: >> 214 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_class), >> 215 dcmd_info_array[i].permission_name==NULL?NULL: >> 216 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_name), >> 217 dcmd_info_array[i].permission_action==NULL?NULL: >> 218 (*env)->NewStringUTF(env,dcmd_info_array[i].permission_action), >> 219 dcmd_info_array[i].enabled, args); >> >> Again indent is wrong (yes those really long strings are a pain but >> that's life) and the original was more correct ie NewObjectByName(env >> on first line, then other args line up underneath. >> >> However if you are going to fix layout in this bit of code then please >> add spaces around the operators ie: >> >> cmd_info_array[i].permission_class == NULL ? NULL : >> >> (*env)->NewStringUTF(env,dcmd_info_array[i].permission_class), >> >> Thanks, >> David >> >>> Regards >>> >>> Harsha >>> >>> >>> On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >>>> Hi David, >>>> >>>> >>>> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>>>> Hi Harsha, >>>>> >>>>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>>>> Hello All, >>>>>> >>>>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>>>> >>>>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>>>> >>>>> Looks functionally correct, but I wouldn't complain if you wanted to >>>>> use a macro to reduce the duplication and verbosity. Even the: >>>>> >>>>> 109 if (obj == NULL) { >>>>> 110 free(dcmd_arg_info_array); >>>>> 111 return NULL; >>>>> >>>>> can be replaced by an exception-check as that is the only time >>>>> JNU_NewObjectByName can return NULL. >>>> I am not sure if using macro here is good practice since it will be >>>> specific to the function and it will encapsulate the local variable >>>> within it. Also, it will reduce code readability. Hence I would like >>>> to leave it as is. >>>>> >>>>> I also noticed an issue that was flagged in some other JNI code >>>>> lately: >>>>> >>>>> 213 if (obj == NULL) { >>>>> 214 free(dcmd_info_array); >>>>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>>>> 216 return NULL; >>>>> >>>>> If obj == NULL then there is already a pending exception and we >>>>> should not be throwing OOME. >>>>> >>>> Sure. This needs to be fixed. >>>>> Thanks, >>>>> David >>>>> >>>>>> Regards >>>>>> >>>>>> Harsha >>>>>> >>>> Harsha >>> > From jini.george at oracle.com Mon Aug 29 07:51:10 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 29 Aug 2016 00:51:10 -0700 (PDT) Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: References: Message-ID: Hi David, Thank you for the review. I have added a few more asserts and uploaded a modified webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ Please do take a relook. Thanks, Jini. > -----Original Message----- > From: David Holmes > Sent: Monday, August 29, 2016 9:36 AM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR:(S): 8164562: > serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > > On 24/08/2016 4:10 PM, Jini Susan George wrote: > > Hi all, > > > > Could you please review the fix for: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 > > > > Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ > > > > I took the liberty to do some module related cleanups in the test also > > while fixing this issue. > > So which change fixes the actual bug? > > As far as I can see if the output of the command is not as expected we > return a null and that then leads to the NPE when calling > String.contains. Seems to me that the test should be more resilient here > and give a meaningful error message if the expected output is not seen. > > Thanks, > David > > > > > > > Thank you, > > > > - Jini Susan George > > > > > > From dmitry.samersoff at oracle.com Mon Aug 29 08:30:49 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 29 Aug 2016 11:30:49 +0300 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> Message-ID: Harsha, I'm for macro. You can define a macro right before a place where you uses it and undef it when you don't need it anymore. -Dmitry On 2016-08-25 11:19, Harsha Wardhana B wrote: > Hello All, > > Please find below the revised webrev below. > > http://cr.openjdk.java.net/~hb/8161448/webrev.01/ > > Regards > > Harsha > > > On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >> Hi David, >> >> >> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>> Hi Harsha, >>> >>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>> Hello All, >>>> >>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>> >>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>> >>> Looks functionally correct, but I wouldn't complain if you wanted to >>> use a macro to reduce the duplication and verbosity. Even the: >>> >>> 109 if (obj == NULL) { >>> 110 free(dcmd_arg_info_array); >>> 111 return NULL; >>> >>> can be replaced by an exception-check as that is the only time >>> JNU_NewObjectByName can return NULL. >> I am not sure if using macro here is good practice since it will be >> specific to the function and it will encapsulate the local variable >> within it. Also, it will reduce code readability. Hence I would like >> to leave it as is. >>> >>> I also noticed an issue that was flagged in some other JNI code lately: >>> >>> 213 if (obj == NULL) { >>> 214 free(dcmd_info_array); >>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>> 216 return NULL; >>> >>> If obj == NULL then there is already a pending exception and we >>> should not be throwing OOME. >>> >> Sure. This needs to be fixed. >>> Thanks, >>> David >>> >>>> Regards >>>> >>>> Harsha >>>> >> Harsha > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From alexander.kulyakhtin at oracle.com Mon Aug 29 12:29:31 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Mon, 29 Aug 2016 05:29:31 -0700 (PDT) Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" Message-ID: <1e141916-8d0c-4061-829d-7e819f5e5b0e@default> Hi Sergey, Thank you very much for your help. With the changes, as you have proposed, the test now passes on all configurations. Please, find the updated webrev at: http://cr.openjdk.java.net/~akulyakh/8148103_03/ Regarding a more thorough verification of the Classloader command, I suggest submitting a new enhancement CR for that, so that the current test can be integrated while we are working on the enhancement. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net Cc: christian.tornqvist at oracle.com Sent: Friday, August 26, 2016 12:03:54 AM GMT +03:00 Iraq Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" Alexander, The fix is pretty good. Some comments besides the bug 8164490 we already discussed. test/serviceability/jdwp/AllModulesCommandTest.java 75 System.err.println("Could not launch the debuggee. Error: '" + line + "'"); A suggestion to replace "Error: " => Error at line: ". Otherwise, the line number will be confused with the error code. 81 // Etsablish JDWP socket connection A typo: Etsablish => Establish The verification in the assertClassLoader is pretty weak. It'd be nice to have more sophisticated verification. For instance, the following commands can be used for such verification: cmdset: ClassLoaderReference=14 , cmd: VisibleClasses=1 cmdset: ReferenceType=2, cmd: ClassLoader=2 cmdset: ReferenceType=2, cmd: Module=19 It is possible to iterate over all classes of the class loader to find at least one class with the given module and check if the class's class loader is the same as module's class loader. BTW, this would test the new jdwp command added for Jigsaw support: cmdset: ReferenceType=2, cmd: Module=19 But I leave it up to you as it looks unreasonably complicated. Maybe, you find a better approach. test/serviceability/jdwp/AllModulesCommandTestDebuggee.java 41 Set modNames = new HashSet<>(); 42 for (Module mod : Layer.boot().modules()) { 43 modNames.add(mod.getName()); 44 String info = String.format("module %s", mod.getName()); 45 write(info); 46 } The local modNames is not really used and can be removed (lines 41, 43). test/serviceability/jdwp/Arch.java It seems, this file/class is not really needed and can be removed. test/serviceability/jdwp/JdwpReply.java Nit: the empty lines 39 and 54 are not needed. Thanks, Serguei On 8/12/16 05:55, Alexander Kulyakhtin wrote: Hi, Could you, please, review the following test-only change (adding a new test): CR: https://bugs.openjdk.java.net/browse/JDK-8148103 Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/ The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. When started the debuggee reports its loaded modules to the test. The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. Best regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.samersoff at oracle.com Mon Aug 29 13:12:12 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Mon, 29 Aug 2016 16:12:12 +0300 Subject: RFR(S): 8163994: Nightly test crashed in jvmtiAllocate In-Reply-To: References: <290c1d74-97ee-95d0-1b20-01d5aebdab48@oracle.com> Message-ID: <3a4bb157-72da-61d6-5952-ed807a130344@oracle.com> Chris & David, JVMTI_ERROR_WRONG_PHASE problem is complicated and requires significant work probably on both JDWP and JVMTI side. Serguei plan to do it as a part of JDK-8134103 and not for JDK 9. So yes, we can close this one as a dup of JDK-8134103 - it has the same root cause and should be addressed as the part of JDK-8134103 (particularly, we have to cleanup ignore_vm_death logic) But the crash is observed only once in a nightly, so my intention is to save us a bit of time next time when this situation happens. i.e. before the changes we get JVMTI_ERROR_WRONG_PHASE message and *crash*, after the changes we get JVMTI_ERROR_WRONG_PHASE message and AGENT_ERROR_INTERNAL message. -Dmitry On 2016-08-29 09:43, Chris Plummer wrote: > On 8/28/16 6:14 PM, David Holmes wrote: >> On 27/08/2016 7:35 AM, Chris Plummer wrote: >>> Hi Dmitry, >>> >>> Although the fix is addressing the specific issue described in the bug, >>> what about the general issue of referencing gdata after a call to >>> cbEarlyVMDeath(). Do more references to gdata need to be protected? >>> >>> Also, is there the possibility of a multi-threading race condition here? >>> Could gdata be cleared by another thread after it is checked? >> >> Certainly. This really isn't fixing anything just adding a bailout >> check before the crashing code. We can still crash and not be any the >> wiser as to why. >> >> Not sure I really see the point of doing this instead of closing this >> as a dup of JDK-8134103 and fixing things properly. > It it correct to say that Dmitry is fixing a bug exposed by JDK-8134103, > or that he is temporarily working around something that is not a true > bug, but is indirectly caused by JDK-8134103. I'm not sure, but the > answer will dictate the correct course of action here. > > Chris >> >> David >> >>> thanks, >>> >>> Chris >>> >>> On 8/26/16 4:00 AM, Dmitry Samersoff wrote: >>>> Everybody, >>>> >>>> Please review the fix. >>>> >>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8163994/webrev.02/ >>>> >>>> *Problem* >>>> >>>> Under some circumstances, when JVMTI_ERROR_WRONG_PHASE(112) is >>>> received, >>>> jvmtiAllocate could be called after call to cbEarlyVMDeath. >>>> >>>> cbEarlyVMDeath set gdata->jvmti to NULL, so jvmtiAllocate crashes. >>>> >>>> The problem appears only once in nightly testing and I was not able to >>>> reproduce it locally. >>>> >>>> *Solution* >>>> >>>> Guard added to jvmtiAllocate to get meaningful error message instead of >>>> crash. >>>> >>>> These fix doesn't fix root cause - JVMTI_ERROR_WRONG_PHASE problem is >>>> going to be addressed under JDK-8134103. >>>> >>>> -Dmitry >>>> >>> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From serguei.spitsyn at oracle.com Mon Aug 29 18:46:05 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Aug 2016 11:46:05 -0700 Subject: RFR(S): 8163994: Nightly test crashed in jvmtiAllocate In-Reply-To: <3a4bb157-72da-61d6-5952-ed807a130344@oracle.com> References: <290c1d74-97ee-95d0-1b20-01d5aebdab48@oracle.com> <3a4bb157-72da-61d6-5952-ed807a130344@oracle.com> Message-ID: <57C482ED.2050804@oracle.com> Chris and David, We had a private discussion about this bug with Dmitry last week. I initially suggested to close it as a dup of JDK-8134103 but then agreed with a fix replacing crash symptom with AGENT_ERROR_INTERNAL. I still have some doubt if it makes sense, as it does not look as important. Now, it seems you also prefer to close this bug as a dup. But let's check your opinion on the Dmitry's reasoning below. Thanks, Serguei On 8/29/16 06:12, Dmitry Samersoff wrote: > Chris & David, > > JVMTI_ERROR_WRONG_PHASE problem is complicated and requires significant > work probably on both JDWP and JVMTI side. Serguei plan to do it as a > part of JDK-8134103 and not for JDK 9. > > So yes, we can close this one as a dup of JDK-8134103 - it has the same > root cause and should be addressed as the part of JDK-8134103 > (particularly, we have to cleanup ignore_vm_death logic) > > But the crash is observed only once in a nightly, so my intention is to > save us a bit of time next time when this situation happens. > > i.e. before the changes we get JVMTI_ERROR_WRONG_PHASE message and > *crash*, after the changes we get JVMTI_ERROR_WRONG_PHASE message > and AGENT_ERROR_INTERNAL message. > > > -Dmitry > > > > On 2016-08-29 09:43, Chris Plummer wrote: >> On 8/28/16 6:14 PM, David Holmes wrote: >>> On 27/08/2016 7:35 AM, Chris Plummer wrote: >>>> Hi Dmitry, >>>> >>>> Although the fix is addressing the specific issue described in the bug, >>>> what about the general issue of referencing gdata after a call to >>>> cbEarlyVMDeath(). Do more references to gdata need to be protected? >>>> >>>> Also, is there the possibility of a multi-threading race condition here? >>>> Could gdata be cleared by another thread after it is checked? >>> Certainly. This really isn't fixing anything just adding a bailout >>> check before the crashing code. We can still crash and not be any the >>> wiser as to why. >>> >>> Not sure I really see the point of doing this instead of closing this >>> as a dup of JDK-8134103 and fixing things properly. >> It it correct to say that Dmitry is fixing a bug exposed by JDK-8134103, >> or that he is temporarily working around something that is not a true >> bug, but is indirectly caused by JDK-8134103. I'm not sure, but the >> answer will dictate the correct course of action here. >> >> Chris >>> David >>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 8/26/16 4:00 AM, Dmitry Samersoff wrote: >>>>> Everybody, >>>>> >>>>> Please review the fix. >>>>> >>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8163994/webrev.02/ >>>>> >>>>> *Problem* >>>>> >>>>> Under some circumstances, when JVMTI_ERROR_WRONG_PHASE(112) is >>>>> received, >>>>> jvmtiAllocate could be called after call to cbEarlyVMDeath. >>>>> >>>>> cbEarlyVMDeath set gdata->jvmti to NULL, so jvmtiAllocate crashes. >>>>> >>>>> The problem appears only once in nightly testing and I was not able to >>>>> reproduce it locally. >>>>> >>>>> *Solution* >>>>> >>>>> Guard added to jvmtiAllocate to get meaningful error message instead of >>>>> crash. >>>>> >>>>> These fix doesn't fix root cause - JVMTI_ERROR_WRONG_PHASE problem is >>>>> going to be addressed under JDK-8134103. >>>>> >>>>> -Dmitry >>>>> > From serguei.spitsyn at oracle.com Mon Aug 29 19:00:16 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Aug 2016 12:00:16 -0700 Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" In-Reply-To: <1e141916-8d0c-4061-829d-7e819f5e5b0e@default> References: <1e141916-8d0c-4061-829d-7e819f5e5b0e@default> Message-ID: <57C48640.8020505@oracle.com> Hi Alexander, It looks good. Thank you for the update! Please, file an enhancement CR on the additional test coverage for ClassLoader=2 and Module=19 commands. Thanks, Serguei On 8/29/16 05:29, Alexander Kulyakhtin wrote: > Hi Sergey, > > Thank you very much for your help. With the changes, as you have > proposed, the test now passes on all configurations. > > Please, find the updated webrev at: > http://cr.openjdk.java.net/~akulyakh/8148103_03/ > > Regarding a more thorough verification of the Classloader command, I > suggest submitting a new enhancement CR for that, so that the current > test can be integrated while we are working on the enhancement. > > Best regards, > Alexander > > > ----- Original Message ----- > From: serguei.spitsyn at oracle.com > To: alexander.kulyakhtin at oracle.com, serviceability-dev at openjdk.java.net > Cc: christian.tornqvist at oracle.com > Sent: Friday, August 26, 2016 12:03:54 AM GMT +03:00 Iraq > Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP > for modules" > > Alexander, > > The fix is pretty good. > > Some comments besides the bug 8164490 we already discussed. > > test/serviceability/jdwp/AllModulesCommandTest.java > > 75 System.err.println("Could not launch the debuggee. Error: '" + line + "'"); > A suggestion to replace "Error: " => Error at line: ". > Otherwise, the line number will be confused with the error code. > > 81 // Etsablish JDWP socket connection > A typo: Etsablish => Establish > > > The verification in the assertClassLoader is pretty weak. > It'd be nice to have more sophisticated verification. > For instance, the following commands can be used for such verification: > cmdset: ClassLoaderReference=14 , cmd: VisibleClasses=1 > cmdset: ReferenceType=2, cmd: ClassLoader=2 > cmdset: ReferenceType=2, cmd: Module=19 > > It is possible to iterate over all classes of the class loader to find > at least one class with the given module and check if the class's > class loader > is the same as module's class loader. > BTW, this would test the new jdwp command added for Jigsaw support: > cmdset: ReferenceType=2, cmd: Module=19 > > But I leave it up to you as it looks unreasonably complicated. > Maybe, you find a better approach. > > test/serviceability/jdwp/AllModulesCommandTestDebuggee.java > > 41 Set modNames = new HashSet<>(); > 42 for (Module mod : Layer.boot().modules()) { > 43 modNames.add(mod.getName()); > 44 String info = String.format("module %s", mod.getName()); > 45 write(info); > 46 } > The local modNames is not really used and can be removed (lines 41, > 43). > > > test/serviceability/jdwp/Arch.java > > It seems, this file/class is not really needed and can be removed. > > > test/serviceability/jdwp/JdwpReply.java > > Nit: the empty lines 39 and 54 are not needed. > > > > Thanks, > Serguei > > > On 8/12/16 05:55, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review the following test-only change (adding a new test): > > CR:https://bugs.openjdk.java.net/browse/JDK-8148103 > Webrev:http://cr.openjdk.java.net/~akulyakh/8148103_02/ > > The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. > > It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. > > When started the debuggee reports its loaded modules to the test. > The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. > For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. > Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. > > Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. > The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. > > Best regards, > Alexander > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Mon Aug 29 23:08:07 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 29 Aug 2016 17:08:07 -0600 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> Message-ID: On 8/23/16 6:17 AM, Harsha Wardhana B wrote: > Hi David, > > You approach to waiter object is a neat little abstraction and I will > make it a point to use it in future fixes, if required. > > revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ test/java/lang/management/ThreadMXBean/Locks.java General comment: 'synchronized(foo)' and 'synchronized (foo)' are both used. Please pick a style and use it consistently. L24: /* Space added before comment block begin. Please remove it. L76: /* L77: Handy debug function to check if error condition is because of test code or not. L78: */ Should look like this: L76: /* L77: * Handy debug function to check if error condition is because of test code or not. L78: */ That is standard block comment format. L114: /* L115: Do slow check if thread is blocked on a lock. It is possible that last thread L116: to come out of Phaser might still be in Phaser call stack (Unsfe.park) and L117: hence might eventually acquire expected lock. L118: */ Same comment about standard block comment format. Also typo: "Unsfe.park" -> "Unsafe.park". L129: while(p.test(result)){ Space before first '(' and before '{'. L171: // stop here for LockBThread to hold OBJB Perhaps this for the comment: // block here while LockBThread holds OBJB L208: /* L209: Must be invoked from within a Synchronized context L210: */ Same comment about standard block comment format. Also not sure why "Synchronized" is capitalized... L213: boolean isNotified = false; This should probably be volatile. Update: WaitingThread calls OBJC.doWait() and CheckerThread calls OBJC.doNotify(). Yup, it should be volatile. Dan > > On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >> Hi Harsha, >> >> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>> Hello, >>> >>> Please review the below webrev incorporating David's comments. >>> >>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >> >> Using a static isNotified field isn't exactly what I had in mind, I >> was thinking of something more encapsulated - something I thought >> already existed in other tests, but now I can't find it. Eg: >> >> /* synchronization helper for two-thread wait/notify interaction >> */ >> static class WaitObject { >> boolean isNotified = false; >> public void await() throws InterruptedException { >> while (!isNotified) >> wait(); >> isNotified = false; >> } >> public void doNotify() { >> isNotified = true; >> notify(); >> } >> } >> >> then OBJC would be a WaitObject and you would do: >> >> synchronized(OBJC) { >> log("WaitingThread about to wait on objC"); >> try { >> // Signal checker thread, about to wait on objC. >> waiting = false; >> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >> waiting = true; >> OBJC.doWait(); >> } catch (InterruptedException e) { >> ... >> >> etc. >> >> Minor nits: >> - why did you move the @library ? > It was suggested by NetBeans Jtreg plugin to fix tag order. >> - @Override, if used, should be applied consistently > Have applied the annotation consistently. >> - if you want to capitalize objA, objB, objC then ensure you also >> update it in the comments and log statements (it really isn't >> necessary to capitalize them, that is suggested for compile-time >> constants and these are not - they are just static final variables). > Done. > > Thanks > Harsha >> >> >> Thanks, >> David >> >>> Regards >>> >>> Harsha >>> >>> >>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>> Hi David, >>>> >>>> I will incorporate changes suggested by you. Let's wait for few more >>>> review comments and then I will send consolidated webrev. >>>> >>>> Regards >>>> Harsha >>>> >>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>> Hi David, >>>>>> >>>>>> Agreed that we could fix WaitingThread the way you have said, but in >>>>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>>>> >>>>> Nor are there likely to be - that's what makes spurious wakeup bugs >>>>> so difficult to detect! >>>>> >>>>>> This test has been fixed several times (3-4) for intermittent >>>>>> failures >>>>>> and hence I would not like to meddle with code that is not >>>>>> causing any >>>>>> problems even though there is scope for refactoring. >>>>> >>>>> It isn't refactoring it is fixing and we have fixed several tests in >>>>> a similar way. >>>>> >>>>>> The issue reported was with LockThreadB and hence I have provided >>>>>> possible fix for the same. >>>>> >>>>> That doesn't preclude fixing other issues with the test at the same >>>>> time. >>>>> >>>>> David >>>>> >>>>>> Thanks >>>>>> >>>>>> Harsha >>>>>> >>>>>> >>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>> Hi Harsha, >>>>>>> >>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review and provide comments for fix for issue, >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>> >>>>>>>> having webrev located at >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>> >>>>>>> These changes look quite good (though I have to admit I struggle to >>>>>>> read the lambda and stream code :) ). >>>>>>> >>>>>>> Note that like many of these kinds of tests there is an issue with >>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>> susceptible >>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>> variable and then do: >>>>>>> >>>>>>> while (!notified) >>>>>>> wait(); >>>>>>> >>>>>>> and set notified before the notify(). >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Fix details: >>>>>>>> >>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>>> wrong >>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>> thread is >>>>>>>> blocked on expected object. It is possible that LockThreadB might >>>>>>>> still >>>>>>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>>>>>>> invoked. >>>>>>>> >>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>> being >>>>>>>> printed. >>>>>>>> >>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>> helps us >>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>> >>>>>>>> 4. Even though we had lock free logger, several >>>>>>>> ex.printStackTrace() was >>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>> >>>>>>>> 5. There were several places where tests continue to ran even >>>>>>>> after >>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>> >>>>>>>> 6. Couple of other minor refactoring. >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Harsha >>>>>>>> >>>>>> >>>> >>> > From david.holmes at oracle.com Tue Aug 30 02:51:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 12:51:44 +1000 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> Message-ID: <4219f24c-a1b6-d610-99d4-e242769be24a@oracle.com> On 30/08/2016 9:08 AM, Daniel D. Daugherty wrote: > On 8/23/16 6:17 AM, Harsha Wardhana B wrote: >> Hi David, >> >> You approach to waiter object is a neat little abstraction and I will >> make it a point to use it in future fixes, if required. >> >> revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ > > test/java/lang/management/ThreadMXBean/Locks.java > General comment: > 'synchronized(foo)' and 'synchronized (foo)' are both used. > Please pick a style and use it consistently. > > L24: /* > Space added before comment block begin. Please remove it. > > L76: /* > L77: Handy debug function to check if error condition is because > of test code or not. > L78: */ > Should look like this: > > L76: /* > L77: * Handy debug function to check if error condition is > because of test code or not. > L78: */ > > That is standard block comment format. > > L114: /* > L115: Do slow check if thread is blocked on a lock. It is > possible that last thread > L116: to come out of Phaser might still be in Phaser call stack > (Unsfe.park) and > L117: hence might eventually acquire expected lock. > L118: */ > Same comment about standard block comment format. > > Also typo: "Unsfe.park" -> "Unsafe.park". > > L129: while(p.test(result)){ > Space before first '(' and before '{'. > > L171: // stop here for LockBThread to hold OBJB > Perhaps this for the comment: > // block here while LockBThread holds OBJB > > L208: /* > L209: Must be invoked from within a Synchronized context > L210: */ > Same comment about standard block comment format. > > Also not sure why "Synchronized" is capitalized... > > L213: boolean isNotified = false; > This should probably be volatile. > > Update: WaitingThread calls OBJC.doWait() and > CheckerThread calls OBJC.doNotify(). Yup, it should > be volatile. Nope - it is only accessed under synchronization lock, which must be held by the caller else the wait()/notify() will throw IllegalMonitorStateException. David ----- > Dan > > >> >> On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >>> Hi Harsha, >>> >>> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>>> Hello, >>>> >>>> Please review the below webrev incorporating David's comments. >>>> >>>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >>> >>> Using a static isNotified field isn't exactly what I had in mind, I >>> was thinking of something more encapsulated - something I thought >>> already existed in other tests, but now I can't find it. Eg: >>> >>> /* synchronization helper for two-thread wait/notify interaction >>> */ >>> static class WaitObject { >>> boolean isNotified = false; >>> public void await() throws InterruptedException { >>> while (!isNotified) >>> wait(); >>> isNotified = false; >>> } >>> public void doNotify() { >>> isNotified = true; >>> notify(); >>> } >>> } >>> >>> then OBJC would be a WaitObject and you would do: >>> >>> synchronized(OBJC) { >>> log("WaitingThread about to wait on objC"); >>> try { >>> // Signal checker thread, about to wait on objC. >>> waiting = false; >>> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >>> waiting = true; >>> OBJC.doWait(); >>> } catch (InterruptedException e) { >>> ... >>> >>> etc. >>> >>> Minor nits: >>> - why did you move the @library ? >> It was suggested by NetBeans Jtreg plugin to fix tag order. >>> - @Override, if used, should be applied consistently >> Have applied the annotation consistently. >>> - if you want to capitalize objA, objB, objC then ensure you also >>> update it in the comments and log statements (it really isn't >>> necessary to capitalize them, that is suggested for compile-time >>> constants and these are not - they are just static final variables). >> Done. >> >> Thanks >> Harsha >>> >>> >>> Thanks, >>> David >>> >>>> Regards >>>> >>>> Harsha >>>> >>>> >>>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>>> Hi David, >>>>> >>>>> I will incorporate changes suggested by you. Let's wait for few more >>>>> review comments and then I will send consolidated webrev. >>>>> >>>>> Regards >>>>> Harsha >>>>> >>>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Agreed that we could fix WaitingThread the way you have said, but in >>>>>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>>>>> >>>>>> Nor are there likely to be - that's what makes spurious wakeup bugs >>>>>> so difficult to detect! >>>>>> >>>>>>> This test has been fixed several times (3-4) for intermittent >>>>>>> failures >>>>>>> and hence I would not like to meddle with code that is not >>>>>>> causing any >>>>>>> problems even though there is scope for refactoring. >>>>>> >>>>>> It isn't refactoring it is fixing and we have fixed several tests in >>>>>> a similar way. >>>>>> >>>>>>> The issue reported was with LockThreadB and hence I have provided >>>>>>> possible fix for the same. >>>>>> >>>>>> That doesn't preclude fixing other issues with the test at the same >>>>>> time. >>>>>> >>>>>> David >>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Harsha >>>>>>> >>>>>>> >>>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>>> Hi Harsha, >>>>>>>> >>>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Please review and provide comments for fix for issue, >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>>> >>>>>>>>> having webrev located at >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>>> >>>>>>>> These changes look quite good (though I have to admit I struggle to >>>>>>>> read the lambda and stream code :) ). >>>>>>>> >>>>>>>> Note that like many of these kinds of tests there is an issue with >>>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>>> susceptible >>>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>>> variable and then do: >>>>>>>> >>>>>>>> while (!notified) >>>>>>>> wait(); >>>>>>>> >>>>>>>> and set notified before the notify(). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Fix details: >>>>>>>>> >>>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>>>> wrong >>>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>>> thread is >>>>>>>>> blocked on expected object. It is possible that LockThreadB might >>>>>>>>> still >>>>>>>>> be in Phaser call stack (Unsafe.park) when 'checkBlockedObject' is >>>>>>>>> invoked. >>>>>>>>> >>>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>>> being >>>>>>>>> printed. >>>>>>>>> >>>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>>> helps us >>>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>>> >>>>>>>>> 4. Even though we had lock free logger, several >>>>>>>>> ex.printStackTrace() was >>>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>>> >>>>>>>>> 5. There were several places where tests continue to ran even >>>>>>>>> after >>>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>>> >>>>>>>>> 6. Couple of other minor refactoring. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Harsha >>>>>>>>> >>>>>>> >>>>> >>>> >> > From david.holmes at oracle.com Tue Aug 30 03:05:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 13:05:06 +1000 Subject: RFR(S): 8163994: Nightly test crashed in jvmtiAllocate In-Reply-To: <57C482ED.2050804@oracle.com> References: <290c1d74-97ee-95d0-1b20-01d5aebdab48@oracle.com> <3a4bb157-72da-61d6-5952-ed807a130344@oracle.com> <57C482ED.2050804@oracle.com> Message-ID: <0a0a1dce-5ec0-05ca-4918-5ad0ae108938@oracle.com> Hi Serguei, On 30/08/2016 4:46 AM, serguei.spitsyn at oracle.com wrote: > Chris and David, > > We had a private discussion about this bug with Dmitry last week. > I initially suggested to close it as a dup of JDK-8134103 but then > agreed with a fix replacing crash symptom with AGENT_ERROR_INTERNAL. > I still have some doubt if it makes sense, as it does not look as > important. > > Now, it seems you also prefer to close this bug as a dup. > But let's check your opinion on the Dmitry's reasoning below. The problem is that the "fix" still doesn't guarantee that we will get the more informative AGENT_ERROR_INTERNAL. The whole situation is racy. But I won't block it and don't want to waste time arguing over it. So if Dmitry wants to proceed then you can count this as Reviewed. Thanks, David ----- > Thanks, > Serguei > > > On 8/29/16 06:12, Dmitry Samersoff wrote: >> Chris & David, >> >> JVMTI_ERROR_WRONG_PHASE problem is complicated and requires significant >> work probably on both JDWP and JVMTI side. Serguei plan to do it as a >> part of JDK-8134103 and not for JDK 9. >> >> So yes, we can close this one as a dup of JDK-8134103 - it has the same >> root cause and should be addressed as the part of JDK-8134103 >> (particularly, we have to cleanup ignore_vm_death logic) >> >> But the crash is observed only once in a nightly, so my intention is to >> save us a bit of time next time when this situation happens. >> >> i.e. before the changes we get JVMTI_ERROR_WRONG_PHASE message and >> *crash*, after the changes we get JVMTI_ERROR_WRONG_PHASE message >> and AGENT_ERROR_INTERNAL message. >> >> >> -Dmitry >> >> >> >> On 2016-08-29 09:43, Chris Plummer wrote: >>> On 8/28/16 6:14 PM, David Holmes wrote: >>>> On 27/08/2016 7:35 AM, Chris Plummer wrote: >>>>> Hi Dmitry, >>>>> >>>>> Although the fix is addressing the specific issue described in the >>>>> bug, >>>>> what about the general issue of referencing gdata after a call to >>>>> cbEarlyVMDeath(). Do more references to gdata need to be protected? >>>>> >>>>> Also, is there the possibility of a multi-threading race condition >>>>> here? >>>>> Could gdata be cleared by another thread after it is checked? >>>> Certainly. This really isn't fixing anything just adding a bailout >>>> check before the crashing code. We can still crash and not be any the >>>> wiser as to why. >>>> >>>> Not sure I really see the point of doing this instead of closing this >>>> as a dup of JDK-8134103 and fixing things properly. >>> It it correct to say that Dmitry is fixing a bug exposed by JDK-8134103, >>> or that he is temporarily working around something that is not a true >>> bug, but is indirectly caused by JDK-8134103. I'm not sure, but the >>> answer will dictate the correct course of action here. >>> >>> Chris >>>> David >>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 8/26/16 4:00 AM, Dmitry Samersoff wrote: >>>>>> Everybody, >>>>>> >>>>>> Please review the fix. >>>>>> >>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8163994/webrev.02/ >>>>>> >>>>>> *Problem* >>>>>> >>>>>> Under some circumstances, when JVMTI_ERROR_WRONG_PHASE(112) is >>>>>> received, >>>>>> jvmtiAllocate could be called after call to cbEarlyVMDeath. >>>>>> >>>>>> cbEarlyVMDeath set gdata->jvmti to NULL, so jvmtiAllocate crashes. >>>>>> >>>>>> The problem appears only once in nightly testing and I was not >>>>>> able to >>>>>> reproduce it locally. >>>>>> >>>>>> *Solution* >>>>>> >>>>>> Guard added to jvmtiAllocate to get meaningful error message >>>>>> instead of >>>>>> crash. >>>>>> >>>>>> These fix doesn't fix root cause - JVMTI_ERROR_WRONG_PHASE problem is >>>>>> going to be addressed under JDK-8134103. >>>>>> >>>>>> -Dmitry >>>>>> >> > From harsha.wardhana.b at oracle.com Tue Aug 30 03:47:21 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 30 Aug 2016 09:17:21 +0530 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> Message-ID: <32bedd63-c1db-e7ae-c7aa-8a2b7a446244@oracle.com> Hi Dmitry, I am not sure how using macro will help in this context. As far as I know, macros must be sparingly used as they are error-prone, obfuscate the code and hard to debug. Most of best coding practice for c/c++ (inluding Scott Myers Effective C++ ) advocate using macros only if it is absolutely needed. -Harsha On Monday 29 August 2016 02:00 PM, Dmitry Samersoff wrote: > Harsha, > > I'm for macro. > > You can define a macro right before a place where you uses it and undef > it when you don't need it anymore. > > -Dmitry > > > On 2016-08-25 11:19, Harsha Wardhana B wrote: >> Hello All, >> >> Please find below the revised webrev below. >> >> http://cr.openjdk.java.net/~hb/8161448/webrev.01/ >> >> Regards >> >> Harsha >> >> >> On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >>> Hi David, >>> >>> >>> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>>> Hi Harsha, >>>> >>>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>>> Hello All, >>>>> >>>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>>> >>>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>>> Looks functionally correct, but I wouldn't complain if you wanted to >>>> use a macro to reduce the duplication and verbosity. Even the: >>>> >>>> 109 if (obj == NULL) { >>>> 110 free(dcmd_arg_info_array); >>>> 111 return NULL; >>>> >>>> can be replaced by an exception-check as that is the only time >>>> JNU_NewObjectByName can return NULL. >>> I am not sure if using macro here is good practice since it will be >>> specific to the function and it will encapsulate the local variable >>> within it. Also, it will reduce code readability. Hence I would like >>> to leave it as is. >>>> I also noticed an issue that was flagged in some other JNI code lately: >>>> >>>> 213 if (obj == NULL) { >>>> 214 free(dcmd_info_array); >>>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>>> 216 return NULL; >>>> >>>> If obj == NULL then there is already a pending exception and we >>>> should not be throwing OOME. >>>> >>> Sure. This needs to be fixed. >>>> Thanks, >>>> David >>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>> Harsha > From harsha.wardhana.b at oracle.com Tue Aug 30 03:52:10 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 30 Aug 2016 09:22:10 +0530 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <4219f24c-a1b6-d610-99d4-e242769be24a@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> <4219f24c-a1b6-d610-99d4-e242769be24a@oracle.com> Message-ID: David, Does accessing under synchronization lock guarantee visibility to variable modifications? -Harsha On Tuesday 30 August 2016 08:21 AM, David Holmes wrote: > > > On 30/08/2016 9:08 AM, Daniel D. Daugherty wrote: >> On 8/23/16 6:17 AM, Harsha Wardhana B wrote: >>> Hi David, >>> >>> You approach to waiter object is a neat little abstraction and I will >>> make it a point to use it in future fixes, if required. >>> >>> revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ >> >> test/java/lang/management/ThreadMXBean/Locks.java >> General comment: >> 'synchronized(foo)' and 'synchronized (foo)' are both used. >> Please pick a style and use it consistently. >> >> L24: /* >> Space added before comment block begin. Please remove it. >> >> L76: /* >> L77: Handy debug function to check if error condition is because >> of test code or not. >> L78: */ >> Should look like this: >> >> L76: /* >> L77: * Handy debug function to check if error condition is >> because of test code or not. >> L78: */ >> >> That is standard block comment format. >> >> L114: /* >> L115: Do slow check if thread is blocked on a lock. It is >> possible that last thread >> L116: to come out of Phaser might still be in Phaser call stack >> (Unsfe.park) and >> L117: hence might eventually acquire expected lock. >> L118: */ >> Same comment about standard block comment format. >> >> Also typo: "Unsfe.park" -> "Unsafe.park". >> >> L129: while(p.test(result)){ >> Space before first '(' and before '{'. >> >> L171: // stop here for LockBThread to hold OBJB >> Perhaps this for the comment: >> // block here while LockBThread holds OBJB >> >> L208: /* >> L209: Must be invoked from within a Synchronized context >> L210: */ >> Same comment about standard block comment format. >> >> Also not sure why "Synchronized" is capitalized... >> >> L213: boolean isNotified = false; >> This should probably be volatile. >> >> Update: WaitingThread calls OBJC.doWait() and >> CheckerThread calls OBJC.doNotify(). Yup, it should >> be volatile. > > Nope - it is only accessed under synchronization lock, which must be > held by the caller else the wait()/notify() will throw > IllegalMonitorStateException. > > David > ----- > >> Dan >> >> >>> >>> On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >>>> Hi Harsha, >>>> >>>> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>>>> Hello, >>>>> >>>>> Please review the below webrev incorporating David's comments. >>>>> >>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >>>> >>>> Using a static isNotified field isn't exactly what I had in mind, I >>>> was thinking of something more encapsulated - something I thought >>>> already existed in other tests, but now I can't find it. Eg: >>>> >>>> /* synchronization helper for two-thread wait/notify interaction >>>> */ >>>> static class WaitObject { >>>> boolean isNotified = false; >>>> public void await() throws InterruptedException { >>>> while (!isNotified) >>>> wait(); >>>> isNotified = false; >>>> } >>>> public void doNotify() { >>>> isNotified = true; >>>> notify(); >>>> } >>>> } >>>> >>>> then OBJC would be a WaitObject and you would do: >>>> >>>> synchronized(OBJC) { >>>> log("WaitingThread about to wait on objC"); >>>> try { >>>> // Signal checker thread, about to wait on objC. >>>> waiting = false; >>>> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >>>> waiting = true; >>>> OBJC.doWait(); >>>> } catch (InterruptedException e) { >>>> ... >>>> >>>> etc. >>>> >>>> Minor nits: >>>> - why did you move the @library ? >>> It was suggested by NetBeans Jtreg plugin to fix tag order. >>>> - @Override, if used, should be applied consistently >>> Have applied the annotation consistently. >>>> - if you want to capitalize objA, objB, objC then ensure you also >>>> update it in the comments and log statements (it really isn't >>>> necessary to capitalize them, that is suggested for compile-time >>>> constants and these are not - they are just static final variables). >>> Done. >>> >>> Thanks >>> Harsha >>>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>>> >>>>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>>>> Hi David, >>>>>> >>>>>> I will incorporate changes suggested by you. Let's wait for few more >>>>>> review comments and then I will send consolidated webrev. >>>>>> >>>>>> Regards >>>>>> Harsha >>>>>> >>>>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Agreed that we could fix WaitingThread the way you have said, >>>>>>>> but in >>>>>>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>>>>>> >>>>>>> Nor are there likely to be - that's what makes spurious wakeup bugs >>>>>>> so difficult to detect! >>>>>>> >>>>>>>> This test has been fixed several times (3-4) for intermittent >>>>>>>> failures >>>>>>>> and hence I would not like to meddle with code that is not >>>>>>>> causing any >>>>>>>> problems even though there is scope for refactoring. >>>>>>> >>>>>>> It isn't refactoring it is fixing and we have fixed several >>>>>>> tests in >>>>>>> a similar way. >>>>>>> >>>>>>>> The issue reported was with LockThreadB and hence I have provided >>>>>>>> possible fix for the same. >>>>>>> >>>>>>> That doesn't preclude fixing other issues with the test at the same >>>>>>> time. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Harsha >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>>>> Hi Harsha, >>>>>>>>> >>>>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review and provide comments for fix for issue, >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>>>> >>>>>>>>>> having webrev located at >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>>>> >>>>>>>>> These changes look quite good (though I have to admit I >>>>>>>>> struggle to >>>>>>>>> read the lambda and stream code :) ). >>>>>>>>> >>>>>>>>> Note that like many of these kinds of tests there is an issue >>>>>>>>> with >>>>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>>>> susceptible >>>>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>>>> variable and then do: >>>>>>>>> >>>>>>>>> while (!notified) >>>>>>>>> wait(); >>>>>>>>> >>>>>>>>> and set notified before the notify(). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Fix details: >>>>>>>>>> >>>>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>>>>> wrong >>>>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>>>> thread is >>>>>>>>>> blocked on expected object. It is possible that LockThreadB >>>>>>>>>> might >>>>>>>>>> still >>>>>>>>>> be in Phaser call stack (Unsafe.park) when >>>>>>>>>> 'checkBlockedObject' is >>>>>>>>>> invoked. >>>>>>>>>> >>>>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>>>> being >>>>>>>>>> printed. >>>>>>>>>> >>>>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>>>> helps us >>>>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>>>> >>>>>>>>>> 4. Even though we had lock free logger, several >>>>>>>>>> ex.printStackTrace() was >>>>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>>>> >>>>>>>>>> 5. There were several places where tests continue to ran even >>>>>>>>>> after >>>>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>>>> >>>>>>>>>> 6. Couple of other minor refactoring. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Harsha >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From david.holmes at oracle.com Tue Aug 30 03:56:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 13:56:31 +1000 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: <32bedd63-c1db-e7ae-c7aa-8a2b7a446244@oracle.com> References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> <32bedd63-c1db-e7ae-c7aa-8a2b7a446244@oracle.com> Message-ID: On 30/08/2016 1:47 PM, Harsha Wardhana B wrote: > Hi Dmitry, > > I am not sure how using macro will help in this context. As far as I > know, macros must be sparingly used as they are error-prone, obfuscate > the code and hard to debug. Most of best coding practice for c/c++ > (inluding Scott Myers Effective C++ ) advocate using macros only if it > is absolutely needed. Macros are used extensively throughout hotspot and the JDK native code. That isn't to say that all such macro uses are good (we have bad code too). However macros make sense where you want to avoid code duplication and improve readability - as is the case here. It is quite common to "hide" error checking logic behind a macro because it is the error-checking logic that obfuscates the code. David ----- > -Harsha > > > On Monday 29 August 2016 02:00 PM, Dmitry Samersoff wrote: >> Harsha, >> >> I'm for macro. >> >> You can define a macro right before a place where you uses it and undef >> it when you don't need it anymore. >> >> -Dmitry >> >> >> On 2016-08-25 11:19, Harsha Wardhana B wrote: >>> Hello All, >>> >>> Please find below the revised webrev below. >>> >>> http://cr.openjdk.java.net/~hb/8161448/webrev.01/ >>> >>> Regards >>> >>> Harsha >>> >>> >>> On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >>>> Hi David, >>>> >>>> >>>> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>>>> Hi Harsha, >>>>> >>>>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>>>> Hello All, >>>>>> >>>>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>>>> >>>>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>>>> Looks functionally correct, but I wouldn't complain if you wanted to >>>>> use a macro to reduce the duplication and verbosity. Even the: >>>>> >>>>> 109 if (obj == NULL) { >>>>> 110 free(dcmd_arg_info_array); >>>>> 111 return NULL; >>>>> >>>>> can be replaced by an exception-check as that is the only time >>>>> JNU_NewObjectByName can return NULL. >>>> I am not sure if using macro here is good practice since it will be >>>> specific to the function and it will encapsulate the local variable >>>> within it. Also, it will reduce code readability. Hence I would like >>>> to leave it as is. >>>>> I also noticed an issue that was flagged in some other JNI code >>>>> lately: >>>>> >>>>> 213 if (obj == NULL) { >>>>> 214 free(dcmd_info_array); >>>>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>>>> 216 return NULL; >>>>> >>>>> If obj == NULL then there is already a pending exception and we >>>>> should not be throwing OOME. >>>>> >>>> Sure. This needs to be fixed. >>>>> Thanks, >>>>> David >>>>> >>>>>> Regards >>>>>> >>>>>> Harsha >>>>>> >>>> Harsha >> > From harsha.wardhana.b at oracle.com Tue Aug 30 04:06:46 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 30 Aug 2016 09:36:46 +0530 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> <32bedd63-c1db-e7ae-c7aa-8a2b7a446244@oracle.com> Message-ID: <9b10fa8c-6402-ee8c-1464-cd9bea19a51c@oracle.com> Error checking might distract the main flow of code but it would be far-fetched to call that it obfuscates the code. Ideally error checking could have been made a function (inline if possible) instead of a macro but since it is context sensitive in this case (have to free variables depending on context) , doing so would obfuscate the code even more. I tried to separate it into a function and the code looks more uglier. -Harsha On Tuesday 30 August 2016 09:26 AM, David Holmes wrote: > On 30/08/2016 1:47 PM, Harsha Wardhana B wrote: >> Hi Dmitry, >> >> I am not sure how using macro will help in this context. As far as I >> know, macros must be sparingly used as they are error-prone, obfuscate >> the code and hard to debug. Most of best coding practice for c/c++ >> (inluding Scott Myers Effective C++ ) advocate using macros only if it >> is absolutely needed. > > Macros are used extensively throughout hotspot and the JDK native > code. That isn't to say that all such macro uses are good (we have bad > code too). However macros make sense where you want to avoid code > duplication and improve readability - as is the case here. It is quite > common to "hide" error checking logic behind a macro because it is the > error-checking logic that obfuscates the code. > > David > ----- > >> -Harsha >> >> >> On Monday 29 August 2016 02:00 PM, Dmitry Samersoff wrote: >>> Harsha, >>> >>> I'm for macro. >>> >>> You can define a macro right before a place where you uses it and undef >>> it when you don't need it anymore. >>> >>> -Dmitry >>> >>> >>> On 2016-08-25 11:19, Harsha Wardhana B wrote: >>>> Hello All, >>>> >>>> Please find below the revised webrev below. >>>> >>>> http://cr.openjdk.java.net/~hb/8161448/webrev.01/ >>>> >>>> Regards >>>> >>>> Harsha >>>> >>>> >>>> On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >>>>> Hi David, >>>>> >>>>> >>>>> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>>>>> Hi Harsha, >>>>>> >>>>>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>>>>> Hello All, >>>>>>> >>>>>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>>>>> >>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>>>>> >>>>>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>>>>> Looks functionally correct, but I wouldn't complain if you wanted to >>>>>> use a macro to reduce the duplication and verbosity. Even the: >>>>>> >>>>>> 109 if (obj == NULL) { >>>>>> 110 free(dcmd_arg_info_array); >>>>>> 111 return NULL; >>>>>> >>>>>> can be replaced by an exception-check as that is the only time >>>>>> JNU_NewObjectByName can return NULL. >>>>> I am not sure if using macro here is good practice since it will be >>>>> specific to the function and it will encapsulate the local variable >>>>> within it. Also, it will reduce code readability. Hence I would like >>>>> to leave it as is. >>>>>> I also noticed an issue that was flagged in some other JNI code >>>>>> lately: >>>>>> >>>>>> 213 if (obj == NULL) { >>>>>> 214 free(dcmd_info_array); >>>>>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>>>>> 216 return NULL; >>>>>> >>>>>> If obj == NULL then there is already a pending exception and we >>>>>> should not be throwing OOME. >>>>>> >>>>> Sure. This needs to be fixed. >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Harsha >>>>>>> >>>>> Harsha >>> >> From david.holmes at oracle.com Tue Aug 30 04:16:53 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 14:16:53 +1000 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: <9b10fa8c-6402-ee8c-1464-cd9bea19a51c@oracle.com> References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> <32bedd63-c1db-e7ae-c7aa-8a2b7a446244@oracle.com> <9b10fa8c-6402-ee8c-1464-cd9bea19a51c@oracle.com> Message-ID: <810bd003-ff73-dd90-6bda-781d7b5bbc4e@oracle.com> On 30/08/2016 2:06 PM, Harsha Wardhana B wrote: > Error checking might distract the main flow of code but it would be > far-fetched to call that it obfuscates the code. Ideally error checking You claimed macros obfuscate so the same word seemed appropriate. I don't necessarily equate readability with obfuscation. > could have been made a function (inline if possible) instead of a macro > but since it is context sensitive in this case (have to free variables > depending on context) , doing so would obfuscate the code even more. > > I tried to separate it into a function and the code looks more uglier. I was envisaging something like: jstring jname, jdesc,jtype,jdefStr; jname = (*env)->NewStringUTF(env,dcmd_arg_info_array[i].name); EXCEPTION_CHECK_AND_FREE(dcmd_arg_info_array); jdesc = (*env)->NewStringUTF(env,dcmd_arg_info_array[i].description); EXCEPTION_CHECK_AND_FREE(dcmd_arg_info_array); jtype = (*env)->NewStringUTF(env,dcmd_arg_info_array[i].type); EXCEPTION_CHECK_AND_FREE(dcmd_arg_info_array); jdefStr = (*env)->NewStringUTF(env, dcmd_arg_info_array[i].default_string); EXCEPTION_CHECK_AND_FREE(dcmd_arg_info_array); Of course if this were C++ code instead of C there would be better techniques for dealing with the free'ing. Cheers, David > -Harsha > On Tuesday 30 August 2016 09:26 AM, David Holmes wrote: >> On 30/08/2016 1:47 PM, Harsha Wardhana B wrote: >>> Hi Dmitry, >>> >>> I am not sure how using macro will help in this context. As far as I >>> know, macros must be sparingly used as they are error-prone, obfuscate >>> the code and hard to debug. Most of best coding practice for c/c++ >>> (inluding Scott Myers Effective C++ ) advocate using macros only if it >>> is absolutely needed. >> >> Macros are used extensively throughout hotspot and the JDK native >> code. That isn't to say that all such macro uses are good (we have bad >> code too). However macros make sense where you want to avoid code >> duplication and improve readability - as is the case here. It is quite >> common to "hide" error checking logic behind a macro because it is the >> error-checking logic that obfuscates the code. >> >> David >> ----- >> >>> -Harsha >>> >>> >>> On Monday 29 August 2016 02:00 PM, Dmitry Samersoff wrote: >>>> Harsha, >>>> >>>> I'm for macro. >>>> >>>> You can define a macro right before a place where you uses it and undef >>>> it when you don't need it anymore. >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-08-25 11:19, Harsha Wardhana B wrote: >>>>> Hello All, >>>>> >>>>> Please find below the revised webrev below. >>>>> >>>>> http://cr.openjdk.java.net/~hb/8161448/webrev.01/ >>>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>>> >>>>> On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >>>>>> Hi David, >>>>>> >>>>>> >>>>>> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>>>>>> Hi Harsha, >>>>>>> >>>>>>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>>>>>> Hello All, >>>>>>>> >>>>>>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>>>>>> >>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>>>>>> >>>>>>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>>>>>> Looks functionally correct, but I wouldn't complain if you wanted to >>>>>>> use a macro to reduce the duplication and verbosity. Even the: >>>>>>> >>>>>>> 109 if (obj == NULL) { >>>>>>> 110 free(dcmd_arg_info_array); >>>>>>> 111 return NULL; >>>>>>> >>>>>>> can be replaced by an exception-check as that is the only time >>>>>>> JNU_NewObjectByName can return NULL. >>>>>> I am not sure if using macro here is good practice since it will be >>>>>> specific to the function and it will encapsulate the local variable >>>>>> within it. Also, it will reduce code readability. Hence I would like >>>>>> to leave it as is. >>>>>>> I also noticed an issue that was flagged in some other JNI code >>>>>>> lately: >>>>>>> >>>>>>> 213 if (obj == NULL) { >>>>>>> 214 free(dcmd_info_array); >>>>>>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>>>>>> 216 return NULL; >>>>>>> >>>>>>> If obj == NULL then there is already a pending exception and we >>>>>>> should not be throwing OOME. >>>>>>> >>>>>> Sure. This needs to be fixed. >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Harsha >>>>>>>> >>>>>> Harsha >>>> >>> > From david.holmes at oracle.com Tue Aug 30 04:51:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 14:51:22 +1000 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> <4219f24c-a1b6-d610-99d4-e242769be24a@oracle.com> Message-ID: <72bc7e5c-986f-c91f-c9d4-58954d299891@oracle.com> On 30/08/2016 1:52 PM, Harsha Wardhana B wrote: > David, > > Does accessing under synchronization lock guarantee visibility to > variable modifications? Yes. As long as all accesses to the variable are with the synchronization lock held then you are guaranteed to see all changes. volatile is only needed for lock-free accesses. David > -Harsha > > On Tuesday 30 August 2016 08:21 AM, David Holmes wrote: >> >> >> On 30/08/2016 9:08 AM, Daniel D. Daugherty wrote: >>> On 8/23/16 6:17 AM, Harsha Wardhana B wrote: >>>> Hi David, >>>> >>>> You approach to waiter object is a neat little abstraction and I will >>>> make it a point to use it in future fixes, if required. >>>> >>>> revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ >>> >>> test/java/lang/management/ThreadMXBean/Locks.java >>> General comment: >>> 'synchronized(foo)' and 'synchronized (foo)' are both used. >>> Please pick a style and use it consistently. >>> >>> L24: /* >>> Space added before comment block begin. Please remove it. >>> >>> L76: /* >>> L77: Handy debug function to check if error condition is because >>> of test code or not. >>> L78: */ >>> Should look like this: >>> >>> L76: /* >>> L77: * Handy debug function to check if error condition is >>> because of test code or not. >>> L78: */ >>> >>> That is standard block comment format. >>> >>> L114: /* >>> L115: Do slow check if thread is blocked on a lock. It is >>> possible that last thread >>> L116: to come out of Phaser might still be in Phaser call stack >>> (Unsfe.park) and >>> L117: hence might eventually acquire expected lock. >>> L118: */ >>> Same comment about standard block comment format. >>> >>> Also typo: "Unsfe.park" -> "Unsafe.park". >>> >>> L129: while(p.test(result)){ >>> Space before first '(' and before '{'. >>> >>> L171: // stop here for LockBThread to hold OBJB >>> Perhaps this for the comment: >>> // block here while LockBThread holds OBJB >>> >>> L208: /* >>> L209: Must be invoked from within a Synchronized context >>> L210: */ >>> Same comment about standard block comment format. >>> >>> Also not sure why "Synchronized" is capitalized... >>> >>> L213: boolean isNotified = false; >>> This should probably be volatile. >>> >>> Update: WaitingThread calls OBJC.doWait() and >>> CheckerThread calls OBJC.doNotify(). Yup, it should >>> be volatile. >> >> Nope - it is only accessed under synchronization lock, which must be >> held by the caller else the wait()/notify() will throw >> IllegalMonitorStateException. >> >> David >> ----- >> >>> Dan >>> >>> >>>> >>>> On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >>>>> Hi Harsha, >>>>> >>>>> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the below webrev incorporating David's comments. >>>>>> >>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >>>>> >>>>> Using a static isNotified field isn't exactly what I had in mind, I >>>>> was thinking of something more encapsulated - something I thought >>>>> already existed in other tests, but now I can't find it. Eg: >>>>> >>>>> /* synchronization helper for two-thread wait/notify interaction >>>>> */ >>>>> static class WaitObject { >>>>> boolean isNotified = false; >>>>> public void await() throws InterruptedException { >>>>> while (!isNotified) >>>>> wait(); >>>>> isNotified = false; >>>>> } >>>>> public void doNotify() { >>>>> isNotified = true; >>>>> notify(); >>>>> } >>>>> } >>>>> >>>>> then OBJC would be a WaitObject and you would do: >>>>> >>>>> synchronized(OBJC) { >>>>> log("WaitingThread about to wait on objC"); >>>>> try { >>>>> // Signal checker thread, about to wait on objC. >>>>> waiting = false; >>>>> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >>>>> waiting = true; >>>>> OBJC.doWait(); >>>>> } catch (InterruptedException e) { >>>>> ... >>>>> >>>>> etc. >>>>> >>>>> Minor nits: >>>>> - why did you move the @library ? >>>> It was suggested by NetBeans Jtreg plugin to fix tag order. >>>>> - @Override, if used, should be applied consistently >>>> Have applied the annotation consistently. >>>>> - if you want to capitalize objA, objB, objC then ensure you also >>>>> update it in the comments and log statements (it really isn't >>>>> necessary to capitalize them, that is suggested for compile-time >>>>> constants and these are not - they are just static final variables). >>>> Done. >>>> >>>> Thanks >>>> Harsha >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Regards >>>>>> >>>>>> Harsha >>>>>> >>>>>> >>>>>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I will incorporate changes suggested by you. Let's wait for few more >>>>>>> review comments and then I will send consolidated webrev. >>>>>>> >>>>>>> Regards >>>>>>> Harsha >>>>>>> >>>>>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Agreed that we could fix WaitingThread the way you have said, >>>>>>>>> but in >>>>>>>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>>>>>>> >>>>>>>> Nor are there likely to be - that's what makes spurious wakeup bugs >>>>>>>> so difficult to detect! >>>>>>>> >>>>>>>>> This test has been fixed several times (3-4) for intermittent >>>>>>>>> failures >>>>>>>>> and hence I would not like to meddle with code that is not >>>>>>>>> causing any >>>>>>>>> problems even though there is scope for refactoring. >>>>>>>> >>>>>>>> It isn't refactoring it is fixing and we have fixed several >>>>>>>> tests in >>>>>>>> a similar way. >>>>>>>> >>>>>>>>> The issue reported was with LockThreadB and hence I have provided >>>>>>>>> possible fix for the same. >>>>>>>> >>>>>>>> That doesn't preclude fixing other issues with the test at the same >>>>>>>> time. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Harsha >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>>>>> Hi Harsha, >>>>>>>>>> >>>>>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review and provide comments for fix for issue, >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>>>>> >>>>>>>>>>> having webrev located at >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>>>>> >>>>>>>>>> These changes look quite good (though I have to admit I >>>>>>>>>> struggle to >>>>>>>>>> read the lambda and stream code :) ). >>>>>>>>>> >>>>>>>>>> Note that like many of these kinds of tests there is an issue >>>>>>>>>> with >>>>>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>>>>> susceptible >>>>>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>>>>> variable and then do: >>>>>>>>>> >>>>>>>>>> while (!notified) >>>>>>>>>> wait(); >>>>>>>>>> >>>>>>>>>> and set notified before the notify(). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Fix details: >>>>>>>>>>> >>>>>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>>>>>> wrong >>>>>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>>>>> thread is >>>>>>>>>>> blocked on expected object. It is possible that LockThreadB >>>>>>>>>>> might >>>>>>>>>>> still >>>>>>>>>>> be in Phaser call stack (Unsafe.park) when >>>>>>>>>>> 'checkBlockedObject' is >>>>>>>>>>> invoked. >>>>>>>>>>> >>>>>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>>>>> being >>>>>>>>>>> printed. >>>>>>>>>>> >>>>>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>>>>> helps us >>>>>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>>>>> >>>>>>>>>>> 4. Even though we had lock free logger, several >>>>>>>>>>> ex.printStackTrace() was >>>>>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>>>>> >>>>>>>>>>> 5. There were several places where tests continue to ran even >>>>>>>>>>> after >>>>>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>>>>> >>>>>>>>>>> 6. Couple of other minor refactoring. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Harsha >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From david.holmes at oracle.com Tue Aug 30 05:37:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 15:37:28 +1000 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: References: Message-ID: <9ee800ea-479b-7a2b-bfd7-f4a45f354a25@oracle.com> Hi Jini, On 29/08/2016 5:51 PM, Jini Susan George wrote: > Hi David, > > Thank you for the review. I have added a few more asserts and uploaded a modified webrev: > > http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ > > Please do take a relook. The added assertions are good. Thanks. The layout/indent in those tests is all over the place, but fixing all that is out of scope I think. We can discuss the use of -XX:+UnlockDiagnosticVMOptions separately. Thanks, David > Thanks, > Jini. > > >> -----Original Message----- >> From: David Holmes >> Sent: Monday, August 29, 2016 9:36 AM >> To: Jini Susan George; serviceability-dev at openjdk.java.net >> Subject: Re: RFR:(S): 8164562: >> serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE >> >> On 24/08/2016 4:10 PM, Jini Susan George wrote: >>> Hi all, >>> >>> Could you please review the fix for: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 >>> >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ >>> >>> I took the liberty to do some module related cleanups in the test also >>> while fixing this issue. >> >> So which change fixes the actual bug? >> >> As far as I can see if the output of the command is not as expected we >> return a null and that then leads to the NPE when calling >> String.contains. Seems to me that the test should be more resilient here >> and give a meaningful error message if the expected output is not seen. >> >> Thanks, >> David >> >>> >>> >>> Thank you, >>> >>> - Jini Susan George >>> >>> >>> From jini.george at oracle.com Tue Aug 30 05:38:42 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 29 Aug 2016 22:38:42 -0700 (PDT) Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: <9ee800ea-479b-7a2b-bfd7-f4a45f354a25@oracle.com> References: <9ee800ea-479b-7a2b-bfd7-f4a45f354a25@oracle.com> Message-ID: <38df56de-d50f-4a09-a11a-671902908415@default> Thank you, David. -jini. > -----Original Message----- > From: David Holmes > Sent: Tuesday, August 30, 2016 11:07 AM > To: Jini Susan George; serviceability-dev at openjdk.java.net > Subject: Re: RFR:(S): 8164562: > serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > > Hi Jini, > > On 29/08/2016 5:51 PM, Jini Susan George wrote: > > Hi David, > > > > Thank you for the review. I have added a few more asserts and uploaded a > modified webrev: > > > > http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ > > > > Please do take a relook. > > The added assertions are good. Thanks. > > The layout/indent in those tests is all over the place, but fixing all > that is out of scope I think. > > We can discuss the use of -XX:+UnlockDiagnosticVMOptions separately. > > Thanks, > David > > > Thanks, > > Jini. > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Monday, August 29, 2016 9:36 AM > >> To: Jini Susan George; serviceability-dev at openjdk.java.net > >> Subject: Re: RFR:(S): 8164562: > >> serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > >> > >> On 24/08/2016 4:10 PM, Jini Susan George wrote: > >>> Hi all, > >>> > >>> Could you please review the fix for: > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8164562 > >>> > >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8164562/webrev.00/ > >>> > >>> I took the liberty to do some module related cleanups in the test also > >>> while fixing this issue. > >> > >> So which change fixes the actual bug? > >> > >> As far as I can see if the output of the command is not as expected we > >> return a null and that then leads to the NPE when calling > >> String.contains. Seems to me that the test should be more resilient here > >> and give a meaningful error message if the expected output is not seen. > >> > >> Thanks, > >> David > >> > >>> > >>> > >>> Thank you, > >>> > >>> - Jini Susan George > >>> > >>> > >>> From amit.sapre at oracle.com Tue Aug 30 05:56:04 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Mon, 29 Aug 2016 22:56:04 -0700 (PDT) Subject: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module In-Reply-To: References: <28eda504-3c5a-4763-b2ee-902c7b3a3dac@default> Message-ID: <6904b38e-e66c-4203-9f41-1ac6c9e61a69@default> Thanks David for your inputs. I like to go the cleanup way and made changes accordingly. The new webrev is http://cr.openjdk.java.net/~jgeorge/sponsorships/8066635/webrev.01/ Thanks, Amit -----Original Message----- From: David Holmes Sent: Wednesday, August 24, 2016 12:24 PM To: Amit Sapre; serviceability-dev Subject: Re: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module Hi Amit, On 24/08/2016 4:37 PM, Amit Sapre wrote: > > *From:*Amit Sapre > *Sent:* Monday, August 22, 2016 2:39 PM > *To:* serviceability-dev > *Subject:* RFR : JDK-8066635 - Fix deprecation warnings in > java.management module > > Hello, > > Please review changes for fixing deprecation warnings. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8066635 > > Webrev : > http://cr.openjdk.java.net/~sballal/sponsorship/8066635/webrev.00/ Marking the methods @Deprecated fixes the problem. Another option would be converting the interface methods to default methods that throw the UnsupportOperationException and then delete them from the DefaultMBeanServerInterceptor class. Your call. If you leave as-is then consider this Reviewed. Thanks, David > > > Amit > From mandy.chung at oracle.com Tue Aug 30 05:56:33 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 29 Aug 2016 22:56:33 -0700 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: References: Message-ID: > On Aug 29, 2016, at 12:51 AM, Jini Susan George wrote: > > Hi David, > > Thank you for the review. I have added a few more asserts and uploaded a modified webrev: > > http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ Looks okay. It?d be helpful if you can make sure your fix can push to jdk9/hs and include in the next hs->dev push. Otherwise these tests without your fix will fail in jdk9/dev since the old CLI option will be removed. thanks Mandy From amit.sapre at oracle.com Tue Aug 30 05:58:06 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Mon, 29 Aug 2016 22:58:06 -0700 (PDT) Subject: RFR : JDK-8164609 : javax/management/remote/mandatory/notif/DeadListenerTest.java fails with AssertionError In-Reply-To: References: Message-ID: <15ce9e43-8757-49b8-802a-2310292db8bc@default> Hello, I made changes as David suggested. Here is the new webrev link http://cr.openjdk.java.net/~jgeorge/sponsorships/8164609/webrev.01/ Thanks, Amit -----Original Message----- From: David Holmes Sent: Monday, August 29, 2016 11:57 AM To: Amit Sapre; serviceability-dev Subject: Re: RFR : JDK-8164609 : javax/management/remote/mandatory/notif/DeadListenerTest.java fails with AssertionError Hi Amit, On 29/08/2016 3:55 PM, Amit Sapre wrote: > Hello, > > Please review a small test only change. > > Bug id : https://bugs.openjdk.java.net/browse/JDK-8164609 > > Webrev : > http://cr.openjdk.java.net/~sballal/sponsorship/8164609/webrev.00/ ! * Copyright (c) 2010, 2015, 2016, Oracle and/or its affiliates. All rights reserved. Copyright format is wrong - we only use first and last year, so just update the existing 2015 to be 2016. ! * @run main/othervm/timeout=120 -XX:+UsePerfData DeadListenerTest I think that is already the default timeout. Only set an explicit timeout if you need it to be longer - which I don't think you do here. Getting rid of the internal timeout mechanism is good. > PS : Based on triaging , it looked like a timing issue in test case, > so the proposed changes are done only to increase the test timeout. If > issue is still observed, will re-open the bug. Once a bug has had a changeset associated with it, it is considered Fixed and must not be reopened. Any subsequent test failures will require a new bug to be filed. Thanks, David > > > Thanks, > > Amit > From amit.sapre at oracle.com Tue Aug 30 06:03:05 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Mon, 29 Aug 2016 23:03:05 -0700 (PDT) Subject: RFR : JDK-8164730 - Make it clear that 'cl' parameter passed to RMIConnector.OISWL is never null. Message-ID: <6771fed3-c671-43e5-9d16-bf70d5304d52@default> Hello, Please review this small code change and a new test case to validate the changes. Bug Id : https://bugs.openjdk.java.net/browse/JDK-8164730 Webrev : http://cr.openjdk.java.net/~jgeorge/sponsorships/8164730/webrev.00/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Aug 30 06:07:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 16:07:33 +1000 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: References: Message-ID: <68314278-ad07-9a50-01b3-e5b0c61f1b1f@oracle.com> Hi Mandy, On 30/08/2016 3:56 PM, Mandy Chung wrote: > >> On Aug 29, 2016, at 12:51 AM, Jini Susan George wrote: >> >> Hi David, >> >> Thank you for the review. I have added a few more asserts and uploaded a modified webrev: >> >> http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ > > Looks okay. It?d be helpful if you can make sure your fix can push to jdk9/hs and include in the next hs->dev push. Otherwise these tests without your fix will fail in jdk9/dev since the old CLI option will be removed. Why wasn't removal deferred until after all test changes were made? There is no guarantees as to when jdk9/hs will push up next - it depends on the changes that go in there and the stability of those changes. David > thanks > Mandy > From david.holmes at oracle.com Tue Aug 30 06:14:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 16:14:19 +1000 Subject: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module In-Reply-To: <6904b38e-e66c-4203-9f41-1ac6c9e61a69@default> References: <28eda504-3c5a-4763-b2ee-902c7b3a3dac@default> <6904b38e-e66c-4203-9f41-1ac6c9e61a69@default> Message-ID: <9c512a1f-b440-6878-9c59-b87744867c99@oracle.com> On 30/08/2016 3:56 PM, Amit Sapre wrote: > Thanks David for your inputs. > I like to go the cleanup way and made changes accordingly. > The new webrev is http://cr.openjdk.java.net/~jgeorge/sponsorships/8066635/webrev.01/ Looks good! Only nit is the argument alignment here: ! default public ObjectInputStream deserialize(String className, ObjectName loaderName, byte[] data) they should align with each other, after the ( Thanks, David > Thanks, > Amit > > -----Original Message----- > From: David Holmes > Sent: Wednesday, August 24, 2016 12:24 PM > To: Amit Sapre; serviceability-dev > Subject: Re: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module > > Hi Amit, > > On 24/08/2016 4:37 PM, Amit Sapre wrote: >> >> *From:*Amit Sapre >> *Sent:* Monday, August 22, 2016 2:39 PM >> *To:* serviceability-dev >> *Subject:* RFR : JDK-8066635 - Fix deprecation warnings in >> java.management module >> >> Hello, >> >> Please review changes for fixing deprecation warnings. >> >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8066635 >> >> Webrev : >> http://cr.openjdk.java.net/~sballal/sponsorship/8066635/webrev.00/ > > Marking the methods @Deprecated fixes the problem. > > Another option would be converting the interface methods to default methods that throw the UnsupportOperationException and then delete them from the DefaultMBeanServerInterceptor class. > > Your call. If you leave as-is then consider this Reviewed. > > Thanks, > David > >> >> >> Amit >> From david.holmes at oracle.com Tue Aug 30 06:15:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 16:15:22 +1000 Subject: RFR : JDK-8164609 : javax/management/remote/mandatory/notif/DeadListenerTest.java fails with AssertionError In-Reply-To: <15ce9e43-8757-49b8-802a-2310292db8bc@default> References: <15ce9e43-8757-49b8-802a-2310292db8bc@default> Message-ID: Looks good! Thanks, David On 30/08/2016 3:58 PM, Amit Sapre wrote: > Hello, > I made changes as David suggested. Here is the new webrev link > > http://cr.openjdk.java.net/~jgeorge/sponsorships/8164609/webrev.01/ > > Thanks, > Amit > > -----Original Message----- > From: David Holmes > Sent: Monday, August 29, 2016 11:57 AM > To: Amit Sapre; serviceability-dev > Subject: Re: RFR : JDK-8164609 : javax/management/remote/mandatory/notif/DeadListenerTest.java fails with AssertionError > > Hi Amit, > > On 29/08/2016 3:55 PM, Amit Sapre wrote: >> Hello, >> >> Please review a small test only change. >> >> Bug id : https://bugs.openjdk.java.net/browse/JDK-8164609 >> >> Webrev : >> http://cr.openjdk.java.net/~sballal/sponsorship/8164609/webrev.00/ > > ! * Copyright (c) 2010, 2015, 2016, Oracle and/or its affiliates. All rights reserved. > > Copyright format is wrong - we only use first and last year, so just update the existing 2015 to be 2016. > > ! * @run main/othervm/timeout=120 -XX:+UsePerfData DeadListenerTest > > I think that is already the default timeout. Only set an explicit timeout if you need it to be longer - which I don't think you do here. > > Getting rid of the internal timeout mechanism is good. > >> PS : Based on triaging , it looked like a timing issue in test case, >> so the proposed changes are done only to increase the test timeout. If >> issue is still observed, will re-open the bug. > > Once a bug has had a changeset associated with it, it is considered Fixed and must not be reopened. Any subsequent test failures will require a new bug to be filed. > > Thanks, > David > >> >> >> Thanks, >> >> Amit >> From jini.george at oracle.com Tue Aug 30 06:15:26 2016 From: jini.george at oracle.com (Jini Susan George) Date: Mon, 29 Aug 2016 23:15:26 -0700 (PDT) Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: References: Message-ID: <1a0d53db-e3f3-45a5-8170-8b8a3e320a87@default> Thank you, Mandy. Aiming at that. -jini. > -----Original Message----- > From: Mandy Chung > Sent: Tuesday, August 30, 2016 11:27 AM > To: Jini Susan George > Cc: David Holmes; serviceability-dev; Alejandro Murillo > Subject: Re: RFR:(S): 8164562: > serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE > > > > On Aug 29, 2016, at 12:51 AM, Jini Susan George > wrote: > > > > Hi David, > > > > Thank you for the review. I have added a few more asserts and uploaded a > modified webrev: > > > > http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ > > Looks okay. It?d be helpful if you can make sure your fix can push to jdk9/hs > and include in the next hs->dev push. Otherwise these tests without your fix > will fail in jdk9/dev since the old CLI option will be removed. > > thanks > Mandy > From mandy.chung at oracle.com Tue Aug 30 06:21:54 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 29 Aug 2016 23:21:54 -0700 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: <68314278-ad07-9a50-01b3-e5b0c61f1b1f@oracle.com> References: <68314278-ad07-9a50-01b3-e5b0c61f1b1f@oracle.com> Message-ID: <572EC52B-484A-4F11-9A08-9F51CDF7DF06@oracle.com> > On Aug 29, 2016, at 11:07 PM, David Holmes wrote: > > Hi Mandy, > > On 30/08/2016 3:56 PM, Mandy Chung wrote: >> >>> On Aug 29, 2016, at 12:51 AM, Jini Susan George wrote: >>> >>> Hi David, >>> >>> Thank you for the review. I have added a few more asserts and uploaded a modified webrev: >>> >>> http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ >> >> Looks okay. It?d be helpful if you can make sure your fix can push to jdk9/hs and include in the next hs->dev push. Otherwise these tests without your fix will fail in jdk9/dev since the old CLI option will be removed. > > Why wasn't removal deferred until after all test changes were made? There is no guarantees as to when jdk9/hs will push up next - it depends on the changes that go in there and the stability of those changes. If jdk9/hs is sync?ed to jdk9/dev without 8164562, doesn?t this test fail with NPE anyway? When the new CLI options are integrated, all regression tests were updated to use the new CLI options. These 2 tests were changed after JDK-8136930 was pushed and use the old CLI options - that happens. The new CLI options has been integrated over 2+ weeks to give time for transition. We should also ask why these tests are not using the new CLI options. In any case, I file https://bugs.openjdk.java.net/browse/JDK-8164902 that Jini has closed as a dup since his patch is going to resolve it. Mandy [1] http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1cbffa2beba6 From alejandro.murillo at oracle.com Tue Aug 30 06:40:20 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Tue, 30 Aug 2016 00:40:20 -0600 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: <1a0d53db-e3f3-45a5-8170-8b8a3e320a87@default> References: <1a0d53db-e3f3-45a5-8170-8b8a3e320a87@default> Message-ID: Please push this to jdk9/dev after Mandy's change is in, to make sure the fix work, and that is there by Thursday when I take the snapshot otherwise there's not guarantee it will be part of the snapshot Thanks Alejandro On 8/30/2016 12:15 AM, Jini Susan George wrote: > Thank you, Mandy. Aiming at that. > > -jini. > >> -----Original Message----- >> From: Mandy Chung >> Sent: Tuesday, August 30, 2016 11:27 AM >> To: Jini Susan George >> Cc: David Holmes; serviceability-dev; Alejandro Murillo >> Subject: Re: RFR:(S): 8164562: >> serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE >> >> >>> On Aug 29, 2016, at 12:51 AM, Jini Susan George >> wrote: >>> Hi David, >>> >>> Thank you for the review. I have added a few more asserts and uploaded a >> modified webrev: >>> http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ >> Looks okay. It?d be helpful if you can make sure your fix can push to jdk9/hs >> and include in the next hs->dev push. Otherwise these tests without your fix >> will fail in jdk9/dev since the old CLI option will be removed. >> >> thanks >> Mandy >> -- Alejandro From harsha.wardhana.b at oracle.com Tue Aug 30 06:51:38 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Tue, 30 Aug 2016 12:21:38 +0530 Subject: RFR: 8161448: 4 JNI exception pending defect groups in DiagnosticCommandImpl.c In-Reply-To: <810bd003-ff73-dd90-6bda-781d7b5bbc4e@oracle.com> References: <60afa3f1-b2f5-6fef-6590-2d1496ac394e@oracle.com> <7eed5760-4787-d63d-4e92-e3e8baef14aa@oracle.com> <32bedd63-c1db-e7ae-c7aa-8a2b7a446244@oracle.com> <9b10fa8c-6402-ee8c-1464-cd9bea19a51c@oracle.com> <810bd003-ff73-dd90-6bda-781d7b5bbc4e@oracle.com> Message-ID: <376c70be-7856-ec54-d8b6-0e7127c39c80@oracle.com> Hello, Please find below webrev addressing David's and Dmitry's comments. http://cr.openjdk.java.net/~hb/8161448/webrev.02/ -Harsha On Tuesday 30 August 2016 09:46 AM, David Holmes wrote: > On 30/08/2016 2:06 PM, Harsha Wardhana B wrote: >> Error checking might distract the main flow of code but it would be >> far-fetched to call that it obfuscates the code. Ideally error checking > > You claimed macros obfuscate so the same word seemed appropriate. I > don't necessarily equate readability with obfuscation. > >> could have been made a function (inline if possible) instead of a macro >> but since it is context sensitive in this case (have to free variables >> depending on context) , doing so would obfuscate the code even more. >> >> I tried to separate it into a function and the code looks more uglier. > > I was envisaging something like: > > jstring jname, jdesc,jtype,jdefStr; > jname = (*env)->NewStringUTF(env,dcmd_arg_info_array[i].name); > EXCEPTION_CHECK_AND_FREE(dcmd_arg_info_array); > jdesc = > (*env)->NewStringUTF(env,dcmd_arg_info_array[i].description); > EXCEPTION_CHECK_AND_FREE(dcmd_arg_info_array); > jtype = (*env)->NewStringUTF(env,dcmd_arg_info_array[i].type); > EXCEPTION_CHECK_AND_FREE(dcmd_arg_info_array); > jdefStr = (*env)->NewStringUTF(env, > dcmd_arg_info_array[i].default_string); > EXCEPTION_CHECK_AND_FREE(dcmd_arg_info_array); > > Of course if this were C++ code instead of C there would be better > techniques for dealing with the free'ing. > > Cheers, > David > > >> -Harsha >> On Tuesday 30 August 2016 09:26 AM, David Holmes wrote: >>> On 30/08/2016 1:47 PM, Harsha Wardhana B wrote: >>>> Hi Dmitry, >>>> >>>> I am not sure how using macro will help in this context. As far as I >>>> know, macros must be sparingly used as they are error-prone, obfuscate >>>> the code and hard to debug. Most of best coding practice for c/c++ >>>> (inluding Scott Myers Effective C++ ) advocate using macros only if it >>>> is absolutely needed. >>> >>> Macros are used extensively throughout hotspot and the JDK native >>> code. That isn't to say that all such macro uses are good (we have bad >>> code too). However macros make sense where you want to avoid code >>> duplication and improve readability - as is the case here. It is quite >>> common to "hide" error checking logic behind a macro because it is the >>> error-checking logic that obfuscates the code. >>> >>> David >>> ----- >>> >>>> -Harsha >>>> >>>> >>>> On Monday 29 August 2016 02:00 PM, Dmitry Samersoff wrote: >>>>> Harsha, >>>>> >>>>> I'm for macro. >>>>> >>>>> You can define a macro right before a place where you uses it and >>>>> undef >>>>> it when you don't need it anymore. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> On 2016-08-25 11:19, Harsha Wardhana B wrote: >>>>>> Hello All, >>>>>> >>>>>> Please find below the revised webrev below. >>>>>> >>>>>> http://cr.openjdk.java.net/~hb/8161448/webrev.01/ >>>>>> >>>>>> Regards >>>>>> >>>>>> Harsha >>>>>> >>>>>> >>>>>> On Wednesday 24 August 2016 11:48 AM, Harsha Wardhana B wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> >>>>>>> On Tuesday 23 August 2016 12:41 PM, David Holmes wrote: >>>>>>>> Hi Harsha, >>>>>>>> >>>>>>>> On 22/08/2016 6:30 PM, Harsha Wardhana B wrote: >>>>>>>>> Hello All, >>>>>>>>> >>>>>>>>> Please review the below parfait fixes for DiagnosticCommandImpl.c >>>>>>>>> >>>>>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8161448 >>>>>>>>> >>>>>>>>> webrev : http://cr.openjdk.java.net/~hb/8161448/webrev.00/ >>>>>>>> Looks functionally correct, but I wouldn't complain if you >>>>>>>> wanted to >>>>>>>> use a macro to reduce the duplication and verbosity. Even the: >>>>>>>> >>>>>>>> 109 if (obj == NULL) { >>>>>>>> 110 free(dcmd_arg_info_array); >>>>>>>> 111 return NULL; >>>>>>>> >>>>>>>> can be replaced by an exception-check as that is the only time >>>>>>>> JNU_NewObjectByName can return NULL. >>>>>>> I am not sure if using macro here is good practice since it will be >>>>>>> specific to the function and it will encapsulate the local variable >>>>>>> within it. Also, it will reduce code readability. Hence I would >>>>>>> like >>>>>>> to leave it as is. >>>>>>>> I also noticed an issue that was flagged in some other JNI code >>>>>>>> lately: >>>>>>>> >>>>>>>> 213 if (obj == NULL) { >>>>>>>> 214 free(dcmd_info_array); >>>>>>>> 215 JNU_ThrowOutOfMemoryError(env, 0); >>>>>>>> 216 return NULL; >>>>>>>> >>>>>>>> If obj == NULL then there is already a pending exception and we >>>>>>>> should not be throwing OOME. >>>>>>>> >>>>>>> Sure. This needs to be fixed. >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Harsha >>>>>>>>> >>>>>>> Harsha >>>>> >>>> >> From alexander.kulyakhtin at oracle.com Tue Aug 30 09:56:51 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 30 Aug 2016 02:56:51 -0700 (PDT) Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" Message-ID: Hi Sergey, Thank you very much for the review. I've submitted JDK-8165017 as you have suggested. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com Cc: christian.tornqvist at oracle.com, serviceability-dev at openjdk.java.net Sent: Monday, August 29, 2016 10:00:17 PM GMT +03:00 Iraq Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" Hi Alexander, It looks good. Thank you for the update! Please, file an enhancement CR on the additional test coverage for ClassLoader=2 and Module=19 commands. Thanks, Serguei On 8/29/16 05:29, Alexander Kulyakhtin wrote: Hi Sergey, Thank you very much for your help. With the changes, as you have proposed, the test now passes on all configurations. Please, find the updated webrev at: http://cr.openjdk.java.net/~akulyakh/8148103_03/ Regarding a more thorough verification of the Classloader command, I suggest submitting a new enhancement CR for that, so that the current test can be integrated while we are working on the enhancement. Best regards, Alexander ----- Original Message ----- From: serguei.spitsyn at oracle.com To: alexander.kulyakhtin at oracle.com , serviceability-dev at openjdk.java.net Cc: christian.tornqvist at oracle.com Sent: Friday, August 26, 2016 12:03:54 AM GMT +03:00 Iraq Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" Alexander, The fix is pretty good. Some comments besides the bug 8164490 we already discussed. test/serviceability/jdwp/AllModulesCommandTest.java 75 System.err.println("Could not launch the debuggee. Error: '" + line + "'"); A suggestion to replace "Error: " => Error at line: ". Otherwise, the line number will be confused with the error code. 81 // Etsablish JDWP socket connection A typo: Etsablish => Establish The verification in the assertClassLoader is pretty weak. It'd be nice to have more sophisticated verification. For instance, the following commands can be used for such verification: cmdset: ClassLoaderReference=14 , cmd: VisibleClasses=1 cmdset: ReferenceType=2, cmd: ClassLoader=2 cmdset: ReferenceType=2, cmd: Module=19 It is possible to iterate over all classes of the class loader to find at least one class with the given module and check if the class's class loader is the same as module's class loader. BTW, this would test the new jdwp command added for Jigsaw support: cmdset: ReferenceType=2, cmd: Module=19 But I leave it up to you as it looks unreasonably complicated. Maybe, you find a better approach. test/serviceability/jdwp/AllModulesCommandTestDebuggee.java 41 Set modNames = new HashSet<>(); 42 for (Module mod : Layer.boot().modules()) { 43 modNames.add(mod.getName()); 44 String info = String.format("module %s", mod.getName()); 45 write(info); 46 } The local modNames is not really used and can be removed (lines 41, 43). test/serviceability/jdwp/Arch.java It seems, this file/class is not really needed and can be removed. test/serviceability/jdwp/JdwpReply.java Nit: the empty lines 39 and 54 are not needed. Thanks, Serguei On 8/12/16 05:55, Alexander Kulyakhtin wrote: Hi, Could you, please, review the following test-only change (adding a new test): CR: https://bugs.openjdk.java.net/browse/JDK-8148103 Webrev: http://cr.openjdk.java.net/~akulyakh/8148103_02/ The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. When started the debuggee reports its loaded modules to the test. The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. Best regards, Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Aug 30 10:24:29 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Aug 2016 03:24:29 -0700 Subject: RFR:8148103:add more tests for task "Update JDI and JDWP for modules" In-Reply-To: References: Message-ID: <57C55EDD.30206@oracle.com> Hi Alexander, On 8/30/16 02:56, Alexander Kulyakhtin wrote: > Hi Sergey, > > Thank you very much for the review. I've submitted JDK-8165017 > as you have suggested. Ok, thanks! Is it enough to have one review for test enhancements? Also, do you have a sponsor for push? Thanks, Serguei > > Best regards, > Alexander > > ----- Original Message ----- > From: serguei.spitsyn at oracle.com > To: alexander.kulyakhtin at oracle.com > Cc: christian.tornqvist at oracle.com, serviceability-dev at openjdk.java.net > Sent: Monday, August 29, 2016 10:00:17 PM GMT +03:00 Iraq > Subject: Re: RFR:8148103:add more tests for task "Update JDI and JDWP > for modules" > > Hi Alexander, > > It looks good. > Thank you for the update! > > Please, file an enhancement CR on the additional test coverage > for ClassLoader=2 and Module=19 commands. > > Thanks, > Serguei > > > > On 8/29/16 05:29, Alexander Kulyakhtin wrote: > > Hi Sergey, > > Thank you very much for your help. With the changes, as you have > proposed, the test now passes on all configurations. > > Please, find the updated webrev at: > http://cr.openjdk.java.net/~akulyakh/8148103_03/ > > Regarding a more thorough verification of the Classloader command, > I suggest submitting a new enhancement CR for that, so that the > current test can be integrated while we are working on the > enhancement. > > Best regards, > Alexander > > > ----- Original Message ----- > From: serguei.spitsyn at oracle.com > To: alexander.kulyakhtin at oracle.com, > serviceability-dev at openjdk.java.net > Cc: christian.tornqvist at oracle.com > Sent: Friday, August 26, 2016 12:03:54 AM GMT +03:00 Iraq > Subject: Re: RFR:8148103:add more tests for task "Update JDI and > JDWP for modules" > > Alexander, > > The fix is pretty good. > > Some comments besides the bug 8164490 we already discussed. > > test/serviceability/jdwp/AllModulesCommandTest.java > > 75 System.err.println("Could not launch the debuggee. Error: '" + line + "'"); > > A suggestion to replace "Error: " => Error at line: ". > Otherwise, the line number will be confused with the error code. > > 81 // Etsablish JDWP socket connection > > A typo: Etsablish => Establish > > > The verification in the assertClassLoader is pretty weak. > It'd be nice to have more sophisticated verification. > For instance, the following commands can be used for such > verification: > cmdset: ClassLoaderReference=14 , cmd: VisibleClasses=1 > cmdset: ReferenceType=2, cmd: ClassLoader=2 > cmdset: ReferenceType=2, cmd: Module=19 > > It is possible to iterate over all classes of the class loader > to find > at least one class with the given module and check if the > class's class loader > is the same as module's class loader. > BTW, this would test the new jdwp command added for Jigsaw support: > cmdset: ReferenceType=2, cmd: Module=19 > > But I leave it up to you as it looks unreasonably complicated. > Maybe, you find a better approach. > > test/serviceability/jdwp/AllModulesCommandTestDebuggee.java > > 41 Set modNames = new HashSet<>(); > 42 for (Module mod : Layer.boot().modules()) { > 43 modNames.add(mod.getName()); > 44 String info = String.format("module %s", mod.getName()); > 45 write(info); > 46 } > > The local modNames is not really used and can be removed (lines > 41, 43). > > > test/serviceability/jdwp/Arch.java > > It seems, this file/class is not really needed and can be removed. > > > test/serviceability/jdwp/JdwpReply.java > > Nit: the empty lines 39 and 54 are not needed. > > > > Thanks, > Serguei > > > On 8/12/16 05:55, Alexander Kulyakhtin wrote: > > Hi, > > Could you, please, review the following test-only change (adding a new test): > > CR:https://bugs.openjdk.java.net/browse/JDK-8148103 > Webrev:http://cr.openjdk.java.net/~akulyakh/8148103_02/ > > The new test verifies the new JDWP commands: AllModules, Module, Name, ClassLoader, CanRead. > > It does so by launching a debuggee java program with the necessary JDWP-related options, so that a JDWP session can be established between the debuggee and the test. > > When started the debuggee reports its loaded modules to the test. > The test then initiates the JDWP session and issues AllModules command to get the modules info by means of the JDWP. > For each module the test issues Name command. It then verifies that the modules names reported via the JDWP are the same as reported by the debuggee using the Java API. > Additionally, for each module the test issues CanRead and Classloader commands and verifies that the corresponding replies are correct. > > Since all the previous JDWP tests were implemented using the deprecated closed test framework, the amount of the code for this test is slightly larger than usually for a single test. > The simple JDWP framework, created for this test, allows for porting the other JDWP tests to the jtreg in the same manner. > > Best regards, > Alexander > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kulyakhtin at oracle.com Tue Aug 30 10:38:51 2016 From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin) Date: Tue, 30 Aug 2016 03:38:51 -0700 (PDT) Subject: Fwd: RFR:8139368:-javaagent and -Dcom.sun.management need to add to the initial set of modules to resolve Message-ID: Hi, Could I, please, have some feedback on the RFR below (adding a new test for the -javaagent option)? Best regards, Alexander ----- Forwarded Message ----- From: alexander.kulyakhtin at oracle.com To: serviceability-dev at openjdk.java.net Cc: christian.tornqvist at oracle.com, alan.bateman at oracle.com Sent: Tuesday, August 9, 2016 2:28:38 PM GMT +03:00 Iraq Subject: RFR:8139368:-javaagent and -Dcom.sun.management need to add to the initial set of modules to resolve Hi, Could you, please, review this test-only change (adding a new test). CR: https://bugs.openjdk.java.net/browse/JDK-8139368 "-javaagent and -Dcom.sun.management need to add to the initial set of modules to resolve" Webrev: http://cr.openjdk.java.net/~akulyakh/8139368_01/ The new tests starts java with the -javaagent option at the same time limiting the initial modules not to include the java.instrument module. The test then verifies that java starts successfully and that both the agent and the application produce the expected output. The other part of the CR, related to the -Dcom.sun.management, is not addressed by this fix as it is being addressed by a separate CR JDK-8131061 Best regards, Alexander From amit.sapre at oracle.com Tue Aug 30 10:39:08 2016 From: amit.sapre at oracle.com (Amit Sapre) Date: Tue, 30 Aug 2016 03:39:08 -0700 (PDT) Subject: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module In-Reply-To: <9c512a1f-b440-6878-9c59-b87744867c99@oracle.com> References: <28eda504-3c5a-4763-b2ee-902c7b3a3dac@default> <6904b38e-e66c-4203-9f41-1ac6c9e61a69@default> <9c512a1f-b440-6878-9c59-b87744867c99@oracle.com> Message-ID: <252f96fc-e488-4486-81de-e8a1f3fdc0e5@default> Hello, Fixed the alignment problem as well. Here is the updated webrev. http://cr.openjdk.java.net/~jgeorge/sponsorships/8066635/webrev.02/ Thanks, Amit -----Original Message----- From: David Holmes Sent: Tuesday, August 30, 2016 11:44 AM To: Amit Sapre; serviceability-dev Subject: Re: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module On 30/08/2016 3:56 PM, Amit Sapre wrote: > Thanks David for your inputs. > I like to go the cleanup way and made changes accordingly. > The new webrev is > http://cr.openjdk.java.net/~jgeorge/sponsorships/8066635/webrev.01/ Looks good! Only nit is the argument alignment here: ! default public ObjectInputStream deserialize(String className, ObjectName loaderName, byte[] data) they should align with each other, after the ( Thanks, David > Thanks, > Amit > > -----Original Message----- > From: David Holmes > Sent: Wednesday, August 24, 2016 12:24 PM > To: Amit Sapre; serviceability-dev > Subject: Re: PING : RFR : JDK-8066635 - Fix deprecation warnings in > java.management module > > Hi Amit, > > On 24/08/2016 4:37 PM, Amit Sapre wrote: >> >> *From:*Amit Sapre >> *Sent:* Monday, August 22, 2016 2:39 PM >> *To:* serviceability-dev >> *Subject:* RFR : JDK-8066635 - Fix deprecation warnings in >> java.management module >> >> Hello, >> >> Please review changes for fixing deprecation warnings. >> >> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8066635 >> >> Webrev : >> http://cr.openjdk.java.net/~sballal/sponsorship/8066635/webrev.00/ > > Marking the methods @Deprecated fixes the problem. > > Another option would be converting the interface methods to default methods that throw the UnsupportOperationException and then delete them from the DefaultMBeanServerInterceptor class. > > Your call. If you leave as-is then consider this Reviewed. > > Thanks, > David > >> >> >> Amit >> From david.holmes at oracle.com Tue Aug 30 10:42:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Aug 2016 20:42:44 +1000 Subject: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module In-Reply-To: <252f96fc-e488-4486-81de-e8a1f3fdc0e5@default> References: <28eda504-3c5a-4763-b2ee-902c7b3a3dac@default> <6904b38e-e66c-4203-9f41-1ac6c9e61a69@default> <9c512a1f-b440-6878-9c59-b87744867c99@oracle.com> <252f96fc-e488-4486-81de-e8a1f3fdc0e5@default> Message-ID: <3103650b-e3b9-817e-222f-301aeddb53e7@oracle.com> On 30/08/2016 8:39 PM, Amit Sapre wrote: > Hello, > Fixed the alignment problem as well. Here is the updated webrev. > > http://cr.openjdk.java.net/~jgeorge/sponsorships/8066635/webrev.02/ Can you use the original style for this please. No need to see an updated webrev. Thanks, David > Thanks, > Amit > > > -----Original Message----- > From: David Holmes > Sent: Tuesday, August 30, 2016 11:44 AM > To: Amit Sapre; serviceability-dev > Subject: Re: PING : RFR : JDK-8066635 - Fix deprecation warnings in java.management module > > On 30/08/2016 3:56 PM, Amit Sapre wrote: >> Thanks David for your inputs. >> I like to go the cleanup way and made changes accordingly. >> The new webrev is >> http://cr.openjdk.java.net/~jgeorge/sponsorships/8066635/webrev.01/ > > Looks good! Only nit is the argument alignment here: > > ! default public ObjectInputStream deserialize(String className, > ObjectName loaderName, > byte[] data) > > they should align with each other, after the ( > > Thanks, > David > >> Thanks, >> Amit >> >> -----Original Message----- >> From: David Holmes >> Sent: Wednesday, August 24, 2016 12:24 PM >> To: Amit Sapre; serviceability-dev >> Subject: Re: PING : RFR : JDK-8066635 - Fix deprecation warnings in >> java.management module >> >> Hi Amit, >> >> On 24/08/2016 4:37 PM, Amit Sapre wrote: >>> >>> *From:*Amit Sapre >>> *Sent:* Monday, August 22, 2016 2:39 PM >>> *To:* serviceability-dev >>> *Subject:* RFR : JDK-8066635 - Fix deprecation warnings in >>> java.management module >>> >>> Hello, >>> >>> Please review changes for fixing deprecation warnings. >>> >>> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8066635 >>> >>> Webrev : >>> http://cr.openjdk.java.net/~sballal/sponsorship/8066635/webrev.00/ >> >> Marking the methods @Deprecated fixes the problem. >> >> Another option would be converting the interface methods to default methods that throw the UnsupportOperationException and then delete them from the DefaultMBeanServerInterceptor class. >> >> Your call. If you leave as-is then consider this Reviewed. >> >> Thanks, >> David >> >>> >>> >>> Amit >>> From mandy.chung at oracle.com Tue Aug 30 15:45:49 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 30 Aug 2016 08:45:49 -0700 Subject: RFR:(S): 8164562: serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE In-Reply-To: References: <1a0d53db-e3f3-45a5-8170-8b8a3e320a87@default> Message-ID: Thanks Alejandro. A minor correction - the patch is pushed to jdk9/hs/hotspot which is the right repo to fix this issue. I did a grep on jdk9/hs/hotspot/test and find no other test changes using the old CLI options. I have covered the necessary changes in jdk9/dev/hotspot/test in [1]. Mandy [1] http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160851/webrev.00/index.html > On Aug 29, 2016, at 11:40 PM, Alejandro Murillo wrote: > > Please push this to jdk9/dev after Mandy's change is in, > to make sure the fix work, and that is there by Thursday when I take the snapshot > otherwise there's not guarantee it will be part of the snapshot > > Thanks > Alejandro > > On 8/30/2016 12:15 AM, Jini Susan George wrote: >> Thank you, Mandy. Aiming at that. >> >> -jini. >> >>> -----Original Message----- >>> From: Mandy Chung >>> Sent: Tuesday, August 30, 2016 11:27 AM >>> To: Jini Susan George >>> Cc: David Holmes; serviceability-dev; Alejandro Murillo >>> Subject: Re: RFR:(S): 8164562: >>> serviceability/sa/TestInstanceKlassSizeForInterface.java: fails with NPE >>> >>> >>>> On Aug 29, 2016, at 12:51 AM, Jini Susan George >>> wrote: >>>> Hi David, >>>> >>>> Thank you for the review. I have added a few more asserts and uploaded a >>> modified webrev: >>>> http://cr.openjdk.java.net/~jgeorge/8164562/webrev.01/ >>> Looks okay. It?d be helpful if you can make sure your fix can push to jdk9/hs >>> and include in the next hs->dev push. Otherwise these tests without your fix >>> will fail in jdk9/dev since the old CLI option will be removed. >>> >>> thanks >>> Mandy >>> > > -- > Alejandro > From daniel.daugherty at oracle.com Tue Aug 30 20:17:08 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 30 Aug 2016 14:17:08 -0600 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <4219f24c-a1b6-d610-99d4-e242769be24a@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> <4219f24c-a1b6-d610-99d4-e242769be24a@oracle.com> Message-ID: <9703d269-f710-35ce-91ca-43665ea1ed39@oracle.com> On 8/29/16 8:51 PM, David Holmes wrote: > > > On 30/08/2016 9:08 AM, Daniel D. Daugherty wrote: >> On 8/23/16 6:17 AM, Harsha Wardhana B wrote: >>> Hi David, >>> >>> You approach to waiter object is a neat little abstraction and I will >>> make it a point to use it in future fixes, if required. >>> >>> revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ >> >> test/java/lang/management/ThreadMXBean/Locks.java >> General comment: >> 'synchronized(foo)' and 'synchronized (foo)' are both used. >> Please pick a style and use it consistently. >> >> L24: /* >> Space added before comment block begin. Please remove it. >> >> L76: /* >> L77: Handy debug function to check if error condition is because >> of test code or not. >> L78: */ >> Should look like this: >> >> L76: /* >> L77: * Handy debug function to check if error condition is >> because of test code or not. >> L78: */ >> >> That is standard block comment format. >> >> L114: /* >> L115: Do slow check if thread is blocked on a lock. It is >> possible that last thread >> L116: to come out of Phaser might still be in Phaser call stack >> (Unsfe.park) and >> L117: hence might eventually acquire expected lock. >> L118: */ >> Same comment about standard block comment format. >> >> Also typo: "Unsfe.park" -> "Unsafe.park". >> >> L129: while(p.test(result)){ >> Space before first '(' and before '{'. >> >> L171: // stop here for LockBThread to hold OBJB >> Perhaps this for the comment: >> // block here while LockBThread holds OBJB >> >> L208: /* >> L209: Must be invoked from within a Synchronized context >> L210: */ >> Same comment about standard block comment format. >> >> Also not sure why "Synchronized" is capitalized... >> >> L213: boolean isNotified = false; >> This should probably be volatile. >> >> Update: WaitingThread calls OBJC.doWait() and >> CheckerThread calls OBJC.doNotify(). Yup, it should >> be volatile. > > Nope - it is only accessed under synchronization lock, which must be > held by the caller else the wait()/notify() will throw > IllegalMonitorStateException. Yup. That occurred to me late last night... Sorry for the noise. Dan > > David > ----- > >> Dan >> >> >>> >>> On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >>>> Hi Harsha, >>>> >>>> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>>>> Hello, >>>>> >>>>> Please review the below webrev incorporating David's comments. >>>>> >>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >>>> >>>> Using a static isNotified field isn't exactly what I had in mind, I >>>> was thinking of something more encapsulated - something I thought >>>> already existed in other tests, but now I can't find it. Eg: >>>> >>>> /* synchronization helper for two-thread wait/notify interaction >>>> */ >>>> static class WaitObject { >>>> boolean isNotified = false; >>>> public void await() throws InterruptedException { >>>> while (!isNotified) >>>> wait(); >>>> isNotified = false; >>>> } >>>> public void doNotify() { >>>> isNotified = true; >>>> notify(); >>>> } >>>> } >>>> >>>> then OBJC would be a WaitObject and you would do: >>>> >>>> synchronized(OBJC) { >>>> log("WaitingThread about to wait on objC"); >>>> try { >>>> // Signal checker thread, about to wait on objC. >>>> waiting = false; >>>> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >>>> waiting = true; >>>> OBJC.doWait(); >>>> } catch (InterruptedException e) { >>>> ... >>>> >>>> etc. >>>> >>>> Minor nits: >>>> - why did you move the @library ? >>> It was suggested by NetBeans Jtreg plugin to fix tag order. >>>> - @Override, if used, should be applied consistently >>> Have applied the annotation consistently. >>>> - if you want to capitalize objA, objB, objC then ensure you also >>>> update it in the comments and log statements (it really isn't >>>> necessary to capitalize them, that is suggested for compile-time >>>> constants and these are not - they are just static final variables). >>> Done. >>> >>> Thanks >>> Harsha >>>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Regards >>>>> >>>>> Harsha >>>>> >>>>> >>>>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>>>> Hi David, >>>>>> >>>>>> I will incorporate changes suggested by you. Let's wait for few more >>>>>> review comments and then I will send consolidated webrev. >>>>>> >>>>>> Regards >>>>>> Harsha >>>>>> >>>>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Agreed that we could fix WaitingThread the way you have said, >>>>>>>> but in >>>>>>>> recent past, there aren't any issues reported w.r.t WaitingThread. >>>>>>> >>>>>>> Nor are there likely to be - that's what makes spurious wakeup bugs >>>>>>> so difficult to detect! >>>>>>> >>>>>>>> This test has been fixed several times (3-4) for intermittent >>>>>>>> failures >>>>>>>> and hence I would not like to meddle with code that is not >>>>>>>> causing any >>>>>>>> problems even though there is scope for refactoring. >>>>>>> >>>>>>> It isn't refactoring it is fixing and we have fixed several >>>>>>> tests in >>>>>>> a similar way. >>>>>>> >>>>>>>> The issue reported was with LockThreadB and hence I have provided >>>>>>>> possible fix for the same. >>>>>>> >>>>>>> That doesn't preclude fixing other issues with the test at the same >>>>>>> time. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> Harsha >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>>>> Hi Harsha, >>>>>>>>> >>>>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Please review and provide comments for fix for issue, >>>>>>>>>> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>>>> >>>>>>>>>> having webrev located at >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>>>> >>>>>>>>> These changes look quite good (though I have to admit I >>>>>>>>> struggle to >>>>>>>>> read the lambda and stream code :) ). >>>>>>>>> >>>>>>>>> Note that like many of these kinds of tests there is an issue >>>>>>>>> with >>>>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>>>> susceptible >>>>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>>>> variable and then do: >>>>>>>>> >>>>>>>>> while (!notified) >>>>>>>>> wait(); >>>>>>>>> >>>>>>>>> and set notified before the notify(). >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Fix details: >>>>>>>>>> >>>>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>>>>> wrong >>>>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>>>> thread is >>>>>>>>>> blocked on expected object. It is possible that LockThreadB >>>>>>>>>> might >>>>>>>>>> still >>>>>>>>>> be in Phaser call stack (Unsafe.park) when >>>>>>>>>> 'checkBlockedObject' is >>>>>>>>>> invoked. >>>>>>>>>> >>>>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>>>> being >>>>>>>>>> printed. >>>>>>>>>> >>>>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>>>> helps us >>>>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>>>> >>>>>>>>>> 4. Even though we had lock free logger, several >>>>>>>>>> ex.printStackTrace() was >>>>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>>>> >>>>>>>>>> 5. There were several places where tests continue to ran even >>>>>>>>>> after >>>>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>>>> >>>>>>>>>> 6. Couple of other minor refactoring. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Harsha >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >> From harsha.wardhana.b at oracle.com Wed Aug 31 08:20:16 2016 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Wed, 31 Aug 2016 13:50:16 +0530 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <9703d269-f710-35ce-91ca-43665ea1ed39@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> <4219f24c-a1b6-d610-99d4-e242769be24a@oracle.com> <9703d269-f710-35ce-91ca-43665ea1ed39@oracle.com> Message-ID: <77fc0355-54cd-414f-5859-65da709a14e0@oracle.com> Hello, Please review new webrev incorporating nits form Daniel. http://cr.openjdk.java.net/~hb/8152589/webrev.03/ -Harsha On Wednesday 31 August 2016 01:47 AM, Daniel D. Daugherty wrote: > On 8/29/16 8:51 PM, David Holmes wrote: >> >> >> On 30/08/2016 9:08 AM, Daniel D. Daugherty wrote: >>> On 8/23/16 6:17 AM, Harsha Wardhana B wrote: >>>> Hi David, >>>> >>>> You approach to waiter object is a neat little abstraction and I will >>>> make it a point to use it in future fixes, if required. >>>> >>>> revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ >>> >>> test/java/lang/management/ThreadMXBean/Locks.java >>> General comment: >>> 'synchronized(foo)' and 'synchronized (foo)' are both used. >>> Please pick a style and use it consistently. >>> >>> L24: /* >>> Space added before comment block begin. Please remove it. >>> >>> L76: /* >>> L77: Handy debug function to check if error condition is >>> because >>> of test code or not. >>> L78: */ >>> Should look like this: >>> >>> L76: /* >>> L77: * Handy debug function to check if error condition is >>> because of test code or not. >>> L78: */ >>> >>> That is standard block comment format. >>> >>> L114: /* >>> L115: Do slow check if thread is blocked on a lock. It is >>> possible that last thread >>> L116: to come out of Phaser might still be in Phaser call stack >>> (Unsfe.park) and >>> L117: hence might eventually acquire expected lock. >>> L118: */ >>> Same comment about standard block comment format. >>> >>> Also typo: "Unsfe.park" -> "Unsafe.park". >>> >>> L129: while(p.test(result)){ >>> Space before first '(' and before '{'. >>> >>> L171: // stop here for LockBThread to hold OBJB >>> Perhaps this for the comment: >>> // block here while LockBThread holds OBJB >>> >>> L208: /* >>> L209: Must be invoked from within a Synchronized context >>> L210: */ >>> Same comment about standard block comment format. >>> >>> Also not sure why "Synchronized" is capitalized... >>> >>> L213: boolean isNotified = false; >>> This should probably be volatile. >>> >>> Update: WaitingThread calls OBJC.doWait() and >>> CheckerThread calls OBJC.doNotify(). Yup, it should >>> be volatile. >> >> Nope - it is only accessed under synchronization lock, which must be >> held by the caller else the wait()/notify() will throw >> IllegalMonitorStateException. > > Yup. That occurred to me late last night... Sorry for the noise. > > Dan > > >> >> David >> ----- >> >>> Dan >>> >>> >>>> >>>> On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >>>>> Hi Harsha, >>>>> >>>>> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the below webrev incorporating David's comments. >>>>>> >>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >>>>> >>>>> Using a static isNotified field isn't exactly what I had in mind, I >>>>> was thinking of something more encapsulated - something I thought >>>>> already existed in other tests, but now I can't find it. Eg: >>>>> >>>>> /* synchronization helper for two-thread wait/notify interaction >>>>> */ >>>>> static class WaitObject { >>>>> boolean isNotified = false; >>>>> public void await() throws InterruptedException { >>>>> while (!isNotified) >>>>> wait(); >>>>> isNotified = false; >>>>> } >>>>> public void doNotify() { >>>>> isNotified = true; >>>>> notify(); >>>>> } >>>>> } >>>>> >>>>> then OBJC would be a WaitObject and you would do: >>>>> >>>>> synchronized(OBJC) { >>>>> log("WaitingThread about to wait on objC"); >>>>> try { >>>>> // Signal checker thread, about to wait on objC. >>>>> waiting = false; >>>>> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >>>>> waiting = true; >>>>> OBJC.doWait(); >>>>> } catch (InterruptedException e) { >>>>> ... >>>>> >>>>> etc. >>>>> >>>>> Minor nits: >>>>> - why did you move the @library ? >>>> It was suggested by NetBeans Jtreg plugin to fix tag order. >>>>> - @Override, if used, should be applied consistently >>>> Have applied the annotation consistently. >>>>> - if you want to capitalize objA, objB, objC then ensure you also >>>>> update it in the comments and log statements (it really isn't >>>>> necessary to capitalize them, that is suggested for compile-time >>>>> constants and these are not - they are just static final variables). >>>> Done. >>>> >>>> Thanks >>>> Harsha >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Regards >>>>>> >>>>>> Harsha >>>>>> >>>>>> >>>>>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I will incorporate changes suggested by you. Let's wait for few >>>>>>> more >>>>>>> review comments and then I will send consolidated webrev. >>>>>>> >>>>>>> Regards >>>>>>> Harsha >>>>>>> >>>>>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Agreed that we could fix WaitingThread the way you have said, >>>>>>>>> but in >>>>>>>>> recent past, there aren't any issues reported w.r.t >>>>>>>>> WaitingThread. >>>>>>>> >>>>>>>> Nor are there likely to be - that's what makes spurious wakeup >>>>>>>> bugs >>>>>>>> so difficult to detect! >>>>>>>> >>>>>>>>> This test has been fixed several times (3-4) for intermittent >>>>>>>>> failures >>>>>>>>> and hence I would not like to meddle with code that is not >>>>>>>>> causing any >>>>>>>>> problems even though there is scope for refactoring. >>>>>>>> >>>>>>>> It isn't refactoring it is fixing and we have fixed several >>>>>>>> tests in >>>>>>>> a similar way. >>>>>>>> >>>>>>>>> The issue reported was with LockThreadB and hence I have provided >>>>>>>>> possible fix for the same. >>>>>>>> >>>>>>>> That doesn't preclude fixing other issues with the test at the >>>>>>>> same >>>>>>>> time. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Harsha >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>>>>> Hi Harsha, >>>>>>>>>> >>>>>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Please review and provide comments for fix for issue, >>>>>>>>>>> >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>>>>> >>>>>>>>>>> having webrev located at >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>>>>> >>>>>>>>>> These changes look quite good (though I have to admit I >>>>>>>>>> struggle to >>>>>>>>>> read the lambda and stream code :) ). >>>>>>>>>> >>>>>>>>>> Note that like many of these kinds of tests there is an issue >>>>>>>>>> with >>>>>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>>>>> susceptible >>>>>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>>>>> variable and then do: >>>>>>>>>> >>>>>>>>>> while (!notified) >>>>>>>>>> wait(); >>>>>>>>>> >>>>>>>>>> and set notified before the notify(). >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Fix details: >>>>>>>>>>> >>>>>>>>>>> 1. From nightly failures we see that LockThreadB was blocked on >>>>>>>>>>> wrong >>>>>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>>>>> thread is >>>>>>>>>>> blocked on expected object. It is possible that LockThreadB >>>>>>>>>>> might >>>>>>>>>>> still >>>>>>>>>>> be in Phaser call stack (Unsafe.park) when >>>>>>>>>>> 'checkBlockedObject' is >>>>>>>>>>> invoked. >>>>>>>>>>> >>>>>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>>>>> being >>>>>>>>>>> printed. >>>>>>>>>>> >>>>>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>>>>> helps us >>>>>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>>>>> >>>>>>>>>>> 4. Even though we had lock free logger, several >>>>>>>>>>> ex.printStackTrace() was >>>>>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>>>>> >>>>>>>>>>> 5. There were several places where tests continue to ran even >>>>>>>>>>> after >>>>>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>>>>> >>>>>>>>>>> 6. Couple of other minor refactoring. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> Harsha >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>> >>> > From Alan.Burlison at oracle.com Wed Aug 31 12:51:16 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 31 Aug 2016 13:51:16 +0100 Subject: jhsdb jstack cannot work correctly In-Reply-To: <0710b0b3-0783-4733-a04c-36555b244d3d@default> References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> <57A34253.1080409@gmail.com> <0710b0b3-0783-4733-a04c-36555b244d3d@default> Message-ID: On 04/08/2016 14:57, Arvind Aprameya wrote: > Hi Yasumasa, > We already have a bug filed for this one JDK-8163143 . Is https://bugs.openjdk.java.net/browse/JDK-8164383 a dup of this? -- Alan Burlison -- From jini.george at oracle.com Wed Aug 31 13:35:08 2016 From: jini.george at oracle.com (Jini Susan George) Date: Wed, 31 Aug 2016 06:35:08 -0700 (PDT) Subject: jhsdb jstack cannot work correctly In-Reply-To: References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> <57A34253.1080409@gmail.com> <0710b0b3-0783-4733-a04c-36555b244d3d@default> Message-ID: Alan, this looks like a dup of https://bugs.openjdk.java.net/browse/JDK-8164802. - jini. > -----Original Message----- > From: Alan Burlison > Sent: Wednesday, August 31, 2016 6:21 PM > To: Arvind Aprameya; Yasumasa Suenaga; serviceability- > dev at openjdk.java.net > Subject: Re: jhsdb jstack cannot work correctly > > On 04/08/2016 14:57, Arvind Aprameya wrote: > > > Hi Yasumasa, > > We already have a bug filed for this one JDK-8163143 . > > Is https://bugs.openjdk.java.net/browse/JDK-8164383 a dup of this? > > -- > Alan Burlison > -- From yasuenag at gmail.com Wed Aug 31 13:39:06 2016 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 31 Aug 2016 22:39:06 +0900 Subject: jhsdb jstack cannot work correctly In-Reply-To: References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> <57A34253.1080409@gmail.com> <0710b0b3-0783-4733-a04c-36555b244d3d@default> Message-ID: Hi Alan, IMHO, I think JDK-8164383 is different from my report. It seems to be a problem for finding symbols in Solaris platform. Yasumasa On 2016/08/31 21:51, Alan Burlison wrote: > On 04/08/2016 14:57, Arvind Aprameya wrote: > >> Hi Yasumasa, >> We already have a bug filed for this one JDK-8163143 . > > Is https://bugs.openjdk.java.net/browse/JDK-8164383 a dup of this? > From Alan.Burlison at oracle.com Wed Aug 31 16:36:09 2016 From: Alan.Burlison at oracle.com (Alan Burlison) Date: Wed, 31 Aug 2016 17:36:09 +0100 Subject: jhsdb jstack cannot work correctly In-Reply-To: References: <30331bf1-1cf6-d705-48a7-dc78809b0099@gmail.com> <57A34253.1080409@gmail.com> <0710b0b3-0783-4733-a04c-36555b244d3d@default> Message-ID: <5e455280-bfec-48ea-67d5-7dc4f2e6355c@oracle.com> On 31/08/2016 14:35, Jini Susan George wrote: > Alan, this looks like a dup of https://bugs.openjdk.java.net/browse/JDK-8164802. OK thanks, I've linked the two bugs. -- Alan Burlison -- From daniel.daugherty at oracle.com Wed Aug 31 18:03:55 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 31 Aug 2016 12:03:55 -0600 Subject: RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object In-Reply-To: <77fc0355-54cd-414f-5859-65da709a14e0@oracle.com> References: <98998d12-211a-73a2-e091-094bfc08a89e@oracle.com> <3e7f1f24-5010-6f89-6966-d612657f0186@oracle.com> <7efec61c-8d07-54c1-ea54-f6550252bbaf@oracle.com> <93ce2a00-2de5-6207-20f4-f4d009597885@oracle.com> <55e9fb83-68da-3ee4-74d7-9ea829c4cdd2@oracle.com> <06ed88cc-7adf-8c9d-78c0-bf531d66ac4b@oracle.com> <0b8c52b1-0c17-30d0-befc-6aa36e10cbd6@oracle.com> <16cd10c4-ceb5-abf5-204b-1884c2bb995c@oracle.com> <4219f24c-a1b6-d610-99d4-e242769be24a@oracle.com> <9703d269-f710-35ce-91ca-43665ea1ed39@oracle.com> <77fc0355-54cd-414f-5859-65da709a14e0@oracle.com> Message-ID: On 8/31/16 2:20 AM, Harsha Wardhana B wrote: > Hello, > > Please review new webrev incorporating nits form Daniel. > > http://cr.openjdk.java.net/~hb/8152589/webrev.03/ Replies below. > > -Harsha > > On Wednesday 31 August 2016 01:47 AM, Daniel D. Daugherty wrote: >> On 8/29/16 8:51 PM, David Holmes wrote: >>> >>> >>> On 30/08/2016 9:08 AM, Daniel D. Daugherty wrote: >>>> On 8/23/16 6:17 AM, Harsha Wardhana B wrote: >>>>> Hi David, >>>>> >>>>> You approach to waiter object is a neat little abstraction and I will >>>>> make it a point to use it in future fixes, if required. >>>>> >>>>> revised webrev : http://cr.openjdk.java.net/~hb/8152589/webrev.02/ >>>> >>>> test/java/lang/management/ThreadMXBean/Locks.java >>>> General comment: >>>> 'synchronized(foo)' and 'synchronized (foo)' are both used. >>>> Please pick a style and use it consistently. >>>> >>>> L24: /* >>>> Space added before comment block begin. Please remove it. This one is not fixed. >>>> >>>> L76: /* >>>> L77: Handy debug function to check if error condition is >>>> because >>>> of test code or not. >>>> L78: */ >>>> Should look like this: >>>> >>>> L76: /* >>>> L77: * Handy debug function to check if error >>>> condition is >>>> because of test code or not. >>>> L78: */ This one is not fixed the way I requested. All the '*' should line up. >>>> >>>> That is standard block comment format. >>>> >>>> L114: /* >>>> L115: Do slow check if thread is blocked on a lock. It is >>>> possible that last thread >>>> L116: to come out of Phaser might still be in Phaser call >>>> stack >>>> (Unsfe.park) and >>>> L117: hence might eventually acquire expected lock. >>>> L118: */ >>>> Same comment about standard block comment format. This one is not fixed the way I requested. All the '*' should line up. >>>> >>>> Also typo: "Unsfe.park" -> "Unsafe.park". >>>> >>>> L129: while(p.test(result)){ >>>> Space before first '(' and before '{'. >>>> >>>> L171: // stop here for LockBThread to hold OBJB >>>> Perhaps this for the comment: >>>> // block here while LockBThread holds OBJB Partially fixed. This: // block here for LockBThread to hold OBJB should be rewritten as: // block here while LockBThread holds OBJB which makes it more clear that LockAThread is blocking on OBJB while LockBThread holds that lock. >>>> >>>> L208: /* >>>> L209: Must be invoked from within a Synchronized context >>>> L210: */ >>>> Same comment about standard block comment format. This one is not fixed the way I requested. All the '*' should line up. Dan >>>> >>>> Also not sure why "Synchronized" is capitalized... >>>> >>>> L213: boolean isNotified = false; >>>> This should probably be volatile. >>>> >>>> Update: WaitingThread calls OBJC.doWait() and >>>> CheckerThread calls OBJC.doNotify(). Yup, it should >>>> be volatile. >>> >>> Nope - it is only accessed under synchronization lock, which must be >>> held by the caller else the wait()/notify() will throw >>> IllegalMonitorStateException. >> >> Yup. That occurred to me late last night... Sorry for the noise. >> >> Dan >> >> >>> >>> David >>> ----- >>> >>>> Dan >>>> >>>> >>>>> >>>>> On Tuesday 23 August 2016 11:47 AM, David Holmes wrote: >>>>>> Hi Harsha, >>>>>> >>>>>> On 22/08/2016 6:48 PM, Harsha Wardhana B wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review the below webrev incorporating David's comments. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.01/ >>>>>> >>>>>> Using a static isNotified field isn't exactly what I had in mind, I >>>>>> was thinking of something more encapsulated - something I thought >>>>>> already existed in other tests, but now I can't find it. Eg: >>>>>> >>>>>> /* synchronization helper for two-thread wait/notify interaction >>>>>> */ >>>>>> static class WaitObject { >>>>>> boolean isNotified = false; >>>>>> public void await() throws InterruptedException { >>>>>> while (!isNotified) >>>>>> wait(); >>>>>> isNotified = false; >>>>>> } >>>>>> public void doNotify() { >>>>>> isNotified = true; >>>>>> notify(); >>>>>> } >>>>>> } >>>>>> >>>>>> then OBJC would be a WaitObject and you would do: >>>>>> >>>>>> synchronized(OBJC) { >>>>>> log("WaitingThread about to wait on objC"); >>>>>> try { >>>>>> // Signal checker thread, about to wait on objC. >>>>>> waiting = false; >>>>>> p.arriveAndAwaitAdvance(); // Phase 1 (waiting) >>>>>> waiting = true; >>>>>> OBJC.doWait(); >>>>>> } catch (InterruptedException e) { >>>>>> ... >>>>>> >>>>>> etc. >>>>>> >>>>>> Minor nits: >>>>>> - why did you move the @library ? >>>>> It was suggested by NetBeans Jtreg plugin to fix tag order. >>>>>> - @Override, if used, should be applied consistently >>>>> Have applied the annotation consistently. >>>>>> - if you want to capitalize objA, objB, objC then ensure you also >>>>>> update it in the comments and log statements (it really isn't >>>>>> necessary to capitalize them, that is suggested for compile-time >>>>>> constants and these are not - they are just static final variables). >>>>> Done. >>>>> >>>>> Thanks >>>>> Harsha >>>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Regards >>>>>>> >>>>>>> Harsha >>>>>>> >>>>>>> >>>>>>> On Wednesday 17 August 2016 11:45 AM, Harsha Wardhana B wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I will incorporate changes suggested by you. Let's wait for few >>>>>>>> more >>>>>>>> review comments and then I will send consolidated webrev. >>>>>>>> >>>>>>>> Regards >>>>>>>> Harsha >>>>>>>> >>>>>>>> On Wednesday 17 August 2016 09:02 AM, David Holmes wrote: >>>>>>>>> On 16/08/2016 11:33 PM, Harsha Wardhana B wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Agreed that we could fix WaitingThread the way you have said, >>>>>>>>>> but in >>>>>>>>>> recent past, there aren't any issues reported w.r.t >>>>>>>>>> WaitingThread. >>>>>>>>> >>>>>>>>> Nor are there likely to be - that's what makes spurious wakeup >>>>>>>>> bugs >>>>>>>>> so difficult to detect! >>>>>>>>> >>>>>>>>>> This test has been fixed several times (3-4) for intermittent >>>>>>>>>> failures >>>>>>>>>> and hence I would not like to meddle with code that is not >>>>>>>>>> causing any >>>>>>>>>> problems even though there is scope for refactoring. >>>>>>>>> >>>>>>>>> It isn't refactoring it is fixing and we have fixed several >>>>>>>>> tests in >>>>>>>>> a similar way. >>>>>>>>> >>>>>>>>>> The issue reported was with LockThreadB and hence I have >>>>>>>>>> provided >>>>>>>>>> possible fix for the same. >>>>>>>>> >>>>>>>>> That doesn't preclude fixing other issues with the test at the >>>>>>>>> same >>>>>>>>> time. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> Harsha >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tuesday 16 August 2016 01:32 PM, David Holmes wrote: >>>>>>>>>>> Hi Harsha, >>>>>>>>>>> >>>>>>>>>>> On 16/08/2016 4:08 PM, Harsha Wardhana B wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Please review and provide comments for fix for issue, >>>>>>>>>>>> >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8152589 >>>>>>>>>>>> >>>>>>>>>>>> having webrev located at >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~hb/8152589/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> These changes look quite good (though I have to admit I >>>>>>>>>>> struggle to >>>>>>>>>>> read the lambda and stream code :) ). >>>>>>>>>>> >>>>>>>>>>> Note that like many of these kinds of tests there is an >>>>>>>>>>> issue with >>>>>>>>>>> WaitingThread because it does not wait in a loop and so is >>>>>>>>>>> susceptible >>>>>>>>>>> to spurious wakeups. The way to fix that is to add a "notified" >>>>>>>>>>> variable and then do: >>>>>>>>>>> >>>>>>>>>>> while (!notified) >>>>>>>>>>> wait(); >>>>>>>>>>> >>>>>>>>>>> and set notified before the notify(). >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Fix details: >>>>>>>>>>>> >>>>>>>>>>>> 1. From nightly failures we see that LockThreadB was >>>>>>>>>>>> blocked on >>>>>>>>>>>> wrong >>>>>>>>>>>> object. We now do a repeated check with timeout if any given >>>>>>>>>>>> thread is >>>>>>>>>>>> blocked on expected object. It is possible that LockThreadB >>>>>>>>>>>> might >>>>>>>>>>>> still >>>>>>>>>>>> be in Phaser call stack (Unsafe.park) when >>>>>>>>>>>> 'checkBlockedObject' is >>>>>>>>>>>> invoked. >>>>>>>>>>>> >>>>>>>>>>>> 2. The logs from lock free logger was never printed. It is not >>>>>>>>>>>> being >>>>>>>>>>>> printed. >>>>>>>>>>>> >>>>>>>>>>>> 3. Any time we see failure, thread stack is being logged. This >>>>>>>>>>>> helps us >>>>>>>>>>>> ascertain if failure is in test case or in the component. >>>>>>>>>>>> >>>>>>>>>>>> 4. Even though we had lock free logger, several >>>>>>>>>>>> ex.printStackTrace() was >>>>>>>>>>>> used which could be responsible for failure. It is removed. >>>>>>>>>>>> >>>>>>>>>>>> 5. There were several places where tests continue to ran even >>>>>>>>>>>> after >>>>>>>>>>>> failure (testFailed flag). That is fixed. >>>>>>>>>>>> >>>>>>>>>>>> 6. Couple of other minor refactoring. >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> >>>>>>>>>>>> Harsha >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> >