From jonathan.gibbons at oracle.com Mon Oct 1 14:56:56 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 1 Oct 2018 07:56:56 -0700 Subject: Infinite loop in jdk/test/sun/management/windows/revokeall In-Reply-To: References: Message-ID: <5b29307d-903d-190d-c074-7be5955910ea@oracle.com> I'm guessing serviceability-dev is a better place for this message. -- Jon On 10/1/18 5:44 AM, Ladislav Jahoda wrote: > Hello guys, > the revokeall utility has an infinite loop in its revokeAll method. > Please note in the loop (line #344 in revokeall.c): > while (count > 0) { > the condition (line #354): > if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != > ACCESS_ALLOWED_ACE_TYPE) { > ???? continue; > } > which loops forever if the condition is met. Note that the ?count? > counter needs to be decremented before the continue statement, that is: > if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != > ACCESS_ALLOWED_ACE_TYPE) { > ???? count--; > ???? continue; > } > I checked the OpenJDK 8, 9 and 10, the bug is in all versions. > Thanks ahead for the fix, > Lada Jahoda > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Oct 1 16:43:08 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 1 Oct 2018 18:43:08 +0200 Subject: Infinite loop in jdk/test/sun/management/windows/revokeall In-Reply-To: <5b29307d-903d-190d-c074-7be5955910ea@oracle.com> References: <5b29307d-903d-190d-c074-7be5955910ea@oracle.com> Message-ID: Hi, Should we not be also incrementing i to get the next Ace? Otherwise, we are always getting the same one and probably just waiting till the count is 0 which would terminate the loop (if that is what we want, why not just break?). Thanks, Jc On Mon, Oct 1, 2018 at 4:57 PM Jonathan Gibbons wrote: > I'm guessing serviceability-dev is a better place for this message. > > -- Jon > > > On 10/1/18 5:44 AM, Ladislav Jahoda wrote: > > Hello guys, > > the revokeall utility has an infinite loop in its revokeAll method. Please > note in the loop (line #344 in revokeall.c): > > while (count > 0) { > > the condition (line #354): > > if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != > ACCESS_ALLOWED_ACE_TYPE) { > continue; > } > > which loops forever if the condition is met. Note that the ?count? counter > needs to be decremented before the continue statement, that is: > > if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != > ACCESS_ALLOWED_ACE_TYPE) { > count--; > continue; > } > > I checked the OpenJDK 8, 9 and 10, the bug is in all versions. > > Thanks ahead for the fix, > Lada Jahoda > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Oct 1 16:50:26 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 1 Oct 2018 18:50:26 +0200 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* In-Reply-To: <2521fc07-1ce2-dd35-1e6e-a5fbfe786888@oracle.com> References: <2521fc07-1ce2-dd35-1e6e-a5fbfe786888@oracle.com> Message-ID: Hi Chris, Thanks for the review! I think most of your comments are/should be future items, I inlined my answers: On Fri, Sep 28, 2018 at 7:49 PM Chris Plummer wrote: > Hi JC, > > In addition to Alex's ForceEarlyReturn001.cpp comment: > > There are many places where I see a space between two parens at the end > of the line. For example, in attach020Agent00.cpp: > > 168 if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps)) ) { > > I saw that too, that will disappear when I remove the NSK_JVMTI_VERIFY altogether. These spaces were there before so I did not want to try to fix them in this fix-up round since anyway we were going to touch these lines again anyway. I looked and there are a lot of these across the vmTestbase folders. I created this bug to track it: https://bugs.openjdk.java.net/browse/JDK-8211335 (To be honest, every time I look a bit at the lines fixed right now, I see things around I'm itching to fix next but I strive to keep the transformation simple). > Every place NSK_JNI_VERIFY is used there is ugliness with "if" > expressions involving JNI results that are not already boolean. Besides > a boolean being computed for the JNI result, often there is also an > assignment to the JNI result. I'm not sure if you have plans to clean > stuff like this up, but it would be best to always do the assignment > first, even if currently there is no local variable being assigned to. > It would simplify the boolean expression being passed to NSK_JNI_VERIFY. > Here's one example: > > 137 if (!NSK_JNI_VERIFY(jni, (array = (jbyteArray) > 138 jni->GetStaticObjectField(cls, fieldID)) != NULL)) { > > This would be much better: > > 137 array = (jbyteArray)jni->GetStaticObjectField(cls, fieldID); > 138 if (!NSK_JNI_VERIFY(jni, array != NULL) { > > I already have this on my future plate: https://bugs.openjdk.java.net/browse/JDK-8210922 attach015Target.cpp: use of ?: is not needed and it should be explicitly > checking if FindClass is NULL. > > 40 return jni->FindClass(LOADED_CLASS_NAME) ? JNI_TRUE : JNI_FALSE; > > For this, I saw a conversation in hotspot ( http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/033828.html) saying we have to be careful here. I think returning != 0 will work, right? If so, I'll create a bug to fix all of these up. > attach022Agent00.cpp: The empty line 88 and 141 should be removed. Also > extra space near the end of the line: > Done for the lines and the white space at the end of the line. Basically, my ordering of refactoring would be if the reviewers agree: - Remove the NSK_CPP_STUB* (which is what these refactoring to do) - Remove the NSK_*_VERIFY macros at which point I'll remove that space you saw for NSK_*_VERIFY lines; that will remove the ) in the lines - Move out the assignments - Remove the remaining spaces before a ) for l Let me know what you think, Jc > thanks, > > Chris > > On 9/27/18 10:15 PM, JC Beyler wrote: > > Hi all, > > > > I continued the NSK_CPP_STUB removal with this webrev: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 > > > > This does the another set of 50 files of the jvmti subfolder, it is > > done automatically by the scripts I put in the bug comments. > > > > This passes the tests changed on my dev machine. > > > > Let me know what you think, > > Jc > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Oct 1 17:16:28 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 1 Oct 2018 10:16:28 -0700 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* In-Reply-To: References: <2cd251ec-61df-b701-a9f2-a75efb2c732a@oracle.com> Message-ID: <403d57ef-d65e-2833-6142-3cce89ef2a21@oracle.com> LGTM --alex On 09/28/2018 19:44, JC Beyler wrote: > Hi Alex, > > Thanks for the review and nice catch. I updated my scripts and now fix > that corner case. Here is the incremental webrev that fixes a few more > white space issues: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00_01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 > > The full webrev is here: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 > > Let me know what you think, > Jc > > On Fri, Sep 28, 2018 at 10:20 AM Alex Menkov > wrote: > > Hi Jc, > > Overall looks good. > Could you please update > ForceEarlyReturn/ForceEarlyReturn001/ForceEarlyReturn001.cpp manually - > converted calls contain a lot of unnecessary spaces. > > --alex > > On 09/27/2018 22:15, JC Beyler wrote: > > Hi all, > > > > I continued the NSK_CPP_STUB removal with this webrev: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 > > > > This does the another set of 50 files of the jvmti subfolder, it > is done > > automatically by the scripts I put in the bug comments. > > > > This passes the tests changed on my dev machine. > > > > Let me know what you think, > > Jc > > > > -- > > Thanks, > Jc From chris.plummer at oracle.com Mon Oct 1 18:59:12 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Oct 2018 11:59:12 -0700 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* In-Reply-To: References: <2521fc07-1ce2-dd35-1e6e-a5fbfe786888@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Oct 1 22:17:16 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Oct 2018 15:17:16 -0700 Subject: RFR JDK-8203928: [Test] Convert non-JDB scaffolding serviceability shell script tests to java In-Reply-To: References: Message-ID: <4af0ff73-082c-db17-33f5-6b3e7f543e0e@oracle.com> Hi Alex, Looks good. thanks, Chris On 9/27/18 2:32 PM, Alex Menkov wrote: > Hi all, > > please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8203928 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/non-jdb/webrev.01/ > > Some details: > > ImmutableResourceTest.java > ? - required compile/run args are specified by using jtreg tag options; > > JITDebug.java > ? - was not able to reproduce failures described (looks like that it's > something ancient). Actually we use dt_socket transport on Windows for > a long time without any issues; > ? - replaced Runtime.exec with ProcessBuilder, used some /test/lib > stuff, fixed some minor issues; > > connect/spi/JdiLoadedByCustomLoader.java > redefine/RedefineTest.java > redefineMethod/RedefineTest.java > ? - implemented compilation tasks in java, removed shell files; > > PrivateTransportTest.java (was > test/jdk/com/sun/jdi/PrivateTransportTest.sh) > ? - just converted the test from shell to java. > > --alex From alexey.menkov at oracle.com Tue Oct 2 00:55:57 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 1 Oct 2018 17:55:57 -0700 Subject: RFR (M) 8211131: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[G-I]* In-Reply-To: References: Message-ID: <0be9bef2-6052-0768-fb9b-57ae43baff7c@oracle.com> Hi Jc, Looking at your conversion script I expected things like if (!NSK_JVMTI_VERIFY( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { to be converted to if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps))) { (then the final string is shorter than 100 symbols) But actually I see if (!NSK_JVMTI_VERIFY( - NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { + jvmti->AddCapabilities(&caps))) { --alex On 09/26/2018 20:37, JC Beyler wrote: > Hi all, > > I continued the NSK_CPP_STUB removal with this webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 > > This does the first 50 files of the jvmti subfolder, it is done > automatically by the scripts I put in the bug comments. > > Let me know what you think, > Jc From serguei.spitsyn at oracle.com Tue Oct 2 05:50:30 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 1 Oct 2018 22:50:30 -0700 Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: <93151a49-fa0d-4690-9ea4-b7c4879b17e3@default> References: <6aa3ffd4-f332-472a-8102-6d8f06f1d273@default> <457eb3cc-0d46-1c95-da87-594882056d92@oracle.com> <1c69df87-ee80-286b-9611-cbb9b9bebb55@oracle.com> <93151a49-fa0d-4690-9ea4-b7c4879b17e3@default> Message-ID: <06fe00fd-cf1b-ea17-00b4-c9b885ca0c8a@oracle.com> Hi Fairoz, It looks good to me. Thanks, Serguei On 9/27/18 10:10 PM, Fairoz Matte wrote: > Hi Jini, thanks for the review. May I get one more review for this? > > Thanks, > Fairoz > >> -----Original Message----- >> From: Jini George >> Sent: Friday, September 28, 2018 10:37 AM >> To: Fairoz Matte ; serviceability- >> dev at openjdk.java.net >> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 >> when loading dumped core >> >> This looks good to me, Fairoz. >> >> Thanks, >> Jini. >> >> On 9/26/2018 1:37 PM, Fairoz Matte wrote: >>> Hi Jini, >>> >>> Thanks for pointing out that, yes we cannot make that cleanup for JDK8. >>> Keeping it very simple and taking only changes required to fix >>> JDK-8164383 http://cr.openjdk.java.net/~fmatte/8164383/webrev.02/ >>> >>> I have verified running "test/serviceability/sa/jmap- >> hashcode/Test8028623.java" test case (found from one of the duplicate issue >> of JDK-8164383). >>> Results are as expected before and after the patch on Solaris 12 and Solaris >> 10. >>> Along with that, I have verified with Internal testing and found no >>> issues >>> >>> Thanks, >>> Fairoz >>> >>>> -----Original Message----- >>>> From: Jini George >>>> Sent: Tuesday, September 25, 2018 3:48 PM >>>> To: Fairoz Matte ; serviceability- >>>> dev at openjdk.java.net >>>> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on >>>> Solaris 12 when loading dumped core >>>> >>>> Hi Fairoz, >>>> >>>> I took a better look at the changes and I realized that the cleanup >>>> related to SOLARIS_11_B159_OR_LATER would be valid for only JDK9 and >>>> later. Since >>>> JDK8 is supported for Solaris 10 too, I believe that the cleanup >>>> related changes done as a part of JDK-8164383 should not be done for >> JDK-8. >>>> Thanks! >>>> Jini. >>>> >>>> On 9/24/2018 7:21 PM, Fairoz Matte wrote: >>>>> Hi Jini, >>>>> >>>>>> -----Original Message----- >>>>>> From: Jini George >>>>>> Sent: Friday, September 21, 2018 4:07 PM >>>>>> To: Fairoz Matte ; serviceability- >>>>>> dev at openjdk.java.net >>>>>> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on >>>>>> Solaris 12 when loading dumped core >>>>>> >>>>>> Hi Fairoz, >>>>>> >>>>>> This looks good to me. One nit which got missed out in the original >>>>>> change also is that in saproc.cpp, the following comments >>>>>> >>>>>> 452 >>>>>> 453 // Pstack_iter() proc_stack_f callback prior to Nevada-B159 >>>>>> >>>>>> 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later >>>>>> 477 /*ARGSUSED*/ >>>>>> >>>>> I have incorporated above changes >>>>> >>>>>> would not be required anymore. And we would not need the wrapper >> to >>>>>> the callback routine fill_cframe_list() -- as in, we would need >>>>>> only one routine with the appropriate arguments passed. But you are >>>>>> free to ignore this since this was not done as a part of the original >> change. >>>>> Removed wrapper_fill_cframe_list function and fill_cframe_list >>>>> function >>>> has been used directly. >>>>> Please find the updated webrev >>>>> http://cr.openjdk.java.net/~fmatte/8164383/webrev.01/ >>>>> >>>>> Thanks, >>>>> Fairoz >>>>> >>>>>> Thanks, >>>>>> Jini (Not a Reviewer). >>>>>> >>>>>> >>>>>> >>>>>> On 9/20/2018 7:06 PM, Fairoz Matte wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Kindly review the backport of "JDK-8164383 : jhsdb dumps core on >>>>>>> Solaris 12 when loading dumped core" to 8u >>>>>>> >>>>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ >>>>>>> >>>>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 >>>>>>> >>>>>>> JDK9 changeset - >>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 >>>>>>> >>>>>>> JDK9 review thread - >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-Oct >>>>>>> ob >>>>>>> er >>>>>>> /020543.html >>>>>>> >>>>>>> Thanks, >>>>>>> Fairoz >>>>>>> From fairoz.matte at oracle.com Tue Oct 2 05:56:31 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Mon, 1 Oct 2018 22:56:31 -0700 (PDT) Subject: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 when loading dumped core In-Reply-To: <06fe00fd-cf1b-ea17-00b4-c9b885ca0c8a@oracle.com> References: <6aa3ffd4-f332-472a-8102-6d8f06f1d273@default> <457eb3cc-0d46-1c95-da87-594882056d92@oracle.com> <1c69df87-ee80-286b-9611-cbb9b9bebb55@oracle.com> <93151a49-fa0d-4690-9ea4-b7c4879b17e3@default> <06fe00fd-cf1b-ea17-00b4-c9b885ca0c8a@oracle.com> Message-ID: Hi Serguei, Thanks for the review. Thanks, Fairoz > -----Original Message----- > From: Serguei Spitsyn > Sent: Tuesday, October 02, 2018 11:21 AM > To: Fairoz Matte ; Jini Susan George > ; serviceability-dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on Solaris 12 > when loading dumped core > > > Hi Fairoz, > > It looks good to me. > > Thanks, > Serguei > > > On 9/27/18 10:10 PM, Fairoz Matte wrote: > > Hi Jini, thanks for the review. May I get one more review for this? > > > > Thanks, > > Fairoz > > > >> -----Original Message----- > >> From: Jini George > >> Sent: Friday, September 28, 2018 10:37 AM > >> To: Fairoz Matte ; serviceability- > >> dev at openjdk.java.net > >> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on > >> Solaris 12 when loading dumped core > >> > >> This looks good to me, Fairoz. > >> > >> Thanks, > >> Jini. > >> > >> On 9/26/2018 1:37 PM, Fairoz Matte wrote: > >>> Hi Jini, > >>> > >>> Thanks for pointing out that, yes we cannot make that cleanup for JDK8. > >>> Keeping it very simple and taking only changes required to fix > >>> JDK-8164383 http://cr.openjdk.java.net/~fmatte/8164383/webrev.02/ > >>> > >>> I have verified running "test/serviceability/sa/jmap- > >> hashcode/Test8028623.java" test case (found from one of the duplicate > >> issue of JDK-8164383). > >>> Results are as expected before and after the patch on Solaris 12 and > >>> Solaris > >> 10. > >>> Along with that, I have verified with Internal testing and found no > >>> issues > >>> > >>> Thanks, > >>> Fairoz > >>> > >>>> -----Original Message----- > >>>> From: Jini George > >>>> Sent: Tuesday, September 25, 2018 3:48 PM > >>>> To: Fairoz Matte ; serviceability- > >>>> dev at openjdk.java.net > >>>> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on > >>>> Solaris 12 when loading dumped core > >>>> > >>>> Hi Fairoz, > >>>> > >>>> I took a better look at the changes and I realized that the cleanup > >>>> related to SOLARIS_11_B159_OR_LATER would be valid for only JDK9 > >>>> and later. Since > >>>> JDK8 is supported for Solaris 10 too, I believe that the cleanup > >>>> related changes done as a part of JDK-8164383 should not be done > >>>> for > >> JDK-8. > >>>> Thanks! > >>>> Jini. > >>>> > >>>> On 9/24/2018 7:21 PM, Fairoz Matte wrote: > >>>>> Hi Jini, > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Jini George > >>>>>> Sent: Friday, September 21, 2018 4:07 PM > >>>>>> To: Fairoz Matte ; serviceability- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: [8u-backport] RFR: JDK-8164383 : jhsdb dumps core on > >>>>>> Solaris 12 when loading dumped core > >>>>>> > >>>>>> Hi Fairoz, > >>>>>> > >>>>>> This looks good to me. One nit which got missed out in the > >>>>>> original change also is that in saproc.cpp, the following > >>>>>> comments > >>>>>> > >>>>>> 452 > >>>>>> 453 // Pstack_iter() proc_stack_f callback prior to > >>>>>> Nevada-B159 > >>>>>> > >>>>>> 476 // Pstack_iter() proc_stack_f callback in Nevada-B159 or later > >>>>>> 477 /*ARGSUSED*/ > >>>>>> > >>>>> I have incorporated above changes > >>>>> > >>>>>> would not be required anymore. And we would not need the > wrapper > >> to > >>>>>> the callback routine fill_cframe_list() -- as in, we would need > >>>>>> only one routine with the appropriate arguments passed. But you > >>>>>> are free to ignore this since this was not done as a part of the > >>>>>> original > >> change. > >>>>> Removed wrapper_fill_cframe_list function and fill_cframe_list > >>>>> function > >>>> has been used directly. > >>>>> Please find the updated webrev > >>>>> http://cr.openjdk.java.net/~fmatte/8164383/webrev.01/ > >>>>> > >>>>> Thanks, > >>>>> Fairoz > >>>>> > >>>>>> Thanks, > >>>>>> Jini (Not a Reviewer). > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 9/20/2018 7:06 PM, Fairoz Matte wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> Kindly review the backport of "JDK-8164383 : jhsdb dumps core on > >>>>>>> Solaris 12 when loading dumped core" to 8u > >>>>>>> > >>>>>>> Webrev - http://cr.openjdk.java.net/~fmatte/8164383/webrev.00/ > >>>>>>> > >>>>>>> JBS bug - https://bugs.openjdk.java.net/browse/JDK-8164383 > >>>>>>> > >>>>>>> JDK9 changeset - > >>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce3eaa22b582 > >>>>>>> > >>>>>>> JDK9 review thread - > >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-O > >>>>>>> ct > >>>>>>> ob > >>>>>>> er > >>>>>>> /020543.html > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Fairoz > >>>>>>> > From doug.simon at oracle.com Tue Oct 2 08:11:24 2018 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 2 Oct 2018 10:11:24 +0200 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> Message-ID: <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> It would be great to get some input from the non-compilers teams on this RFR. -Doug > On 28 Sep 2018, at 19:51, Vladimir Kozlov wrote: > > To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. > > Thanks, > Vladimir > > On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >> Adding serviceability-dev at ... since this is JVM/TI... >> Dan >> On 9/25/18 10:48 AM, Doug Simon wrote: >>> A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. >>> >>> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, >>> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. >>> >>> The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: >>> * Returning null instead of throwing an exception on failure. >>> * Adding a `bool null_on_fail` argument to all relevant methods. >>> * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. >>> This represents a significant number of changes. >>> >>> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. >>> >>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>> >>> -Doug From jcbeyler at google.com Tue Oct 2 13:51:08 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 2 Oct 2018 15:51:08 +0200 Subject: RFR (M) 8211131: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[G-I]* In-Reply-To: <0be9bef2-6052-0768-fb9b-57ae43baff7c@oracle.com> References: <0be9bef2-6052-0768-fb9b-57ae43baff7c@oracle.com> Message-ID: Hi Alex, That is because this webrev was done before I added the 100 character wrap, which I added when I was generating the next batch of changes. Here is the webrev with the new version of the script: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 Thanks, let me know what you think! Jc On Tue, Oct 2, 2018 at 2:56 AM Alex Menkov wrote: > Hi Jc, > > Looking at your conversion script I expected things like > > if (!NSK_JVMTI_VERIFY( > NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { > > to be converted to > > if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps))) { > > (then the final string is shorter than 100 symbols) > > But actually I see > > if (!NSK_JVMTI_VERIFY( > - NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { > + jvmti->AddCapabilities(&caps))) { > > --alex > > On 09/26/2018 20:37, JC Beyler wrote: > > Hi all, > > > > I continued the NSK_CPP_STUB removal with this webrev: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 > > > > This does the first 50 files of the jvmti subfolder, it is done > > automatically by the scripts I put in the bug comments. > > > > Let me know what you think, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Tue Oct 2 15:16:08 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 02 Oct 2018 11:16:08 -0400 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr Message-ID: <5BB38BB8.3040601@oracle.com> Solaris debug builds are failing tests that use the attach interface. An IOException is reported when the java_pid file is not opened. It appears that the attempt to attach is taking place too quickly. This workaround will allow the open operation to be retried after a short pause. Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 Testing is in progress. From gary.adams at oracle.com Tue Oct 2 18:29:25 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 02 Oct 2018 14:29:25 -0400 Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false In-Reply-To: References: Message-ID: <5BB3B905.7050904@oracle.com> Looking for one more reviewer before we push this changeset. On 9/22/18, 6:45 AM, gary.adams at oracle.com wrote: > This is a very old bug that started off as a closed test, but should > have an open review > before it finally gets pushed. Many other jdb bugs will be closed as > duplicates as a > result of this change. > > The problem shows up as a corrupted log when running the jdb tests. > The tests send commands to a jdb process and parse the output to determine > if the correct functions were performed. Sometimes the tests will timeout, > sometimes the test will report the commands were not successful. > > When running jdb the output can come from several different threads. > - the command processing thread > - the event handler thread > - asynchronous command threads > - debuggee class (separate process) > > This fix works around an issue between the command > thread and the event handler thread. In the TTY.executeCommand() > method there is a large dispatch to commands that ends with the printing > of a prompt for the user to enter another command. > > When commands {cont, next, step, stepi} are processed they > resume the vm in the debuggee. This can cause the event handler > to be woken up. Events typically display messages, such > as "Breakpoint hit", "Step completed". They also set the > current thread variable so a "current location" in the source can > be identified. The event finishes by printing a prompt so the user will > enter the next command. > > The corruption in the log shows up when the event handler > starts running between the printing of the command and > command issuing the prompt. It also shows up when > a prompt is written in the middle of the event output. > > The proposed fix allows the {cont,next,step,stepi} commands > to issue a simple prompt before performing the command > that resumes the debuggee. It then skips the prompt that is issued > at the end of the excuteCommand() dispatch. > > A variety of other fixes had been tried such as locks and > output buffering, but all fell short. Many of the output > routines are shared. Even the executeCommand() processing > is called from the event handler thread to process monitor > commands. > > Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev.03/ > > This fix was tested with 1000 test runs on the slower debug builds > where the problem was observed more often. Before the fix it was > common to see 9/1000 failures on windows-x64 and solaris-sparc9 > platforms. > > Here's a sample of a corrupted log. A prompt is displayed after > an event header was displayed. As the next command is processed > the rest of the event output shows up. > ... > Breakpoint hit: main[1] > Sending command: locals > > reply[0]: "thread=main", > nsk.jdb.locals.locals002.locals002a.allKindsOfLocals(), line=82 bci=62 > ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Oct 2 18:35:16 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 Oct 2018 19:35:16 +0100 Subject: Infinite loop in jdk/test/sun/management/windows/revokeall In-Reply-To: References: <5b29307d-903d-190d-c074-7be5955910ea@oracle.com> Message-ID: <81fd3c73-311e-27c3-b736-125961177800@oracle.com> On 01/10/2018 17:43, JC Beyler wrote: > Hi, > > Should we not be also incrementing i to get the next Ace? Otherwise, > we are always getting the same one and probably just waiting till the > count is 0 which would terminate the loop (if that is what we want, > why not just break?). > > Thanks, > Jc > An alternative is to replace the revokeall tool in the test suite with test infrastructure that uses the new file system API. There is support for editing ACLs which I think should be enough to drop the entries that the runtime looks as part of its check to ensure that password file is secure. -Alan From chris.plummer at oracle.com Tue Oct 2 19:12:06 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Oct 2018 12:12:06 -0700 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <5BB38BB8.3040601@oracle.com> References: <5BB38BB8.3040601@oracle.com> Message-ID: <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> Without the fix was this issue easy enough to reproduce that you can be sure this is resolving it? Chris On 10/2/18 8:16 AM, Gary Adams wrote: > Solaris debug builds are failing tests that use the attach interface. > An IOException is reported when the java_pid file is not opened. > > It appears that the attempt to attach is taking place too quickly. > This workaround will allow the open operation to be retried > after a short pause. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 > > Testing is in progress. From gary.adams at oracle.com Tue Oct 2 19:27:59 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 2 Oct 2018 15:27:59 -0400 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> Message-ID: <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> The problem reproduced pretty quickly. I added a call to checkPermission and revealed the "file not found" from the stat call when the IOException was detected. There has been some flakiness from the Solaris test machines today, so I'll continue with the testing a bit longer. On 10/2/18 3:12 PM, Chris Plummer wrote: > Without the fix was this issue easy enough to reproduce that you can > be sure this is resolving it? > > Chris > > On 10/2/18 8:16 AM, Gary Adams wrote: >> Solaris debug builds are failing tests that use the attach interface. >> An IOException is reported when the java_pid file is not opened. >> >> It appears that the attempt to attach is taking place too quickly. >> This workaround will allow the open operation to be retried >> after a short pause. >> >> ? Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >> >> Testing is in progress. > > > From chris.plummer at oracle.com Tue Oct 2 20:11:59 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Oct 2018 13:11:59 -0700 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> Message-ID: Can you summarize how the attach handshaking is suppose to work? I'm just wondering why the attacher would ever be looking for the file before the attachee has created it. It seems a proper handshake would prevent this. Maybe there's some sort of visibility issue where the attachee has indeed created the file, but it is not immediately visible to the attacher process. Chris On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: > The problem reproduced pretty quickly. > I added a call to checkPermission and revealed the > "file not found" from the stat call when the IOException > was detected. > > There has been some flakiness from the Solaris test machines today, > so I'll continue with the testing a bit longer. > > On 10/2/18 3:12 PM, Chris Plummer wrote: >> Without the fix was this issue easy enough to reproduce that you can >> be sure this is resolving it? >> >> Chris >> >> On 10/2/18 8:16 AM, Gary Adams wrote: >>> Solaris debug builds are failing tests that use the attach interface. >>> An IOException is reported when the java_pid file is not opened. >>> >>> It appears that the attempt to attach is taking place too quickly. >>> This workaround will allow the open operation to be retried >>> after a short pause. >>> >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>> >>> Testing is in progress. >> >> >> > From gary.adams at oracle.com Tue Oct 2 20:44:45 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 2 Oct 2018 16:44:45 -0400 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> Message-ID: <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> The general attach sequence ... src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java ?the attacher creates an attach_pid file in a directory where the attachee is runnning ?issues a signal to the attacheee ? loops waiting for the java_pid file to be created ? default timeout is 10 seconds ? src/hotspot/os/solaris/attachListener_solaris.cpp ?? attachee creates the java_pid file ?? listens til the attacher opens the door ... Not sure when a bare IOException is thrown rather than the more specific FileNotFoundException. On 10/2/18 4:11 PM, Chris Plummer wrote: > Can you summarize how the attach handshaking is suppose to work? I'm > just wondering why the attacher would ever be looking for the file > before the attachee has created it. It seems a proper handshake would > prevent this. Maybe there's some sort of visibility issue where the > attachee has indeed created the file, but it is not immediately > visible to the attacher process. > > Chris > > On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: >> The problem reproduced pretty quickly. >> I added a call to checkPermission and revealed the >> "file not found" from the stat call when the IOException >> was detected. >> >> There has been some flakiness from the Solaris test machines today, >> so I'll continue with the testing a bit longer. >> >> On 10/2/18 3:12 PM, Chris Plummer wrote: >>> Without the fix was this issue easy enough to reproduce that you can >>> be sure this is resolving it? >>> >>> Chris >>> >>> On 10/2/18 8:16 AM, Gary Adams wrote: >>>> Solaris debug builds are failing tests that use the attach interface. >>>> An IOException is reported when the java_pid file is not opened. >>>> >>>> It appears that the attempt to attach is taking place too quickly. >>>> This workaround will allow the open operation to be retried >>>> after a short pause. >>>> >>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>>> >>>> Testing is in progress. >>> >>> >>> >> > > From chris.plummer at oracle.com Tue Oct 2 20:57:43 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Oct 2018 13:57:43 -0700 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> Message-ID: <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> On 10/2/18 1:44 PM, gary.adams at oracle.com wrote: > The general attach sequence ... > > src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java > > ?the attacher creates an attach_pid file in a directory where the > attachee is runnning > ?issues a signal to the attacheee > > ? loops waiting for the java_pid file to be created > ? default timeout is 10 seconds > So getting a FileNotFoundException while in this loop is OK, but IOException is not. > src/hotspot/os/solaris/attachListener_solaris.cpp > > ?? attachee creates the java_pid file > ?? listens til the attacher opens the door > I'm don't think this is related, but JDK-8199811 made a fix in attachListener_solaris.cpp to make it wait up to 10 seconds for initialization to complete before failing the enqueue. > ... > Not sure when a bare IOException is thrown rather than the > more specific FileNotFoundException. Where is the IOException originating from? I wonder if the issue is that the file is in the process of being created, but is not fully created yet. Maybe it is there, but owner/group/permissions have not been set yet, and this results in an IOException instead of FileNotFoundException. Chris > > > > On 10/2/18 4:11 PM, Chris Plummer wrote: >> Can you summarize how the attach handshaking is suppose to work? I'm >> just wondering why the attacher would ever be looking for the file >> before the attachee has created it. It seems a proper handshake would >> prevent this. Maybe there's some sort of visibility issue where the >> attachee has indeed created the file, but it is not immediately >> visible to the attacher process. >> >> Chris >> >> On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: >>> The problem reproduced pretty quickly. >>> I added a call to checkPermission and revealed the >>> "file not found" from the stat call when the IOException >>> was detected. >>> >>> There has been some flakiness from the Solaris test machines today, >>> so I'll continue with the testing a bit longer. >>> >>> On 10/2/18 3:12 PM, Chris Plummer wrote: >>>> Without the fix was this issue easy enough to reproduce that you >>>> can be sure this is resolving it? >>>> >>>> Chris >>>> >>>> On 10/2/18 8:16 AM, Gary Adams wrote: >>>>> Solaris debug builds are failing tests that use the attach interface. >>>>> An IOException is reported when the java_pid file is not opened. >>>>> >>>>> It appears that the attempt to attach is taking place too quickly. >>>>> This workaround will allow the open operation to be retried >>>>> after a short pause. >>>>> >>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>>>> >>>>> Testing is in progress. >>>> >>>> >>>> >>> >> >> > From alexey.menkov at oracle.com Tue Oct 2 21:03:46 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 2 Oct 2018 14:03:46 -0700 Subject: RFR (M) 8211131: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[G-I]* In-Reply-To: References: <0be9bef2-6052-0768-fb9b-57ae43baff7c@oracle.com> Message-ID: Hi Jc, This looks much better to me :) Sometimes the script generate too long lines like - if (!NSK_JNI_VERIFY(jni, (testedMeth = NSK_CPP_STUB4(GetStaticMethodID, - jni, objCls, meth_sig[clsIdx][i][0], - meth_sig[clsIdx][i][2])) != NULL)) { + if (!NSK_JNI_VERIFY(jni, (testedMeth = jni->GetStaticMethodID(objCls, meth_sig[clsIdx][i][0], meth_sig[clsIdx][i][2])) != NULL)) { But I think it would be better to fix them clearing NSK_JNI_VERIFY stuff. So LGTM. --alex On 10/02/2018 06:51, JC Beyler wrote: > Hi Alex, > > That is because this webrev was done before I added the 100 character > wrap, which I added when I was generating the next batch of changes. > Here is the webrev with the new version of the script: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 > > Thanks, let me know what you think! > Jc > > On Tue, Oct 2, 2018 at 2:56 AM Alex Menkov > wrote: > > Hi Jc, > > Looking at your conversion script I expected things like > > ? ? ? ? ? if (!NSK_JVMTI_VERIFY( > ? ? ? ? ? ? ? ? NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { > > to be converted to > > if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps))) { > > (then the final string is shorter than 100 symbols) > > But actually I see > > if (!NSK_JVMTI_VERIFY( > -? ? ? ? ? ? ? ? NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { > +? ? ? ? ? ? ? ? jvmti->AddCapabilities(&caps))) { > > --alex > > On 09/26/2018 20:37, JC Beyler wrote: > > Hi all, > > > > I continued the NSK_CPP_STUB removal with this webrev: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.00/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 > > > > This does the first 50 files of the jvmti subfolder, it is done > > automatically by the scripts I put in the bug comments. > > > > Let me know what you think, > > Jc > > > > -- > > Thanks, > Jc From david.holmes at oracle.com Tue Oct 2 21:38:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Oct 2018 07:38:34 +1000 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> Message-ID: <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> Chris, On 3/10/2018 6:57 AM, Chris Plummer wrote: > > > On 10/2/18 1:44 PM, gary.adams at oracle.com wrote: >> The general attach sequence ... >> >> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >> >> ?the attacher creates an attach_pid file in a directory where the >> attachee is runnning >> ?issues a signal to the attacheee >> >> ? loops waiting for the java_pid file to be created >> ? default timeout is 10 seconds >> > So getting a FileNotFoundException while in this loop is OK, but > IOException is not. > >> src/hotspot/os/solaris/attachListener_solaris.cpp >> >> ?? attachee creates the java_pid file >> ?? listens til the attacher opens the door >> > I'm don't think this is related, but JDK-8199811 made a fix in > attachListener_solaris.cpp to make it wait up to 10 seconds for > initialization to complete before failing the enqueue. > >> ... >> Not sure when a bare IOException is thrown rather than the >> more specific FileNotFoundException. > Where is the IOException originating from? I wonder if the issue is that > the file is in the process of being created, but is not fully created > yet. Maybe it is there, but owner/group/permissions have not been set > yet, and this results in an IOException instead of FileNotFoundException. The exception is shown in the bug report: [java.io.IOException: Permission denied at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native Method) at jdk.attach/sun.tools.attach.VirtualMachineImpl.openDoor(VirtualMachineImpl.java:215) at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) And if you look at the native code the EPERM from open will cause IOException to be thrown. ./jdk.attach/solaris/native/libattach/VirtualMachineImpl.c JNIEXPORT jint JNICALL Java_sun_tools_attach_VirtualMachineImpl_open (JNIEnv *env, jclass cls, jstring path) { jboolean isCopy; const char* p = GetStringPlatformChars(env, path, &isCopy); if (p == NULL) { return 0; } else { int fd; int err = 0; fd = open(p, O_RDWR); if (fd == -1) { err = errno; } if (isCopy) { JNU_ReleaseStringPlatformChars(env, path, p); } if (fd == -1) { if (err == ENOENT) { JNU_ThrowByName(env, "java/io/FileNotFoundException", NULL); } else { char* msg = strdup(strerror(err)); JNU_ThrowIOException(env, msg); if (msg != NULL) { free(msg); } We should add the path to the exception message. David ----- > Chris >> >> >> >> On 10/2/18 4:11 PM, Chris Plummer wrote: >>> Can you summarize how the attach handshaking is suppose to work? I'm >>> just wondering why the attacher would ever be looking for the file >>> before the attachee has created it. It seems a proper handshake would >>> prevent this. Maybe there's some sort of visibility issue where the >>> attachee has indeed created the file, but it is not immediately >>> visible to the attacher process. >>> >>> Chris >>> >>> On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: >>>> The problem reproduced pretty quickly. >>>> I added a call to checkPermission and revealed the >>>> "file not found" from the stat call when the IOException >>>> was detected. >>>> >>>> There has been some flakiness from the Solaris test machines today, >>>> so I'll continue with the testing a bit longer. >>>> >>>> On 10/2/18 3:12 PM, Chris Plummer wrote: >>>>> Without the fix was this issue easy enough to reproduce that you >>>>> can be sure this is resolving it? >>>>> >>>>> Chris >>>>> >>>>> On 10/2/18 8:16 AM, Gary Adams wrote: >>>>>> Solaris debug builds are failing tests that use the attach interface. >>>>>> An IOException is reported when the java_pid file is not opened. >>>>>> >>>>>> It appears that the attempt to attach is taking place too quickly. >>>>>> This workaround will allow the open operation to be retried >>>>>> after a short pause. >>>>>> >>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>>>>> >>>>>> Testing is in progress. >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From chris.plummer at oracle.com Tue Oct 2 21:54:07 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Oct 2018 14:54:07 -0700 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> Message-ID: <957abd42-1b68-7395-e495-5d50fb3a786e@oracle.com> On 10/2/18 2:38 PM, David Holmes wrote: > Chris, > > On 3/10/2018 6:57 AM, Chris Plummer wrote: >> >> >> On 10/2/18 1:44 PM, gary.adams at oracle.com wrote: >>> The general attach sequence ... >>> >>> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>> >>> ?the attacher creates an attach_pid file in a directory where the >>> attachee is runnning >>> ?issues a signal to the attacheee >>> >>> ? loops waiting for the java_pid file to be created >>> ? default timeout is 10 seconds >>> >> So getting a FileNotFoundException while in this loop is OK, but >> IOException is not. >> >>> src/hotspot/os/solaris/attachListener_solaris.cpp >>> >>> ?? attachee creates the java_pid file >>> ?? listens til the attacher opens the door >>> >> I'm don't think this is related, but JDK-8199811 made a fix in >> attachListener_solaris.cpp to make it wait up to 10 seconds for >> initialization to complete before failing the enqueue. >> >>> ... >>> Not sure when a bare IOException is thrown rather than the >>> more specific FileNotFoundException. >> Where is the IOException originating from? I wonder if the issue is >> that the file is in the process of being created, but is not fully >> created yet. Maybe it is there, but owner/group/permissions have not >> been set yet, and this results in an IOException instead of >> FileNotFoundException. > > The exception is shown in the bug report: > > ?[java.io.IOException: Permission denied > at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native Method) > at > jdk.attach/sun.tools.attach.VirtualMachineImpl.openDoor(VirtualMachineImpl.java:215) > at > jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) > at > jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) > at > jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) > at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) > at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) > > And if you look at the native code the EPERM from open will cause > IOException to be thrown. > > ./jdk.attach/solaris/native/libattach/VirtualMachineImpl.c > > JNIEXPORT jint JNICALL Java_sun_tools_attach_VirtualMachineImpl_open > ? (JNIEnv *env, jclass cls, jstring path) > { > ??? jboolean isCopy; > ??? const char* p = GetStringPlatformChars(env, path, &isCopy); > ??? if (p == NULL) { > ??????? return 0; > ??? } else { > ??????? int fd; > ??????? int err = 0; > > ??????? fd = open(p, O_RDWR); > ??????? if (fd == -1) { > ??????????? err = errno; > ??????? } > > ??????? if (isCopy) { > ??????????? JNU_ReleaseStringPlatformChars(env, path, p); > ??????? } > > ??????? if (fd == -1) { > ??????????? if (err == ENOENT) { > ??????????????? JNU_ThrowByName(env, "java/io/FileNotFoundException", > NULL); > ??????????? } else { > ??????????????? char* msg = strdup(strerror(err)); > ??????????????? JNU_ThrowIOException(env, msg); > ??????????????? if (msg != NULL) { > ??????????????????? free(msg); > ??????????????? } > > > We should add the path to the exception message. > Thanks David. So if EPERM is the error and a retry 100ms later works, I think that supports my hypothesis that the file is not quite fully created. So Gary's fix is probably fine. The only other possible fix I can think of that wouldn't require an explicit delay (or multiple retries) is probably not worth the complexity. It would require that the attachee create two files, and the attacher try to open the second file first. When it either opens or returns EPERM, you know the first file can safety be opened. Chris > David > ----- > >> Chris >>> >>> >>> >>> On 10/2/18 4:11 PM, Chris Plummer wrote: >>>> Can you summarize how the attach handshaking is suppose to work? >>>> I'm just wondering why the attacher would ever be looking for the >>>> file before the attachee has created it. It seems a proper >>>> handshake would prevent this. Maybe there's some sort of visibility >>>> issue where the attachee has indeed created the file, but it is not >>>> immediately visible to the attacher process. >>>> >>>> Chris >>>> >>>> On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: >>>>> The problem reproduced pretty quickly. >>>>> I added a call to checkPermission and revealed the >>>>> "file not found" from the stat call when the IOException >>>>> was detected. >>>>> >>>>> There has been some flakiness from the Solaris test machines today, >>>>> so I'll continue with the testing a bit longer. >>>>> >>>>> On 10/2/18 3:12 PM, Chris Plummer wrote: >>>>>> Without the fix was this issue easy enough to reproduce that you >>>>>> can be sure this is resolving it? >>>>>> >>>>>> Chris >>>>>> >>>>>> On 10/2/18 8:16 AM, Gary Adams wrote: >>>>>>> Solaris debug builds are failing tests that use the attach >>>>>>> interface. >>>>>>> An IOException is reported when the java_pid file is not opened. >>>>>>> >>>>>>> It appears that the attempt to attach is taking place too quickly. >>>>>>> This workaround will allow the open operation to be retried >>>>>>> after a short pause. >>>>>>> >>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>>>>>> >>>>>>> Testing is in progress. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> From alexey.menkov at oracle.com Tue Oct 2 22:00:36 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 2 Oct 2018 15:00:36 -0700 Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false In-Reply-To: <5BB3B905.7050904@oracle.com> References: <5BB3B905.7050904@oracle.com> Message-ID: <31ec27c0-7095-e524-7bfe-c5fef8b5eb02@oracle.com> Looks good to me. --alex On 10/02/2018 11:29, Gary Adams wrote: > Looking for one more reviewer before we push this changeset. > > On 9/22/18, 6:45 AM, gary.adams at oracle.com wrote: >> This is a very old bug that started off as a closed test, but should >> have an open review >> before it finally gets pushed. Many other jdb bugs will be closed as >> duplicates as a >> result of this change. >> >> The problem shows up as a corrupted log when running the jdb tests. >> The tests send commands to a jdb process and parse the output to determine >> if the correct functions were performed. Sometimes the tests will timeout, >> sometimes the test will report the commands were not successful. >> >> When running jdb the output can come from several different threads. >> ??? - the command processing thread >> ??? - the event handler thread >> ??? - asynchronous command threads >> ??? - debuggee class (separate process) >> >> This fix works around an issue between the command >> thread and the event handler thread. In the TTY.executeCommand() >> method there is a large dispatch to commands that ends with the printing >> of a prompt for the user to enter another command. >> >> When commands {cont, next, step, stepi} are processed they >> resume the vm in the debuggee. This can cause the event handler >> to be woken up. Events typically display messages, such >> as "Breakpoint hit", "Step completed". They also set the >> current thread variable so a "current location" in the source can >> be identified. The event finishes by printing a prompt so the user will >> enter the next command. >> >> The corruption in the log shows up when the event handler >> starts running between the printing of the command and >> command issuing the prompt. It also shows up when >> a prompt is written in the middle of the event output. >> >> The proposed fix allows the {cont,next,step,stepi} commands >> to issue a simple prompt before performing the command >> that resumes the debuggee. It then skips the prompt that is issued >> at the end of the excuteCommand() dispatch. >> >> A variety of other fixes had been tried such as locks and >> output buffering, but all fell short. Many of the output >> routines are shared. Even the executeCommand() processing >> is called from the event handler thread to process monitor >> commands. >> >> ? Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev.03/ >> >> This fix was tested with 1000 test runs on the slower debug builds >> where the problem was observed more often. Before the fix it was >> common to see 9/1000 failures on windows-x64 and solaris-sparc9 >> platforms. >> >> Here's a sample of a corrupted log. A prompt is displayed after >> an event header was displayed. As the next command is processed >> the rest of the event output shows up. >> ... >> Breakpoint hit: main[1] >> Sending command: locals >> >> reply[0]: "thread=main", >> nsk.jdb.locals.locals002.locals002a.allKindsOfLocals(), line=82 bci=62 >> ... > From david.holmes at oracle.com Tue Oct 2 22:23:15 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Oct 2018 08:23:15 +1000 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <957abd42-1b68-7395-e495-5d50fb3a786e@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> <957abd42-1b68-7395-e495-5d50fb3a786e@oracle.com> Message-ID: Minor correction: EPERM -> EACCES for Solaris Hard to see how to get a transient EACCES when opening a file ... though as it is really a door I guess there could be additional complexity. David On 3/10/2018 7:54 AM, Chris Plummer wrote: > On 10/2/18 2:38 PM, David Holmes wrote: >> Chris, >> >> On 3/10/2018 6:57 AM, Chris Plummer wrote: >>> >>> >>> On 10/2/18 1:44 PM, gary.adams at oracle.com wrote: >>>> The general attach sequence ... >>>> >>>> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>>> >>>> ?the attacher creates an attach_pid file in a directory where the >>>> attachee is runnning >>>> ?issues a signal to the attacheee >>>> >>>> ? loops waiting for the java_pid file to be created >>>> ? default timeout is 10 seconds >>>> >>> So getting a FileNotFoundException while in this loop is OK, but >>> IOException is not. >>> >>>> src/hotspot/os/solaris/attachListener_solaris.cpp >>>> >>>> ?? attachee creates the java_pid file >>>> ?? listens til the attacher opens the door >>>> >>> I'm don't think this is related, but JDK-8199811 made a fix in >>> attachListener_solaris.cpp to make it wait up to 10 seconds for >>> initialization to complete before failing the enqueue. >>> >>>> ... >>>> Not sure when a bare IOException is thrown rather than the >>>> more specific FileNotFoundException. >>> Where is the IOException originating from? I wonder if the issue is >>> that the file is in the process of being created, but is not fully >>> created yet. Maybe it is there, but owner/group/permissions have not >>> been set yet, and this results in an IOException instead of >>> FileNotFoundException. >> >> The exception is shown in the bug report: >> >> ?[java.io.IOException: Permission denied >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native Method) >> at >> jdk.attach/sun.tools.attach.VirtualMachineImpl.openDoor(VirtualMachineImpl.java:215) >> >> at >> jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) >> >> at >> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) >> >> at >> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) >> >> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) >> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) >> >> And if you look at the native code the EPERM from open will cause >> IOException to be thrown. >> >> ./jdk.attach/solaris/native/libattach/VirtualMachineImpl.c >> >> JNIEXPORT jint JNICALL Java_sun_tools_attach_VirtualMachineImpl_open >> ? (JNIEnv *env, jclass cls, jstring path) >> { >> ??? jboolean isCopy; >> ??? const char* p = GetStringPlatformChars(env, path, &isCopy); >> ??? if (p == NULL) { >> ??????? return 0; >> ??? } else { >> ??????? int fd; >> ??????? int err = 0; >> >> ??????? fd = open(p, O_RDWR); >> ??????? if (fd == -1) { >> ??????????? err = errno; >> ??????? } >> >> ??????? if (isCopy) { >> ??????????? JNU_ReleaseStringPlatformChars(env, path, p); >> ??????? } >> >> ??????? if (fd == -1) { >> ??????????? if (err == ENOENT) { >> ??????????????? JNU_ThrowByName(env, "java/io/FileNotFoundException", >> NULL); >> ??????????? } else { >> ??????????????? char* msg = strdup(strerror(err)); >> ??????????????? JNU_ThrowIOException(env, msg); >> ??????????????? if (msg != NULL) { >> ??????????????????? free(msg); >> ??????????????? } >> >> >> We should add the path to the exception message. >> > Thanks David. So if EPERM is the error and a retry 100ms later works, I > think that supports my hypothesis that the file is not quite fully > created. So Gary's fix is probably fine. The only other possible fix I > can think of that wouldn't require an explicit delay (or multiple > retries) is probably not worth the complexity. It would require that the > attachee create two files, and the attacher try to open the second file > first. When it either opens or returns EPERM, you know the first file > can safety be opened. > > Chris >> David >> ----- >> >>> Chris >>>> >>>> >>>> >>>> On 10/2/18 4:11 PM, Chris Plummer wrote: >>>>> Can you summarize how the attach handshaking is suppose to work? >>>>> I'm just wondering why the attacher would ever be looking for the >>>>> file before the attachee has created it. It seems a proper >>>>> handshake would prevent this. Maybe there's some sort of visibility >>>>> issue where the attachee has indeed created the file, but it is not >>>>> immediately visible to the attacher process. >>>>> >>>>> Chris >>>>> >>>>> On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: >>>>>> The problem reproduced pretty quickly. >>>>>> I added a call to checkPermission and revealed the >>>>>> "file not found" from the stat call when the IOException >>>>>> was detected. >>>>>> >>>>>> There has been some flakiness from the Solaris test machines today, >>>>>> so I'll continue with the testing a bit longer. >>>>>> >>>>>> On 10/2/18 3:12 PM, Chris Plummer wrote: >>>>>>> Without the fix was this issue easy enough to reproduce that you >>>>>>> can be sure this is resolving it? >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 10/2/18 8:16 AM, Gary Adams wrote: >>>>>>>> Solaris debug builds are failing tests that use the attach >>>>>>>> interface. >>>>>>>> An IOException is reported when the java_pid file is not opened. >>>>>>>> >>>>>>>> It appears that the attempt to attach is taking place too quickly. >>>>>>>> This workaround will allow the open operation to be retried >>>>>>>> after a short pause. >>>>>>>> >>>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>>>>>>> >>>>>>>> Testing is in progress. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> > > From serguei.spitsyn at oracle.com Wed Oct 3 01:14:18 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 2 Oct 2018 18:14:18 -0700 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> Message-ID: Hi Doug, The JVMTI related part looks good to me. Thank you for fixing it! Thanks, Serguei On 10/2/18 1:11 AM, Doug Simon wrote: > It would be great to get some input from the non-compilers teams on this RFR. > > -Doug > >> On 28 Sep 2018, at 19:51, Vladimir Kozlov wrote: >> >> To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. >> >> Thanks, >> Vladimir >> >> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>> Adding serviceability-dev at ... since this is JVM/TI... >>> Dan >>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>> A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. >>>> >>>> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, >>>> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. >>>> >>>> The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: >>>> * Returning null instead of throwing an exception on failure. >>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>> * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. >>>> This represents a significant number of changes. >>>> >>>> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. >>>> >>>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>> >>>> -Doug From serguei.spitsyn at oracle.com Wed Oct 3 04:50:45 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 2 Oct 2018 21:50:45 -0700 Subject: [CAUTION] RFR : 8211146 : fix problematic elif-tests after recent gcc warning changes Werror=undef In-Reply-To: <9af9d8c2-2580-0f25-2881-f4d76b2596a9@oracle.com> References: <3667f01e602a47a59739dfb6b73dcd5c@sap.com> <9af9d8c2-2580-0f25-2881-f4d76b2596a9@oracle.com> Message-ID: +1 (if you still need it) Thanks, Serguei On 9/26/18 4:41 AM, David Holmes wrote: > That all seems fine to me. > > Thanks for fixing. > > David > > On 26/09/2018 5:48 AM, Langer, Christoph wrote: >> Hi Matthias, >> >> looks good (and trivial). Ccing serviceability-dev because of change >> in libjdwp. >> >> Best regards >> >> Christoph >> >> *From:*nio-dev *On Behalf Of >> *Baesken, Matthias >> *Sent:* Mittwoch, 26. September 2018 11:25 >> *To:* 'build-dev at openjdk.java.net' ; >> net-dev ; nio-dev at openjdk.java.net >> *Cc:* Lindenmaier, Goetz ; Schmidt, Lutz >> >> *Subject:* [CAUTION] RFR : 8211146 : fix problematic elif-tests after >> recent gcc warning changes Werror=undef >> >> Hello, please review this small build fix . >> >> After the recent? changes? to ?the gcc compile flags?? with 8211029?? >> ??,? most of our? Linux builds stopped working . >> >> Error : >> >> === Output from failing command(s) repeated here === >> >> * For target support_native_java.base_libnet_DatagramPacket.o: >> >> In file included from >> /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/net_util.h:31:0, >> >> ?????????????????from >> /OpenJDK/8210319/jdk/src/java.base/share/native/libnet/DatagramPacket.c:27: >> >> /OpenJDK/8210319/jdk/src/java.base/unix/native/libnet/net_util_md.h:50:7: >> error: "__solaris__" is not defined [-Werror=undef] >> >> #elif __solaris__ >> >> ??????? ^ >> >> After looking into it,? it seems? that? the >> jdk/src/java.base/unix/native/libnet/net_util_md.h??? compile error >> is only triggered on older Linux OS? (e.g. SLES11). >> >> Probably that?s why it was not seen at Oracle ?after? puhsing after >> 8211029?? . >> >> Some greps? showed me a number of similar problematic #elif-checks >> for OS, I adjusted them too . >> >> Bug / webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8211146 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8211146.0/ >> >> >> Thanks, Matthias >> From serguei.spitsyn at oracle.com Wed Oct 3 05:22:39 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 2 Oct 2018 22:22:39 -0700 Subject: RFR (M) 8211131: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[G-I]* In-Reply-To: References: <0be9bef2-6052-0768-fb9b-57ae43baff7c@oracle.com> Message-ID: <7be1b96d-def2-e347-7dcf-a64bfcafc850@oracle.com> Hi Jc, Looks good to me. Thanks, Serguei On 10/2/18 6:51 AM, JC Beyler wrote: > Hi Alex, > > That is because this webrev was done before I added the 100 character > wrap, which I added when I was generating the next batch of changes. > Here is the webrev with the new version of the script: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 > > Thanks, let me know what you think! > Jc > > On Tue, Oct 2, 2018 at 2:56 AM Alex Menkov > wrote: > > Hi Jc, > > Looking at your conversion script I expected things like > > ? ? ? ? ? if (!NSK_JVMTI_VERIFY( > ? ? ? ? ? ? ? ? NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { > > to be converted to > > if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps))) { > > (then the final string is shorter than 100 symbols) > > But actually I see > > if (!NSK_JVMTI_VERIFY( > -? ? ? ? ? ? ? ? NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { > +? ? ? ? ? ? ? ? jvmti->AddCapabilities(&caps))) { > > --alex > > On 09/26/2018 20:37, JC Beyler wrote: > > Hi all, > > > > I continued the NSK_CPP_STUB removal with this webrev: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.00/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 > > > > This does the first 50 files of the jvmti subfolder, it is done > > automatically by the scripts I put in the bug comments. > > > > Let me know what you think, > > Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Wed Oct 3 06:03:10 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Wed, 3 Oct 2018 06:03:10 +0000 (UTC) Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: <07713e7d6f9b481d8b9a3570d97a2586@sap.com> References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> <07713e7d6f9b481d8b9a3570d97a2586@sap.com> Message-ID: <7ef145ac-4eb1-475f-822f-1dfb19ba7851@default> Hi Goetz, I have opened https://bugs.openjdk.java.net/browse/JDK-8211421 for the backport. Thanks, Sharath -----Original Message----- From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] Sent: Friday, September 28, 2018 8:41 PM To: Sharath Ballal; serviceability-dev Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Hi Sharath, what do you think about bringing this fix to jdk11u? We run the tests there regularly and see this problem, too. Best regards, Goetz. > -----Original Message----- > From: serviceability-dev > On Behalf Of Sharath Ballal > Sent: Montag, 24. September 2018 05:49 > To: serviceability-dev > Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > times out parsing a 4GB hprof file > > Hi, > > > > Pls review this test fix to add "-Xmx512m" to SA tests which create > either core file or heap dump, to avoid timeout due to large heap sizes. > > > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 > > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ > > > > > SA tests passed on Mach5 run. > > > > Thanks, > > Sharath > > > > From gary.adams at oracle.com Wed Oct 3 11:47:06 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 03 Oct 2018 07:47:06 -0400 Subject: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false In-Reply-To: <31ec27c0-7095-e524-7bfe-c5fef8b5eb02@oracle.com> References: <5BB3B905.7050904@oracle.com> <31ec27c0-7095-e524-7bfe-c5fef8b5eb02@oracle.com> Message-ID: <5BB4AC3A.3070205@oracle.com> Patch attached. On 10/2/18, 6:00 PM, Alex Menkov wrote: > Looks good to me. > > --alex > > On 10/02/2018 11:29, Gary Adams wrote: >> Looking for one more reviewer before we push this changeset. >> >> On 9/22/18, 6:45 AM, gary.adams at oracle.com wrote: >>> This is a very old bug that started off as a closed test, but should >>> have an open review >>> before it finally gets pushed. Many other jdb bugs will be closed as >>> duplicates as a >>> result of this change. >>> >>> The problem shows up as a corrupted log when running the jdb tests. >>> The tests send commands to a jdb process and parse the output to >>> determine >>> if the correct functions were performed. Sometimes the tests will >>> timeout, >>> sometimes the test will report the commands were not successful. >>> >>> When running jdb the output can come from several different threads. >>> - the command processing thread >>> - the event handler thread >>> - asynchronous command threads >>> - debuggee class (separate process) >>> >>> This fix works around an issue between the command >>> thread and the event handler thread. In the TTY.executeCommand() >>> method there is a large dispatch to commands that ends with the >>> printing >>> of a prompt for the user to enter another command. >>> >>> When commands {cont, next, step, stepi} are processed they >>> resume the vm in the debuggee. This can cause the event handler >>> to be woken up. Events typically display messages, such >>> as "Breakpoint hit", "Step completed". They also set the >>> current thread variable so a "current location" in the source can >>> be identified. The event finishes by printing a prompt so the user will >>> enter the next command. >>> >>> The corruption in the log shows up when the event handler >>> starts running between the printing of the command and >>> command issuing the prompt. It also shows up when >>> a prompt is written in the middle of the event output. >>> >>> The proposed fix allows the {cont,next,step,stepi} commands >>> to issue a simple prompt before performing the command >>> that resumes the debuggee. It then skips the prompt that is issued >>> at the end of the excuteCommand() dispatch. >>> >>> A variety of other fixes had been tried such as locks and >>> output buffering, but all fell short. Many of the output >>> routines are shared. Even the executeCommand() processing >>> is called from the event handler thread to process monitor >>> commands. >>> >>> Webrev: http://cr.openjdk.java.net/~gadams/8169718/webrev.03/ >>> >>> This fix was tested with 1000 test runs on the slower debug builds >>> where the problem was observed more often. Before the fix it was >>> common to see 9/1000 failures on windows-x64 and solaris-sparc9 >>> platforms. >>> >>> Here's a sample of a corrupted log. A prompt is displayed after >>> an event header was displayed. As the next command is processed >>> the rest of the event output shows up. >>> ... >>> Breakpoint hit: main[1] >>> Sending command: locals >>> >>> reply[0]: "thread=main", >>> nsk.jdb.locals.locals002.locals002a.allKindsOfLocals(), line=82 bci=62 >>> ... >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8169718.patch URL: From gary.adams at oracle.com Wed Oct 3 18:55:31 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 03 Oct 2018 14:55:31 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently Message-ID: <5BB510A3.6000207@oracle.com> While running a block of nsk/jvmti/scenarios tests, I noticed an occasional failure for cm02t001 in windows debug platform. After enabling the nsk verbose diagnostics and adding a few messages in the main test and the debuggee thread, it became clear that the missing contention was due to the main thread getting ahead of the debugee thread. The call to letFinish() below let's the deuggee thread wake up from it's wait and proceed to the contention for the endingMonitor. If the main thread waits a little longer it should reach the debuggee thread synchronized block. I reopened an earlier bug that was closed as CNR. Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java @@ -82,7 +82,7 @@ thread.letFinish(); // pause to provoke contention - Thread.sleep(100); + Thread.sleep(1000); } catch (InterruptedException e) { throw new Failure(e); } From chris.plummer at oracle.com Wed Oct 3 20:49:05 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 3 Oct 2018 13:49:05 -0700 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <5BB510A3.6000207@oracle.com> References: <5BB510A3.6000207@oracle.com> Message-ID: <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> Hi Gary, Although I don't like relying on timer delays for stuff like this, the code for it is already in place, so I'm ok with making the delay longer to make sure there is contention on the monitor. Could you update the comment to read "// pause to provoke contention on thread.endingMonitor" thanks, Chris On 10/3/18 11:55 AM, Gary Adams wrote: > While running a block of nsk/jvmti/scenarios tests, I noticed an > occasional failure > for cm02t001 in windows debug platform. After enabling the nsk verbose > diagnostics and adding a few messages in the main test and the debuggee > thread, it became clear that the missing contention was due to the > main thread > getting ahead of the debugee thread. > > The call to letFinish() below let's the deuggee thread wake up from > it's wait > and proceed to the contention for the endingMonitor. If the main thread > waits a little longer it should reach the debuggee thread synchronized > block. > > I reopened an earlier bug that was closed as CNR. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 > > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java > > --- > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java > +++ > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java > @@ -82,7 +82,7 @@ > ???????????????? thread.letFinish(); > > ???????????????? // pause to provoke contention > -??????????????? Thread.sleep(100); > +??????????????? Thread.sleep(1000); > ???????????? } catch (InterruptedException e) { > ???????????????? throw new Failure(e); > ???????????? } From doug.simon at oracle.com Wed Oct 3 22:20:48 2018 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 4 Oct 2018 00:20:48 +0200 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> Message-ID: <7FD94ACE-4CF4-488C-9A2B-C440429B915A@oracle.com> Thanks for the reviews Serguei and Vladimir. Unless I hear objections in the next 24 hours, I'll push this webrev. -Doug > On 3 Oct 2018, at 03:14, serguei.spitsyn at oracle.com wrote: > > Hi Doug, > > The JVMTI related part looks good to me. > Thank you for fixing it! > > Thanks, > Serguei > > On 10/2/18 1:11 AM, Doug Simon wrote: >> It would be great to get some input from the non-compilers teams on this RFR. >> >> -Doug >> >>> On 28 Sep 2018, at 19:51, Vladimir Kozlov wrote: >>> >>> To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>>> Adding serviceability-dev at ... since this is JVM/TI... >>>> Dan >>>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>>> A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. >>>>> >>>>> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, >>>>> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. >>>>> >>>>> The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: >>>>> * Returning null instead of throwing an exception on failure. >>>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>>> * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. >>>>> This represents a significant number of changes. >>>>> >>>>> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. >>>>> >>>>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>>> >>>>> -Doug > From alexey.menkov at oracle.com Thu Oct 4 00:49:26 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 3 Oct 2018 17:49:26 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test Message-ID: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> Hi all, please review a fix for https://bugs.openjdk.java.net/browse/JDK-8211292 webrev: http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ The fix converts manual shell test to automatic java (as Java allows to parse jdb replies much easier). This is the last sub-task for the "shell to java conversion" task, so the fix also removes shared shell scripts. --alex From daniil.x.titov at oracle.com Thu Oct 4 04:29:57 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 03 Oct 2018 21:29:57 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation Message-ID: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> Please review the changes that fix the deadlock in the debugger when the debugger is running with the tracing option on. The problem here is that when the tracing is on the "JDI Target VM Interface" thread (the thread that reads all replies and then notifies the thread that sent the request that the reply has been received) is waiting for a lock which is already acquired by the thread that sent the request and is waiting for reply. The fix itself is in src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. The patch also reverts the changes done in 8129348 "Debugger hangs in trace mode with TRACE_SENDS" in src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java since they address only a specific case (VM is suspended and static method is invoked) while the proposed fix also solves issue 8129348 as well as issue 8193801 "Debugger hangs in trace mode for non-static methods". The changes include new tests for issues 8193879, 8193801 and 8129348. The changes in src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java solve the problem that the prompt is not printed in the debugger output when the breakpoint is hit and the suspend policy is SUSPEND_EVENT_THREAD. This is required for new tests to detect that command "stop thread at ..." is completed. Mach5 build and jdk_jdi tests succeeded. Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 Thanks, --Daniil From fairoz.matte at oracle.com Thu Oct 4 05:28:15 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Wed, 3 Oct 2018 22:28:15 -0700 (PDT) Subject: [8u-backport] RFR: JDK-8163083: SocketListeningConnector does not allow invocations with port 0 Message-ID: <51b96d82-f563-47a4-9a70-20f34c1ea8b2@default> Hi, Kindly review the backport of "JDK-8163083: SocketListeningConnector does not allow invocations with port 0" to 8u Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8163083 JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/d38cb687d631 Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-September/025209.html Thanks, Fairoz From goetz.lindenmaier at sap.com Thu Oct 4 07:20:45 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 4 Oct 2018 07:20:45 +0000 Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: <7ef145ac-4eb1-475f-822f-1dfb19ba7851@default> References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> <07713e7d6f9b481d8b9a3570d97a2586@sap.com> <7ef145ac-4eb1-475f-822f-1dfb19ba7851@default> Message-ID: Hi Sharath, I don't think you need a bug for this. You need to flag the other bug with "fix-request" http://openjdk.java.net/projects/jdk-updates/approval.html But unfortunately we need a new review because the patch does not apply cleanly. Will you send the RFR? I could do the review. Best regards, Goetz. > -----Original Message----- > From: Sharath Ballal > Sent: Mittwoch, 3. Oktober 2018 08:03 > To: Lindenmaier, Goetz ; serviceability-dev > > Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times > out parsing a 4GB hprof file > > Hi Goetz, > > I have opened https://bugs.openjdk.java.net/browse/JDK-8211421 for the > backport. > > > Thanks, > Sharath > > > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: Friday, September 28, 2018 8:41 PM > To: Sharath Ballal; serviceability-dev > Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times > out parsing a 4GB hprof file > > Hi Sharath, > > what do you think about bringing this fix to jdk11u? > We run the tests there regularly and see this problem, too. > > Best regards, > Goetz. > > > -----Original Message----- > > From: serviceability-dev > > On Behalf Of Sharath Ballal > > Sent: Montag, 24. September 2018 05:49 > > To: serviceability-dev > > Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > > times out parsing a 4GB hprof file > > > > Hi, > > > > > > > > Pls review this test fix to add "-Xmx512m" to SA tests which create > > either core file or heap dump, to avoid timeout due to large heap sizes. > > > > > > > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 > > > > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ > > > > > > > > > > SA tests passed on Mach5 run. > > > > > > > > Thanks, > > > > Sharath > > > > > > > > From sharath.ballal at oracle.com Thu Oct 4 08:51:57 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 4 Oct 2018 08:51:57 +0000 (UTC) Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> <07713e7d6f9b481d8b9a3570d97a2586@sap.com> <7ef145ac-4eb1-475f-822f-1dfb19ba7851@default> Message-ID: Sure Goetz. I will do that. I will create a RFR and send for review. Thanks, Sharath -----Original Message----- From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] Sent: Thursday, October 04, 2018 12:51 PM To: Sharath Ballal; serviceability-dev Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Hi Sharath, I don't think you need a bug for this. You need to flag the other bug with "fix-request" http://openjdk.java.net/projects/jdk-updates/approval.html But unfortunately we need a new review because the patch does not apply cleanly. Will you send the RFR? I could do the review. Best regards, Goetz. > -----Original Message----- > From: Sharath Ballal > Sent: Mittwoch, 3. Oktober 2018 08:03 > To: Lindenmaier, Goetz ; serviceability-dev > > Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > times out parsing a 4GB hprof file > > Hi Goetz, > > I have opened https://bugs.openjdk.java.net/browse/JDK-8211421 for the > backport. > > > Thanks, > Sharath > > > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: Friday, September 28, 2018 8:41 PM > To: Sharath Ballal; serviceability-dev > Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > times out parsing a 4GB hprof file > > Hi Sharath, > > what do you think about bringing this fix to jdk11u? > We run the tests there regularly and see this problem, too. > > Best regards, > Goetz. > > > -----Original Message----- > > From: serviceability-dev > > > > On Behalf Of Sharath Ballal > > Sent: Montag, 24. September 2018 05:49 > > To: serviceability-dev > > Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > > times out parsing a 4GB hprof file > > > > Hi, > > > > > > > > Pls review this test fix to add "-Xmx512m" to SA tests which create > > either core file or heap dump, to avoid timeout due to large heap sizes. > > > > > > > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 > > > > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ > > > > > > > > > > SA tests passed on Mach5 run. > > > > > > > > Thanks, > > > > Sharath > > > > > > > > From gary.adams at oracle.com Thu Oct 4 11:11:41 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 07:11:41 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> Message-ID: <5BB5F56D.6080902@oracle.com> Patch attached. I think one reviewer is sufficient for a trivial patch. On 10/3/18, 4:49 PM, Chris Plummer wrote: > Hi Gary, > > Although I don't like relying on timer delays for stuff like this, the > code for it is already in place, so I'm ok with making the delay > longer to make sure there is contention on the monitor. Could you > update the comment to read "// pause to provoke contention on > thread.endingMonitor" > > thanks, > > Chris > > On 10/3/18 11:55 AM, Gary Adams wrote: >> While running a block of nsk/jvmti/scenarios tests, I noticed an >> occasional failure >> for cm02t001 in windows debug platform. After enabling the nsk verbose >> diagnostics and adding a few messages in the main test and the debuggee >> thread, it became clear that the missing contention was due to the >> main thread >> getting ahead of the debugee thread. >> >> The call to letFinish() below let's the deuggee thread wake up from >> it's wait >> and proceed to the contention for the endingMonitor. If the main thread >> waits a little longer it should reach the debuggee thread >> synchronized block. >> >> I reopened an earlier bug that was closed as CNR. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >> >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >> >> --- >> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >> +++ >> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >> @@ -82,7 +82,7 @@ >> thread.letFinish(); >> >> // pause to provoke contention >> - Thread.sleep(100); >> + Thread.sleep(1000); >> } catch (InterruptedException e) { >> throw new Failure(e); >> } > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8036026.patch URL: From gary.adams at oracle.com Thu Oct 4 11:39:08 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 07:39:08 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <5BB5F56D.6080902@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> Message-ID: <5BB5FBDC.7080004@oracle.com> Oops, wrong comment used in the patch. Fresh patch attached. On 10/4/18, 7:11 AM, Gary Adams wrote: > Patch attached. > > I think one reviewer is sufficient for a trivial patch. > > On 10/3/18, 4:49 PM, Chris Plummer wrote: >> Hi Gary, >> >> Although I don't like relying on timer delays for stuff like this, >> the code for it is already in place, so I'm ok with making the delay >> longer to make sure there is contention on the monitor. Could you >> update the comment to read "// pause to provoke contention on >> thread.endingMonitor" >> >> thanks, >> >> Chris >> >> On 10/3/18 11:55 AM, Gary Adams wrote: >>> While running a block of nsk/jvmti/scenarios tests, I noticed an >>> occasional failure >>> for cm02t001 in windows debug platform. After enabling the nsk verbose >>> diagnostics and adding a few messages in the main test and the debuggee >>> thread, it became clear that the missing contention was due to the >>> main thread >>> getting ahead of the debugee thread. >>> >>> The call to letFinish() below let's the deuggee thread wake up from >>> it's wait >>> and proceed to the contention for the endingMonitor. If the main thread >>> waits a little longer it should reach the debuggee thread >>> synchronized block. >>> >>> I reopened an earlier bug that was closed as CNR. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>> >>> >>> diff --git >>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>> >>> --- >>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>> +++ >>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>> @@ -82,7 +82,7 @@ >>> thread.letFinish(); >>> >>> // pause to provoke contention >>> - Thread.sleep(100); >>> + Thread.sleep(1000); >>> } catch (InterruptedException e) { >>> throw new Failure(e); >>> } >> >> > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8036026.patch URL: From gary.adams at oracle.com Thu Oct 4 12:12:07 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 08:12:07 -0400 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> Message-ID: <5BB60397.7050807@oracle.com> In TTY.java do you need to force a simple prompt for the breakpoint event output? What prevents currentThread from being set at the time you are printing the prompt? 103 // Print the prompt if suspend policy is SUSPEND_EVENT_THREAD. In case of 104 // SUSPEND_ALL policy this is handled by vmInterrupted() method. 105 if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) { 106 MessageOutput.println(); 107 MessageOutput.printPrompt(); In Jdb.java you allow the waiting for the simple prompt. I don't see waitForSimplePrompt used in any existing tests. Since it is only looking for a single character it could produce false positives if the '>' was produced in the output stream. Is this wait paired to the added prompt for the break point event? 236 return waitForSimplePrompt ? waitForSimplePrompt(1, cmd.allowExit) : waitForPrompt(1, cmd.allowExit); It might be a good idea to include a test with multiple threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD behavior. On 10/4/18, 12:29 AM, Daniil Titov wrote: > Please review the changes that fix the deadlock in the debugger when the debugger is running with the tracing option on. > > The problem here is that when the tracing is on the "JDI Target VM Interface" thread (the thread that reads all replies and then notifies the thread that sent the request that the reply has been > received) is waiting for a lock which is already acquired by the thread that sent the request and is waiting for reply. > > The fix itself is in src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. > > The patch also reverts the changes done in 8129348 "Debugger hangs in trace mode with TRACE_SENDS" in src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java since they address only a specific case (VM is suspended and static method is invoked) while the proposed fix also solves issue 8129348 as well as issue 8193801 "Debugger hangs in trace mode for non-static methods". > > The changes include new tests for issues 8193879, 8193801 and 8129348. > > The changes in src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java solve the problem that the prompt is not printed in the debugger output when the breakpoint is hit and the suspend policy is SUSPEND_EVENT_THREAD. This is required for new tests to detect that command "stop thread at ..." is completed. > > Mach5 build and jdk_jdi tests succeeded. > > Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 > > Thanks, > --Daniil > > > From daniil.x.titov at oracle.com Thu Oct 4 15:45:21 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 04 Oct 2018 08:45:21 -0700 Subject: [8u-backport] RFR: JDK-8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <9F06B0E8-A403-44A7-B431-020851706969@oracle.com> References: <9F06B0E8-A403-44A7-B431-020851706969@oracle.com> Message-ID: <208B3295-90BA-4C6F-96C6-A6069C34DC55@oracle.com> Hi Fairoz, The backport looks good for me. Thanks! --Daniil ?On 10/3/18, 10:28 PM, "serviceability-dev on behalf of Fairoz Matte" wrote: Hi, Kindly review the backport of "JDK-8163083: SocketListeningConnector does not allow invocations with port 0" to 8u Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8163083 JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/d38cb687d631 Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-September/025209.html Thanks, Fairoz From daniel.daugherty at oracle.com Thu Oct 4 15:45:47 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 4 Oct 2018 11:45:47 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <5BB5FBDC.7080004@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> <5BB5FBDC.7080004@oracle.com> Message-ID: <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> Sleeps don't scale under load. That said, I agree with Chris that the code is already in place. One possible addition is to scale the sleep value by the timeout factor for the test. That will further reduce the likelihood of intermittent failures. Dan On 10/4/18 7:39 AM, Gary Adams wrote: > Oops, wrong comment used in the patch. > Fresh patch attached. > > On 10/4/18, 7:11 AM, Gary Adams wrote: >> Patch attached. >> >> I think one reviewer is sufficient for a trivial patch. >> >> On 10/3/18, 4:49 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> Although I don't like relying on timer delays for stuff like this, >>> the code for it is already in place, so I'm ok with making the delay >>> longer to make sure there is contention on the monitor. Could you >>> update the comment to read "// pause to provoke contention on >>> thread.endingMonitor" >>> >>> thanks, >>> >>> Chris >>> >>> On 10/3/18 11:55 AM, Gary Adams wrote: >>>> While running a block of nsk/jvmti/scenarios tests, I noticed an >>>> occasional failure >>>> for cm02t001 in windows debug platform. After enabling the nsk verbose >>>> diagnostics and adding a few messages in the main test and the >>>> debuggee >>>> thread, it became clear that the missing contention was due to the >>>> main thread >>>> getting ahead of the debugee thread. >>>> >>>> The call to letFinish() below let's the deuggee thread wake up from >>>> it's wait >>>> and proceed to the contention for the endingMonitor. If the main >>>> thread >>>> waits a little longer it should reach the debuggee thread >>>> synchronized block. >>>> >>>> I reopened an earlier bug that was closed as CNR. >>>> >>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>>> >>>> >>>> diff --git >>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>> >>>> --- >>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>> +++ >>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>> @@ -82,7 +82,7 @@ >>>> ???????????????? thread.letFinish(); >>>> >>>> ???????????????? // pause to provoke contention >>>> -??????????????? Thread.sleep(100); >>>> +??????????????? Thread.sleep(1000); >>>> ???????????? } catch (InterruptedException e) { >>>> ???????????????? throw new Failure(e); >>>> ???????????? } >>> >>> >> > From gary.adams at oracle.com Thu Oct 4 15:54:14 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 11:54:14 -0400 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> <957abd42-1b68-7395-e495-5d50fb3a786e@oracle.com> Message-ID: <5BB637A6.6010008@oracle.com> First, let me retract the proposed change, it is not the right solution to the problem originally reported. Second, as a bit of explanation consider the code fragments below. The high level processing calls openDoor which is willing to retry the operation as long as the error is flagged specifically as a FileNotFoundException. VirtualMachineImpl.java:72 VirtualMachineImpl.c:81 During my testing I had added a check VirtualMachineImpl.java:214 and when an IOException was detected made a call to checkPermissions to get more detailed information about the IOException. The error I saw was an ENOENT from the stat call. And not the detailed checks for specific permissions issues (VirtualMachineImpl.c:143) VirtualMachineImpl.c:118 VirtualMachineImpl.c:147 What I missed in the original proposed solution was a FileNotFoundException extends IOException. That means my delay and retry just duplicates the higher level retry around the openDoor call. Third, the original error message logged in the bug report : java.io.IOException: Permission denied at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native Method) had to have come from VirtualMachineImpl.c:70 VirtualMachineImpl.c:84 which means the actual open call reported the file does exist but the permissions do not allow the file to be accessed. That also means the normal mechanism of removing leftover java_pid files would not have cleaned up another user's java_pid files. ===== src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java: ... 67 // Opens the door file to the target VM. If the file is not 68 // found it might mean that the attach mechanism isn't started in the 69 // target VM so we attempt to start it and retry. 70 try { 71 fd = openDoor(pid); 72 } catch (FileNotFoundException fnf1) { 73 File f = createAttachFile(pid); 74 try { 75 sigquit(pid); 76 77 // give the target VM time to start the attach mechanism 78 final int delay_step = 100; 79 final long timeout = attachTimeout(); 80 long time_spend = 0; 81 long delay = 0; 82 do { 83 // Increase timeout on each attempt to reduce polling 84 delay += delay_step; 85 try { 86 Thread.sleep(delay); 87 } catch (InterruptedException x) { } 88 try { 89 fd = openDoor(pid); 90 } catch (FileNotFoundException fnf2) { 91 // pass 92 } 93 94 time_spend += delay; 95 if (time_spend > timeout/2 && fd == -1) { 96 // Send QUIT again to give target VM the last chance to react 97 sigquit(pid); 98 } 99 } while (time_spend <= timeout && fd == -1); 100 if (fd == -1) { 101 throw new AttachNotSupportedException( 102 String.format("Unable to open door %s: " + 103 "target process %d doesn't respond within %dms " + 104 "or HotSpot VM not loaded", socket_path, pid, time_spend)); 105 } ... 212 // The door is attached to .java_pid in the temporary directory. 213 private int openDoor(int pid) throws IOException { 214 socket_path = tmpdir + "/.java_pid" + pid; 215 fd = open(socket_path); 216 217 // Check that the file owner/permission to avoid attaching to 218 // bogus process 219 try { 220 checkPermissions(socket_path); 221 } catch (IOException ioe) { 222 close(fd); 223 throw ioe; 224 } 225 return fd; 226 } ===== src/jdk.attach/solaris/native/libattach/VirtualMachineImpl.c: ... 59 JNIEXPORT jint JNICALL Java_sun_tools_attach_VirtualMachineImpl_open 60 (JNIEnv *env, jclass cls, jstring path) 61 { 62 jboolean isCopy; 63 const char* p = GetStringPlatformChars(env, path, &isCopy); 64 if (p == NULL) { 65 return 0; 66 } else { 67 int fd; 68 int err = 0; 69 70 fd = open(p, O_RDWR); 71 if (fd == -1) { 72 err = errno; 73 } 74 75 if (isCopy) { 76 JNU_ReleaseStringPlatformChars(env, path, p); 77 } 78 79 if (fd == -1) { 80 if (err == ENOENT) { 81 JNU_ThrowByName(env, "java/io/FileNotFoundException", NULL); 82 } else { 83 char* msg = strdup(strerror(err)); 84 JNU_ThrowIOException(env, msg); 85 if (msg != NULL) { 86 free(msg); 87 } 88 } 89 } 90 return fd; 91 } 92 } ... 99 JNIEXPORT void JNICALL Java_sun_tools_attach_VirtualMachineImpl_checkPermissions 100 (JNIEnv *env, jclass cls, jstring path) 101 { 102 jboolean isCopy; 103 const char* p = GetStringPlatformChars(env, path, &isCopy); 104 if (p != NULL) { 105 struct stat64 sb; 106 uid_t uid, gid; 107 int res; 108 109 memset(&sb, 0, sizeof(struct stat64)); 110 111 /* 112 * Check that the path is owned by the effective uid/gid of this 113 * process. Also check that group/other access is not allowed. 114 */ 115 uid = geteuid(); 116 gid = getegid(); 117 118 res = stat64(p, &sb); 119 if (res != 0) { 120 /* save errno */ 121 res = errno; 122 } 123 124 if (res == 0) { 125 char msg[100]; 126 jboolean isError = JNI_FALSE; 127 if (sb.st_uid != uid && uid != ROOT_UID) { 128 snprintf(msg, sizeof(msg), 129 "file should be owned by the current user (which is %d) but is owned by %d", uid, sb.st_uid); 130 isError = JNI_TRUE; 131 } else if (sb.st_gid != gid && uid != ROOT_UID) { 132 snprintf(msg, sizeof(msg), 133 "file's group should be the current group (which is %d) but the group is %d", gid, sb.st_gid); 134 isError = JNI_TRUE; 135 } else if ((sb.st_mode & (S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)) != 0) { 136 snprintf(msg, sizeof(msg), 137 "file should only be readable and writable by the owner but has 0%03o access", sb.st_mode & 0777); 138 isError = JNI_TRUE; 139 } 140 if (isError) { 141 char buf[256]; 142 snprintf(buf, sizeof(buf), "well-known file %s is not secure: %s", p, msg); 143 JNU_ThrowIOException(env, buf); 144 } 145 } else { 146 char* msg = strdup(strerror(res)); 147 JNU_ThrowIOException(env, msg); 148 if (msg != NULL) { 149 free(msg); 150 } 151 } On 10/2/18, 6:23 PM, David Holmes wrote: > Minor correction: EPERM -> EACCES for Solaris > > Hard to see how to get a transient EACCES when opening a file ... > though as it is really a door I guess there could be additional > complexity. > > David > > On 3/10/2018 7:54 AM, Chris Plummer wrote: >> On 10/2/18 2:38 PM, David Holmes wrote: >>> Chris, >>> >>> On 3/10/2018 6:57 AM, Chris Plummer wrote: >>>> >>>> >>>> On 10/2/18 1:44 PM, gary.adams at oracle.com wrote: >>>>> The general attach sequence ... >>>>> >>>>> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>>>> >>>>> >>>>> the attacher creates an attach_pid file in a directory where the >>>>> attachee is runnning >>>>> issues a signal to the attacheee >>>>> >>>>> loops waiting for the java_pid file to be created >>>>> default timeout is 10 seconds >>>>> >>>> So getting a FileNotFoundException while in this loop is OK, but >>>> IOException is not. >>>> >>>>> src/hotspot/os/solaris/attachListener_solaris.cpp >>>>> >>>>> attachee creates the java_pid file >>>>> listens til the attacher opens the door >>>>> >>>> I'm don't think this is related, but JDK-8199811 made a fix in >>>> attachListener_solaris.cpp to make it wait up to 10 seconds for >>>> initialization to complete before failing the enqueue. >>>> >>>>> ... >>>>> Not sure when a bare IOException is thrown rather than the >>>>> more specific FileNotFoundException. >>>> Where is the IOException originating from? I wonder if the issue is >>>> that the file is in the process of being created, but is not fully >>>> created yet. Maybe it is there, but owner/group/permissions have >>>> not been set yet, and this results in an IOException instead of >>>> FileNotFoundException. >>> >>> The exception is shown in the bug report: >>> >>> [java.io.IOException: Permission denied >>> at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native Method) >>> at >>> jdk.attach/sun.tools.attach.VirtualMachineImpl.openDoor(VirtualMachineImpl.java:215) >>> >>> at >>> jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) >>> >>> at >>> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) >>> >>> at >>> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) >>> >>> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) >>> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) >>> >>> And if you look at the native code the EPERM from open will cause >>> IOException to be thrown. >>> >>> ./jdk.attach/solaris/native/libattach/VirtualMachineImpl.c >>> >>> JNIEXPORT jint JNICALL Java_sun_tools_attach_VirtualMachineImpl_open >>> (JNIEnv *env, jclass cls, jstring path) >>> { >>> jboolean isCopy; >>> const char* p = GetStringPlatformChars(env, path, &isCopy); >>> if (p == NULL) { >>> return 0; >>> } else { >>> int fd; >>> int err = 0; >>> >>> fd = open(p, O_RDWR); >>> if (fd == -1) { >>> err = errno; >>> } >>> >>> if (isCopy) { >>> JNU_ReleaseStringPlatformChars(env, path, p); >>> } >>> >>> if (fd == -1) { >>> if (err == ENOENT) { >>> JNU_ThrowByName(env, >>> "java/io/FileNotFoundException", NULL); >>> } else { >>> char* msg = strdup(strerror(err)); >>> JNU_ThrowIOException(env, msg); >>> if (msg != NULL) { >>> free(msg); >>> } >>> >>> >>> We should add the path to the exception message. >>> >> Thanks David. So if EPERM is the error and a retry 100ms later works, >> I think that supports my hypothesis that the file is not quite fully >> created. So Gary's fix is probably fine. The only other possible fix >> I can think of that wouldn't require an explicit delay (or multiple >> retries) is probably not worth the complexity. It would require that >> the attachee create two files, and the attacher try to open the >> second file first. When it either opens or returns EPERM, you know >> the first file can safety be opened. >> >> Chris >>> David >>> ----- >>> >>>> Chris >>>>> >>>>> >>>>> >>>>> On 10/2/18 4:11 PM, Chris Plummer wrote: >>>>>> Can you summarize how the attach handshaking is suppose to work? >>>>>> I'm just wondering why the attacher would ever be looking for the >>>>>> file before the attachee has created it. It seems a proper >>>>>> handshake would prevent this. Maybe there's some sort of >>>>>> visibility issue where the attachee has indeed created the file, >>>>>> but it is not immediately visible to the attacher process. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: >>>>>>> The problem reproduced pretty quickly. >>>>>>> I added a call to checkPermission and revealed the >>>>>>> "file not found" from the stat call when the IOException >>>>>>> was detected. >>>>>>> >>>>>>> There has been some flakiness from the Solaris test machines today, >>>>>>> so I'll continue with the testing a bit longer. >>>>>>> >>>>>>> On 10/2/18 3:12 PM, Chris Plummer wrote: >>>>>>>> Without the fix was this issue easy enough to reproduce that >>>>>>>> you can be sure this is resolving it? >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 10/2/18 8:16 AM, Gary Adams wrote: >>>>>>>>> Solaris debug builds are failing tests that use the attach >>>>>>>>> interface. >>>>>>>>> An IOException is reported when the java_pid file is not opened. >>>>>>>>> >>>>>>>>> It appears that the attempt to attach is taking place too >>>>>>>>> quickly. >>>>>>>>> This workaround will allow the open operation to be retried >>>>>>>>> after a short pause. >>>>>>>>> >>>>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>>>>>>>> >>>>>>>>> Testing is in progress. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Oct 4 16:04:25 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 12:04:25 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> <5BB5FBDC.7080004@oracle.com> <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> Message-ID: <5BB63A09.7060803@oracle.com> We currently use time factor 4 or 10 to scale up the jtreg tests. The change I proposed was already 10x100 = 1000. Since this is just a thread scheduling issue to let the debuggee run til it blocks, it should not require more time to get the switch to take place. If this was a process scheduling issue, then more complex coordination might be worth considering. On 10/4/18, 11:45 AM, Daniel D. Daugherty wrote: > Sleeps don't scale under load. That said, I agree with Chris that > the code is already in place. One possible addition is to scale > the sleep value by the timeout factor for the test. That will > further reduce the likelihood of intermittent failures. > > Dan > > > On 10/4/18 7:39 AM, Gary Adams wrote: >> Oops, wrong comment used in the patch. >> Fresh patch attached. >> >> On 10/4/18, 7:11 AM, Gary Adams wrote: >>> Patch attached. >>> >>> I think one reviewer is sufficient for a trivial patch. >>> >>> On 10/3/18, 4:49 PM, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> Although I don't like relying on timer delays for stuff like this, >>>> the code for it is already in place, so I'm ok with making the >>>> delay longer to make sure there is contention on the monitor. Could >>>> you update the comment to read "// pause to provoke contention on >>>> thread.endingMonitor" >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 10/3/18 11:55 AM, Gary Adams wrote: >>>>> While running a block of nsk/jvmti/scenarios tests, I noticed an >>>>> occasional failure >>>>> for cm02t001 in windows debug platform. After enabling the nsk >>>>> verbose >>>>> diagnostics and adding a few messages in the main test and the >>>>> debuggee >>>>> thread, it became clear that the missing contention was due to the >>>>> main thread >>>>> getting ahead of the debugee thread. >>>>> >>>>> The call to letFinish() below let's the deuggee thread wake up >>>>> from it's wait >>>>> and proceed to the contention for the endingMonitor. If the main >>>>> thread >>>>> waits a little longer it should reach the debuggee thread >>>>> synchronized block. >>>>> >>>>> I reopened an earlier bug that was closed as CNR. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>>>> >>>>> >>>>> diff --git >>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>> >>>>> --- >>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>> +++ >>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>> @@ -82,7 +82,7 @@ >>>>> thread.letFinish(); >>>>> >>>>> // pause to provoke contention >>>>> - Thread.sleep(100); >>>>> + Thread.sleep(1000); >>>>> } catch (InterruptedException e) { >>>>> throw new Failure(e); >>>>> } >>>> >>>> >>> >> > From fairoz.matte at oracle.com Thu Oct 4 16:08:56 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Thu, 4 Oct 2018 16:08:56 +0000 (UTC) Subject: [8u-backport] RFR: JDK-8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <208B3295-90BA-4C6F-96C6-A6069C34DC55@oracle.com> References: <9F06B0E8-A403-44A7-B431-020851706969@oracle.com> <208B3295-90BA-4C6F-96C6-A6069C34DC55@oracle.com> Message-ID: Thanks Daniil... > -----Original Message----- > From: Daniil Titov > Sent: Thursday, October 04, 2018 9:15 PM > To: Fairoz Matte ; serviceability- > dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8163083: SocketListeningConnector does > not allow invocations with port 0 > > Hi Fairoz, > > The backport looks good for me. > > Thanks! > --Daniil > > ?On 10/3/18, 10:28 PM, "serviceability-dev on behalf of Fairoz Matte" > fairoz.matte at oracle.com> wrote: > > Hi, > > Kindly review the backport of "JDK-8163083: SocketListeningConnector > does not allow invocations with port 0" to 8u > > Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8163083 > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/d38cb687d631 > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability- > dev/2018-September/025209.html > > Thanks, > Fairoz > > > > From daniel.daugherty at oracle.com Thu Oct 4 16:13:00 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 4 Oct 2018 12:13:00 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <5BB63A09.7060803@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> <5BB5FBDC.7080004@oracle.com> <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> <5BB63A09.7060803@oracle.com> Message-ID: <74d7b85f-0176-d6b0-cca2-7504e61eb4ac@oracle.com> On 10/4/18 12:04 PM, Gary Adams wrote: > We currently use time factor 4 or 10 to scale up the jtreg tests. > The change I proposed was already 10x100 = 1000. Agreed that you are already bumping it up by 10X. > Since this is just a thread scheduling issue to let the debuggee > run til it blocks, it should not require more time to get the > switch to take place. Are you really trying to say that system load doesn't affect thread scheduling time? > If this was a process scheduling issue, then? more complex > coordination might be worth considering. System load doesn't just affect process scheduling. It also affects thread scheduling. If all the cores are busy, then running another thread or another process is impacted. In any case, I wasn't clear in my suggestion. -??????????????? Thread.sleep(100); +??????????????? Thread.sleep(100 * timeoutFactor); assuming there is some easy way to get access to the -timeoutFactor parameter. Dan > > On 10/4/18, 11:45 AM, Daniel D. Daugherty wrote: >> Sleeps don't scale under load. That said, I agree with Chris that >> the code is already in place. One possible addition is to scale >> the sleep value by the timeout factor for the test. That will >> further reduce the likelihood of intermittent failures. >> >> Dan >> >> >> On 10/4/18 7:39 AM, Gary Adams wrote: >>> Oops, wrong comment used in the patch. >>> Fresh patch attached. >>> >>> On 10/4/18, 7:11 AM, Gary Adams wrote: >>>> Patch attached. >>>> >>>> I think one reviewer is sufficient for a trivial patch. >>>> >>>> On 10/3/18, 4:49 PM, Chris Plummer wrote: >>>>> Hi Gary, >>>>> >>>>> Although I don't like relying on timer delays for stuff like this, >>>>> the code for it is already in place, so I'm ok with making the >>>>> delay longer to make sure there is contention on the monitor. >>>>> Could you update the comment to read "// pause to provoke >>>>> contention on thread.endingMonitor" >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 10/3/18 11:55 AM, Gary Adams wrote: >>>>>> While running a block of nsk/jvmti/scenarios tests, I noticed an >>>>>> occasional failure >>>>>> for cm02t001 in windows debug platform. After enabling the nsk >>>>>> verbose >>>>>> diagnostics and adding a few messages in the main test and the >>>>>> debuggee >>>>>> thread, it became clear that the missing contention was due to >>>>>> the main thread >>>>>> getting ahead of the debugee thread. >>>>>> >>>>>> The call to letFinish() below let's the deuggee thread wake up >>>>>> from it's wait >>>>>> and proceed to the contention for the endingMonitor. If the main >>>>>> thread >>>>>> waits a little longer it should reach the debuggee thread >>>>>> synchronized block. >>>>>> >>>>>> I reopened an earlier bug that was closed as CNR. >>>>>> >>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>>>>> >>>>>> >>>>>> diff --git >>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>> >>>>>> --- >>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>> +++ >>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>> @@ -82,7 +82,7 @@ >>>>>> ???????????????? thread.letFinish(); >>>>>> >>>>>> ???????????????? // pause to provoke contention >>>>>> -??????????????? Thread.sleep(100); >>>>>> +??????????????? Thread.sleep(1000); >>>>>> ???????????? } catch (InterruptedException e) { >>>>>> ???????????????? throw new Failure(e); >>>>>> ???????????? } >>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Oct 4 16:20:50 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 4 Oct 2018 09:20:50 -0700 Subject: [8u-backport] RFR: JDK-8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: <208B3295-90BA-4C6F-96C6-A6069C34DC55@oracle.com> References: <9F06B0E8-A403-44A7-B431-020851706969@oracle.com> <208B3295-90BA-4C6F-96C6-A6069C34DC55@oracle.com> Message-ID: Hi Daniil, You have to post your review on 8 update mailing list. But if I remember correctly Fairoz already got a review. Fairoz, please, correct me if needed. Thanks, Serguei On 10/4/18 08:45, Daniil Titov wrote: > Hi Fairoz, > > The backport looks good for me. > > Thanks! > --Daniil > > ?On 10/3/18, 10:28 PM, "serviceability-dev on behalf of Fairoz Matte" wrote: > > Hi, > > Kindly review the backport of "JDK-8163083: SocketListeningConnector does not allow invocations with port 0" to 8u > > Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8163083 > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/d38cb687d631 > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-September/025209.html > > Thanks, > Fairoz > > > > From chris.plummer at oracle.com Thu Oct 4 16:30:56 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 4 Oct 2018 09:30:56 -0700 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <5BB637A6.6010008@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> <957abd42-1b68-7395-e495-5d50fb3a786e@oracle.com> <5BB637A6.6010008@oracle.com> Message-ID: <7115147a-2aae-d168-2db5-d1914837f050@oracle.com> An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Oct 4 16:48:07 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 12:48:07 -0400 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <7115147a-2aae-d168-2db5-d1914837f050@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> <957abd42-1b68-7395-e495-5d50fb3a786e@oracle.com> <5BB637A6.6010008@oracle.com> <7115147a-2aae-d168-2db5-d1914837f050@oracle.com> Message-ID: <5BB64447.4090408@oracle.com> My delay and retry just duplicated the openDoor retry. The normal processing of FileNotFoundException(ENOENT) is to retry several times until the file is available. But the original problem reported is a "Permission denied" (EACCESS or EPERM). Delay and retry will not resolve a permissions error. On 10/4/18, 12:30 PM, Chris Plummer wrote: > Didn't the retry after 100ms delay work? If yes, why would it if the > problem is that a java_pid was not cleaned up? > > Chris > > On 10/4/18 8:54 AM, Gary Adams wrote: >> First, let me retract the proposed change, >> it is not the right solution to the problem originally >> reported. >> >> Second, as a bit of explanation consider the code fragments below. >> >> The high level processing calls openDoor which is willing to retry >> the operation as long as the error is flagged specifically >> as a FileNotFoundException. >> >> VirtualMachineImpl.java:72 >> VirtualMachineImpl.c:81 >> >> During my testing I had added a check VirtualMachineImpl.java:214 >> and when an IOException was detected made a call to checkPermissions >> to get more detailed information about the IOException. The error >> I saw was an ENOENT from the stat call. And not the detailed checks for >> specific permissions issues (VirtualMachineImpl.c:143) >> >> VirtualMachineImpl.c:118 >> VirtualMachineImpl.c:147 >> >> What I missed in the original proposed solution was a >> FileNotFoundException >> extends IOException. That means my delay and retry just duplicates >> the higher >> level retry around the openDoor call. >> >> Third, the original error message logged in the bug report : >> >> java.io.IOException: Permission denied >> at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native Method) >> >> had to have come from >> >> VirtualMachineImpl.c:70 >> VirtualMachineImpl.c:84 >> >> which means the actual open call reported the file does exist >> but the permissions do not allow the file to be accessed. >> That also means the normal mechanism of removing leftover >> java_pid files would not have cleaned up another user's >> java_pid files. >> >> ===== >> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java: >> ... >> 67 // Opens the door file to the target VM. If the >> file is not >> 68 // found it might mean that the attach mechanism >> isn't started in the >> 69 // target VM so we attempt to start it and retry. >> 70 try { >> 71 fd = openDoor(pid); >> 72 } catch (FileNotFoundException fnf1) { >> 73 File f = createAttachFile(pid); >> 74 try { >> 75 sigquit(pid); >> 76 >> 77 // give the target VM time to start the >> attach mechanism >> 78 final int delay_step = 100; >> 79 final long timeout = attachTimeout(); >> 80 long time_spend = 0; >> 81 long delay = 0; >> 82 do { >> 83 // Increase timeout on each attempt to >> reduce polling >> 84 delay += delay_step; >> 85 try { >> 86 Thread.sleep(delay); >> 87 } catch (InterruptedException x) { } >> 88 try { >> 89 fd = openDoor(pid); >> 90 } catch (FileNotFoundException fnf2) { >> 91 // pass >> 92 } >> 93 >> 94 time_spend += delay; >> 95 if (time_spend > timeout/2 && fd == -1) { >> 96 // Send QUIT again to give target >> VM the last chance to react >> 97 sigquit(pid); >> 98 } >> 99 } while (time_spend <= timeout && fd == -1); >> 100 if (fd == -1) { >> 101 throw new AttachNotSupportedException( >> 102 String.format("Unable to open door >> %s: " + >> 103 "target process %d doesn't >> respond within %dms " + >> 104 "or HotSpot VM not loaded", >> socket_path, pid, time_spend)); >> 105 } >> ... >> 212 // The door is attached to .java_pid in the >> temporary directory. >> 213 private int openDoor(int pid) throws IOException { >> 214 socket_path = tmpdir + "/.java_pid" + pid; >> 215 fd = open(socket_path); >> 216 >> 217 // Check that the file owner/permission to avoid >> attaching to >> 218 // bogus process >> 219 try { >> 220 checkPermissions(socket_path); >> 221 } catch (IOException ioe) { >> 222 close(fd); >> 223 throw ioe; >> 224 } >> 225 return fd; >> 226 } >> >> ===== >> src/jdk.attach/solaris/native/libattach/VirtualMachineImpl.c: >> ... >> 59 JNIEXPORT jint JNICALL >> Java_sun_tools_attach_VirtualMachineImpl_open >> 60 (JNIEnv *env, jclass cls, jstring path) >> 61 { >> 62 jboolean isCopy; >> 63 const char* p = GetStringPlatformChars(env, path, &isCopy); >> 64 if (p == NULL) { >> 65 return 0; >> 66 } else { >> 67 int fd; >> 68 int err = 0; >> 69 >> 70 fd = open(p, O_RDWR); >> 71 if (fd == -1) { >> 72 err = errno; >> 73 } >> 74 >> 75 if (isCopy) { >> 76 JNU_ReleaseStringPlatformChars(env, path, p); >> 77 } >> 78 >> 79 if (fd == -1) { >> 80 if (err == ENOENT) { >> 81 JNU_ThrowByName(env, >> "java/io/FileNotFoundException", NULL); >> 82 } else { >> 83 char* msg = strdup(strerror(err)); >> 84 JNU_ThrowIOException(env, msg); >> 85 if (msg != NULL) { >> 86 free(msg); >> 87 } >> 88 } >> 89 } >> 90 return fd; >> 91 } >> 92 } >> ... >> 99 JNIEXPORT void JNICALL >> Java_sun_tools_attach_VirtualMachineImpl_checkPermissions >> 100 (JNIEnv *env, jclass cls, jstring path) >> 101 { >> 102 jboolean isCopy; >> 103 const char* p = GetStringPlatformChars(env, path, &isCopy); >> 104 if (p != NULL) { >> 105 struct stat64 sb; >> 106 uid_t uid, gid; >> 107 int res; >> 108 >> 109 memset(&sb, 0, sizeof(struct stat64)); >> 110 >> 111 /* >> 112 * Check that the path is owned by the effective >> uid/gid of this >> 113 * process. Also check that group/other access is >> not allowed. >> 114 */ >> 115 uid = geteuid(); >> 116 gid = getegid(); >> 117 >> 118 res = stat64(p, &sb); >> 119 if (res != 0) { >> 120 /* save errno */ >> 121 res = errno; >> 122 } >> 123 >> 124 if (res == 0) { >> 125 char msg[100]; >> 126 jboolean isError = JNI_FALSE; >> 127 if (sb.st_uid != uid && uid != ROOT_UID) { >> 128 snprintf(msg, sizeof(msg), >> 129 "file should be owned by the current >> user (which is %d) but is owned by %d", uid, sb.st_uid); >> 130 isError = JNI_TRUE; >> 131 } else if (sb.st_gid != gid && uid != ROOT_UID) { >> 132 snprintf(msg, sizeof(msg), >> 133 "file's group should be the current >> group (which is %d) but the group is %d", gid, sb.st_gid); >> 134 isError = JNI_TRUE; >> 135 } else if ((sb.st_mode & >> (S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)) != 0) { >> 136 snprintf(msg, sizeof(msg), >> 137 "file should only be readable and >> writable by the owner but has 0%03o access", sb.st_mode & 0777); >> 138 isError = JNI_TRUE; >> 139 } >> 140 if (isError) { >> 141 char buf[256]; >> 142 snprintf(buf, sizeof(buf), "well-known file >> %s is not secure: %s", p, msg); >> 143 JNU_ThrowIOException(env, buf); >> 144 } >> 145 } else { >> 146 char* msg = strdup(strerror(res)); >> 147 JNU_ThrowIOException(env, msg); >> 148 if (msg != NULL) { >> 149 free(msg); >> 150 } >> 151 } >> >> On 10/2/18, 6:23 PM, David Holmes wrote: >>> Minor correction: EPERM -> EACCES for Solaris >>> >>> Hard to see how to get a transient EACCES when opening a file ... >>> though as it is really a door I guess there could be additional >>> complexity. >>> >>> David >>> >>> On 3/10/2018 7:54 AM, Chris Plummer wrote: >>>> On 10/2/18 2:38 PM, David Holmes wrote: >>>>> Chris, >>>>> >>>>> On 3/10/2018 6:57 AM, Chris Plummer wrote: >>>>>> >>>>>> >>>>>> On 10/2/18 1:44 PM, gary.adams at oracle.com wrote: >>>>>>> The general attach sequence ... >>>>>>> >>>>>>> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>> >>>>>>> >>>>>>> the attacher creates an attach_pid file in a directory where >>>>>>> the attachee is runnning >>>>>>> issues a signal to the attacheee >>>>>>> >>>>>>> loops waiting for the java_pid file to be created >>>>>>> default timeout is 10 seconds >>>>>>> >>>>>> So getting a FileNotFoundException while in this loop is OK, but >>>>>> IOException is not. >>>>>> >>>>>>> src/hotspot/os/solaris/attachListener_solaris.cpp >>>>>>> >>>>>>> attachee creates the java_pid file >>>>>>> listens til the attacher opens the door >>>>>>> >>>>>> I'm don't think this is related, but JDK-8199811 made a fix in >>>>>> attachListener_solaris.cpp to make it wait up to 10 seconds for >>>>>> initialization to complete before failing the enqueue. >>>>>> >>>>>>> ... >>>>>>> Not sure when a bare IOException is thrown rather than the >>>>>>> more specific FileNotFoundException. >>>>>> Where is the IOException originating from? I wonder if the issue >>>>>> is that the file is in the process of being created, but is not >>>>>> fully created yet. Maybe it is there, but owner/group/permissions >>>>>> have not been set yet, and this results in an IOException instead >>>>>> of FileNotFoundException. >>>>> >>>>> The exception is shown in the bug report: >>>>> >>>>> [java.io.IOException: Permission denied >>>>> at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native Method) >>>>> at >>>>> jdk.attach/sun.tools.attach.VirtualMachineImpl.openDoor(VirtualMachineImpl.java:215) >>>>> >>>>> at >>>>> jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) >>>>> >>>>> at >>>>> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) >>>>> >>>>> at >>>>> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) >>>>> >>>>> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) >>>>> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) >>>>> >>>>> And if you look at the native code the EPERM from open will cause >>>>> IOException to be thrown. >>>>> >>>>> ./jdk.attach/solaris/native/libattach/VirtualMachineImpl.c >>>>> >>>>> JNIEXPORT jint JNICALL Java_sun_tools_attach_VirtualMachineImpl_open >>>>> (JNIEnv *env, jclass cls, jstring path) >>>>> { >>>>> jboolean isCopy; >>>>> const char* p = GetStringPlatformChars(env, path, &isCopy); >>>>> if (p == NULL) { >>>>> return 0; >>>>> } else { >>>>> int fd; >>>>> int err = 0; >>>>> >>>>> fd = open(p, O_RDWR); >>>>> if (fd == -1) { >>>>> err = errno; >>>>> } >>>>> >>>>> if (isCopy) { >>>>> JNU_ReleaseStringPlatformChars(env, path, p); >>>>> } >>>>> >>>>> if (fd == -1) { >>>>> if (err == ENOENT) { >>>>> JNU_ThrowByName(env, >>>>> "java/io/FileNotFoundException", NULL); >>>>> } else { >>>>> char* msg = strdup(strerror(err)); >>>>> JNU_ThrowIOException(env, msg); >>>>> if (msg != NULL) { >>>>> free(msg); >>>>> } >>>>> >>>>> >>>>> We should add the path to the exception message. >>>>> >>>> Thanks David. So if EPERM is the error and a retry 100ms later >>>> works, I think that supports my hypothesis that the file is not >>>> quite fully created. So Gary's fix is probably fine. The only other >>>> possible fix I can think of that wouldn't require an explicit delay >>>> (or multiple retries) is probably not worth the complexity. It >>>> would require that the attachee create two files, and the attacher >>>> try to open the second file first. When it either opens or returns >>>> EPERM, you know the first file can safety be opened. >>>> >>>> Chris >>>>> David >>>>> ----- >>>>> >>>>>> Chris >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10/2/18 4:11 PM, Chris Plummer wrote: >>>>>>>> Can you summarize how the attach handshaking is suppose to >>>>>>>> work? I'm just wondering why the attacher would ever be looking >>>>>>>> for the file before the attachee has created it. It seems a >>>>>>>> proper handshake would prevent this. Maybe there's some sort of >>>>>>>> visibility issue where the attachee has indeed created the >>>>>>>> file, but it is not immediately visible to the attacher process. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: >>>>>>>>> The problem reproduced pretty quickly. >>>>>>>>> I added a call to checkPermission and revealed the >>>>>>>>> "file not found" from the stat call when the IOException >>>>>>>>> was detected. >>>>>>>>> >>>>>>>>> There has been some flakiness from the Solaris test machines >>>>>>>>> today, >>>>>>>>> so I'll continue with the testing a bit longer. >>>>>>>>> >>>>>>>>> On 10/2/18 3:12 PM, Chris Plummer wrote: >>>>>>>>>> Without the fix was this issue easy enough to reproduce that >>>>>>>>>> you can be sure this is resolving it? >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 10/2/18 8:16 AM, Gary Adams wrote: >>>>>>>>>>> Solaris debug builds are failing tests that use the attach >>>>>>>>>>> interface. >>>>>>>>>>> An IOException is reported when the java_pid file is not >>>>>>>>>>> opened. >>>>>>>>>>> >>>>>>>>>>> It appears that the attempt to attach is taking place too >>>>>>>>>>> quickly. >>>>>>>>>>> This workaround will allow the open operation to be retried >>>>>>>>>>> after a short pause. >>>>>>>>>>> >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>>>>>>>>>> >>>>>>>>>>> Testing is in progress. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Oct 4 17:00:27 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 13:00:27 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <74d7b85f-0176-d6b0-cca2-7504e61eb4ac@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> <5BB5FBDC.7080004@oracle.com> <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> <5BB63A09.7060803@oracle.com> <74d7b85f-0176-d6b0-cca2-7504e61eb4ac@oracle.com> Message-ID: <5BB6472B.7000100@oracle.com> On 10/4/18, 12:13 PM, Daniel D. Daugherty wrote: > On 10/4/18 12:04 PM, Gary Adams wrote: >> We currently use time factor 4 or 10 to scale up the jtreg tests. >> The change I proposed was already 10x100 = 1000. > > Agreed that you are already bumping it up by 10X. > > >> Since this is just a thread scheduling issue to let the debuggee >> run til it blocks, it should not require more time to get the >> switch to take place. > > Are you really trying to say that system load doesn't affect > thread scheduling time? In this particular test, the main thread and the debuggee thread are toggling back and forth around several monitors and synchronized code blocks. Not sure the tests are written for an arbitrarily high system load. > >> If this was a process scheduling issue, then more complex >> coordination might be worth considering. > > System load doesn't just affect process scheduling. It also > affects thread scheduling. If all the cores are busy, then > running another thread or another process is impacted. > > > In any case, I wasn't clear in my suggestion. > > - Thread.sleep(100); > + Thread.sleep(100 * timeoutFactor); > > assuming there is some easy way to get access to the -timeoutFactor > parameter. Currently, timeoutFactor has not been introduced to the vmTestbase/nsk test suite. > > Dan > > > >> >> On 10/4/18, 11:45 AM, Daniel D. Daugherty wrote: >>> Sleeps don't scale under load. That said, I agree with Chris that >>> the code is already in place. One possible addition is to scale >>> the sleep value by the timeout factor for the test. That will >>> further reduce the likelihood of intermittent failures. >>> >>> Dan >>> >>> >>> On 10/4/18 7:39 AM, Gary Adams wrote: >>>> Oops, wrong comment used in the patch. >>>> Fresh patch attached. >>>> >>>> On 10/4/18, 7:11 AM, Gary Adams wrote: >>>>> Patch attached. >>>>> >>>>> I think one reviewer is sufficient for a trivial patch. >>>>> >>>>> On 10/3/18, 4:49 PM, Chris Plummer wrote: >>>>>> Hi Gary, >>>>>> >>>>>> Although I don't like relying on timer delays for stuff like >>>>>> this, the code for it is already in place, so I'm ok with making >>>>>> the delay longer to make sure there is contention on the monitor. >>>>>> Could you update the comment to read "// pause to provoke >>>>>> contention on thread.endingMonitor" >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 10/3/18 11:55 AM, Gary Adams wrote: >>>>>>> While running a block of nsk/jvmti/scenarios tests, I noticed an >>>>>>> occasional failure >>>>>>> for cm02t001 in windows debug platform. After enabling the nsk >>>>>>> verbose >>>>>>> diagnostics and adding a few messages in the main test and the >>>>>>> debuggee >>>>>>> thread, it became clear that the missing contention was due to >>>>>>> the main thread >>>>>>> getting ahead of the debugee thread. >>>>>>> >>>>>>> The call to letFinish() below let's the deuggee thread wake up >>>>>>> from it's wait >>>>>>> and proceed to the contention for the endingMonitor. If the main >>>>>>> thread >>>>>>> waits a little longer it should reach the debuggee thread >>>>>>> synchronized block. >>>>>>> >>>>>>> I reopened an earlier bug that was closed as CNR. >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>>>>>> >>>>>>> >>>>>>> diff --git >>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>> >>>>>>> --- >>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>> +++ >>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>> @@ -82,7 +82,7 @@ >>>>>>> thread.letFinish(); >>>>>>> >>>>>>> // pause to provoke contention >>>>>>> - Thread.sleep(100); >>>>>>> + Thread.sleep(1000); >>>>>>> } catch (InterruptedException e) { >>>>>>> throw new Failure(e); >>>>>>> } >>>>>> >>>>>> >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Thu Oct 4 17:03:12 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 4 Oct 2018 13:03:12 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <5BB6472B.7000100@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> <5BB5FBDC.7080004@oracle.com> <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> <5BB63A09.7060803@oracle.com> <74d7b85f-0176-d6b0-cca2-7504e61eb4ac@oracle.com> <5BB6472B.7000100@oracle.com> Message-ID: <30c4d83c-4f51-bf55-837a-15bcb7df8dc0@oracle.com> On 10/4/18 1:00 PM, Gary Adams wrote: > On 10/4/18, 12:13 PM, Daniel D. Daugherty wrote: >> On 10/4/18 12:04 PM, Gary Adams wrote: >>> We currently use time factor 4 or 10 to scale up the jtreg tests. >>> The change I proposed was already 10x100 = 1000. >> >> Agreed that you are already bumping it up by 10X. >> >> >>> Since this is just a thread scheduling issue to let the debuggee >>> run til it blocks, it should not require more time to get the >>> switch to take place. >> >> Are you really trying to say that system load doesn't affect >> thread scheduling time? > In this particular test, the main thread and the debuggee thread > are toggling back and forth around several monitors and > synchronized code blocks. Not sure the tests are written > for an arbitrarily high system load. >> >>> If this was a process scheduling issue, then? more complex >>> coordination might be worth considering. >> >> System load doesn't just affect process scheduling. It also >> affects thread scheduling. If all the cores are busy, then >> running another thread or another process is impacted. >> >> >> In any case, I wasn't clear in my suggestion. >> >> -??????????????? Thread.sleep(100); >> +??????????????? Thread.sleep(100 * timeoutFactor); >> >> assuming there is some easy way to get access to the -timeoutFactor >> parameter. > Currently, timeoutFactor has not been introduced to the vmTestbase/nsk > test suite. Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG so it is already supported in the test harness that is uses to run the vmTestbase/nsk test suite... What am I missing here? Dan >> >> Dan >> >> >> >>> >>> On 10/4/18, 11:45 AM, Daniel D. Daugherty wrote: >>>> Sleeps don't scale under load. That said, I agree with Chris that >>>> the code is already in place. One possible addition is to scale >>>> the sleep value by the timeout factor for the test. That will >>>> further reduce the likelihood of intermittent failures. >>>> >>>> Dan >>>> >>>> >>>> On 10/4/18 7:39 AM, Gary Adams wrote: >>>>> Oops, wrong comment used in the patch. >>>>> Fresh patch attached. >>>>> >>>>> On 10/4/18, 7:11 AM, Gary Adams wrote: >>>>>> Patch attached. >>>>>> >>>>>> I think one reviewer is sufficient for a trivial patch. >>>>>> >>>>>> On 10/3/18, 4:49 PM, Chris Plummer wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> Although I don't like relying on timer delays for stuff like >>>>>>> this, the code for it is already in place, so I'm ok with making >>>>>>> the delay longer to make sure there is contention on the >>>>>>> monitor. Could you update the comment to read "// pause to >>>>>>> provoke contention on thread.endingMonitor" >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 10/3/18 11:55 AM, Gary Adams wrote: >>>>>>>> While running a block of nsk/jvmti/scenarios tests, I noticed >>>>>>>> an occasional failure >>>>>>>> for cm02t001 in windows debug platform. After enabling the nsk >>>>>>>> verbose >>>>>>>> diagnostics and adding a few messages in the main test and the >>>>>>>> debuggee >>>>>>>> thread, it became clear that the missing contention was due to >>>>>>>> the main thread >>>>>>>> getting ahead of the debugee thread. >>>>>>>> >>>>>>>> The call to letFinish() below let's the deuggee thread wake up >>>>>>>> from it's wait >>>>>>>> and proceed to the contention for the endingMonitor. If the >>>>>>>> main thread >>>>>>>> waits a little longer it should reach the debuggee thread >>>>>>>> synchronized block. >>>>>>>> >>>>>>>> I reopened an earlier bug that was closed as CNR. >>>>>>>> >>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>>>>>>> >>>>>>>> >>>>>>>> diff --git >>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>> >>>>>>>> --- >>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>> +++ >>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>> @@ -82,7 +82,7 @@ >>>>>>>> ???????????????? thread.letFinish(); >>>>>>>> >>>>>>>> ???????????????? // pause to provoke contention >>>>>>>> -??????????????? Thread.sleep(100); >>>>>>>> +??????????????? Thread.sleep(1000); >>>>>>>> ???????????? } catch (InterruptedException e) { >>>>>>>> ???????????????? throw new Failure(e); >>>>>>>> ???????????? } >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Oct 4 17:17:25 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 4 Oct 2018 10:17:25 -0700 Subject: [8u-backport] RFR: JDK-8163083: SocketListeningConnector does not allow invocations with port 0 In-Reply-To: References: <9F06B0E8-A403-44A7-B431-020851706969@oracle.com> <208B3295-90BA-4C6F-96C6-A6069C34DC55@oracle.com> Message-ID: <274df1d2-7abf-850c-c6aa-08a2e48c6832@oracle.com> On 10/4/18 09:20, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > You have to post your review on 8 update mailing list. > But if I remember correctly Fairoz already got a review. The above is wrong - sorry for the noise. Thanks, Serguei > Fairoz, please, correct me if needed. > > Thanks, > Serguei > > On 10/4/18 08:45, Daniil Titov wrote: >> Hi Fairoz, >> >> The backport looks good for me. >> >> Thanks! >> --Daniil >> >> ?On 10/3/18, 10:28 PM, "serviceability-dev on behalf of Fairoz Matte" >> > fairoz.matte at oracle.com> wrote: >> >> ???? Hi, >> ???? ???? Kindly review the backport of "JDK-8163083: >> SocketListeningConnector does not allow invocations with port 0" to 8u >> ???? ???? Webrev - http://cr.openjdk.java.net/~fmatte/8163083/webrev.00/ >> ???? ???? JBS bug - https://bugs.openjdk.java.net/browse/JDK-8163083 >> ???? ???? JDK12 changeset - >> http://hg.openjdk.java.net/jdk/jdk/rev/d38cb687d631 >> ???? ???? Review thread - >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-September/025209.html >> ???? ???? Thanks, >> ???? Fairoz >> >> > From chris.plummer at oracle.com Thu Oct 4 17:25:14 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 4 Oct 2018 10:25:14 -0700 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <5BB64447.4090408@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> <957abd42-1b68-7395-e495-5d50fb3a786e@oracle.com> <5BB637A6.6010008@oracle.com> <7115147a-2aae-d168-2db5-d1914837f050@oracle.com> <5BB64447.4090408@oracle.com> Message-ID: <339eed9a-21e8-2a19-7a38-672d748d4d8a@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Oct 4 17:28:54 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 4 Oct 2018 10:28:54 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <5BB60397.7050807@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> Message-ID: <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> On 10/4/18 5:12 AM, Gary Adams wrote: > In TTY.java do you need to force a simple prompt for the > breakpoint event output? What prevents currentThread from > being set at the time you are printing the prompt? > > > ?103???????? // Print the prompt if suspend policy is > SUSPEND_EVENT_THREAD. In case of > ?104???????? // SUSPEND_ALL policy this is handled by vmInterrupted() > method. > ?105???????? if (be.request().suspendPolicy() == > EventRequest.SUSPEND_EVENT_THREAD) { > ?106???????????? MessageOutput.println(); > ?107???????????? MessageOutput.printPrompt(); Normally the thread is suspended after the above code is executed: ??? public void run() { ??????? EventQueue queue = Env.vm().eventQueue(); ??????? while (connected) { ??????????? try { ??????????????? EventSet eventSet = queue.remove(); ??????????????? boolean resumeStoppedApp = false; ??????????????? EventIterator it = eventSet.eventIterator(); ??????????????? while (it.hasNext()) { ??????????????????? resumeStoppedApp |= !handleEvent(it.nextEvent()); <--- calls the modified code above ??????????????? } ??????????????? if (resumeStoppedApp) { ??????????????????? eventSet.resume(); ??????????????? } else if (eventSet.suspendPolicy() == EventRequest.SUSPEND_ALL) { ??????????????????? setCurrentThread(eventSet);?? <------ ??????????????????? notifier.vmInterrupted(); ??????????????? } However, it only calls setCurrentThread() for SUSPEND_ALL policies. So what Daniil has done here is make it print a simple prompt if the policy is SUSPEND_EVENT_THREAD. It's unclear to me what the actual debugger behavior is in this case. Don't we still suspend and get a prompt from which we can type in the next command? In this case, wouldn't you want a full prompt? Related to that question, why is vmInterrupted() only called if we suspend all threads, and not when we just suspend the thread that the breakpoint came in on? Chris > > > In Jdb.java you allow the waiting for the simple prompt. > I don't see waitForSimplePrompt used in any existing tests. > Since it is only looking for a single character it could > produce false positives if the '>' was produced in the > output stream. Is this wait paired to the added prompt for the > break point event? > > ?236???????? return waitForSimplePrompt ? waitForSimplePrompt(1, > cmd.allowExit) : waitForPrompt(1, cmd.allowExit); > > It might be a good idea to include a test with multiple > threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD > behavior. > > On 10/4/18, 12:29 AM, Daniil Titov wrote: >> Please review the changes that fix the deadlock in the debugger when >> the debugger is running with the tracing option on. >> >> The problem here is that when the tracing is on the "JDI Target VM >> Interface" thread (the thread that reads all replies and then >> notifies the thread that sent the request that the reply has been >> received) is waiting for a lock which is already acquired by the >> thread that sent the request and is waiting for reply. >> >> The fix itself is in >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >> >> The patch also reverts the changes done in 8129348 "Debugger hangs in >> trace mode with TRACE_SENDS" in >> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >> since they address only a specific case (VM is suspended and static >> method is invoked) while the proposed fix also solves issue 8129348 >> as well as issue 8193801 "Debugger hangs in trace mode for non-static >> methods". >> >> The changes include new tests for issues 8193879, 8193801 and 8129348. >> >> The changes in >> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >> solve the problem that the prompt is not printed in the debugger >> output when the breakpoint is hit and the suspend policy is >> SUSPEND_EVENT_THREAD. This is required for new tests to detect that >> command "stop thread at ..." is completed. >> >> Mach5 build and jdk_jdi tests succeeded. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >> >> Thanks, >> --Daniil >> >> >> > From gary.adams at oracle.com Thu Oct 4 17:49:35 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 13:49:35 -0400 Subject: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr In-Reply-To: <339eed9a-21e8-2a19-7a38-672d748d4d8a@oracle.com> References: <5BB38BB8.3040601@oracle.com> <6da06518-9fa9-f981-cbfb-cd98967fc264@oracle.com> <291fa9e2-a535-5c4f-aa9d-504aebd1678c@oracle.com> <7484db78-4e80-7136-8ea9-9c932b66a05d@oracle.com> <2ed39ddf-28df-f181-1ad7-c16a6bda47ac@oracle.com> <9c2e4a37-0a91-0384-88ae-42b81de2a8c2@oracle.com> <957abd42-1b68-7395-e495-5d50fb3a786e@oracle.com> <5BB637A6.6010008@oracle.com> <7115147a-2aae-d168-2db5-d1914837f050@oracle.com> <5BB64447.4090408@oracle.com> <339eed9a-21e8-2a19-7a38-672d748d4d8a@oracle.com> Message-ID: <5BB652AF.9000207@oracle.com> My delay and retry did not fix the problem with permission denied. When I was diagnosing the problem I instrumented the code to catch an IOException and call checkPermission to get more detail about the IOException. The error reported from calling checkPermission was ENOENT (stat). The code change I then proposed was catch the IOException, delay, and retry the open. That fixed the problem of ENOENT, but had nothing to do with "permission denied". On 10/4/18, 1:25 PM, Chris Plummer wrote: > But I also thought you said the delay and retry fixed the problem. How > could fix the problem if it is just duplicating something that is > already in place? > > Chris > > On 10/4/18 9:48 AM, Gary Adams wrote: >> My delay and retry just duplicated the openDoor retry. >> The normal processing of FileNotFoundException(ENOENT) is to retry >> several times until the file is available. >> >> But the original problem reported is a "Permission denied" (EACCESS >> or EPERM). >> Delay and retry will not resolve a permissions error. >> >> On 10/4/18, 12:30 PM, Chris Plummer wrote: >>> Didn't the retry after 100ms delay work? If yes, why would it if the >>> problem is that a java_pid was not cleaned up? >>> >>> Chris >>> >>> On 10/4/18 8:54 AM, Gary Adams wrote: >>>> First, let me retract the proposed change, >>>> it is not the right solution to the problem originally >>>> reported. >>>> >>>> Second, as a bit of explanation consider the code fragments below. >>>> >>>> The high level processing calls openDoor which is willing to retry >>>> the operation as long as the error is flagged specifically >>>> as a FileNotFoundException. >>>> >>>> VirtualMachineImpl.java:72 >>>> VirtualMachineImpl.c:81 >>>> >>>> During my testing I had added a check VirtualMachineImpl.java:214 >>>> and when an IOException was detected made a call to checkPermissions >>>> to get more detailed information about the IOException. The error >>>> I saw was an ENOENT from the stat call. And not the detailed checks for >>>> specific permissions issues (VirtualMachineImpl.c:143) >>>> >>>> VirtualMachineImpl.c:118 >>>> VirtualMachineImpl.c:147 >>>> >>>> What I missed in the original proposed solution was a >>>> FileNotFoundException >>>> extends IOException. That means my delay and retry just duplicates >>>> the higher >>>> level retry around the openDoor call. >>>> >>>> Third, the original error message logged in the bug report : >>>> >>>> java.io.IOException: Permission denied >>>> at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native Method) >>>> >>>> had to have come from >>>> >>>> VirtualMachineImpl.c:70 >>>> VirtualMachineImpl.c:84 >>>> >>>> which means the actual open call reported the file does exist >>>> but the permissions do not allow the file to be accessed. >>>> That also means the normal mechanism of removing leftover >>>> java_pid files would not have cleaned up another user's >>>> java_pid files. >>>> >>>> ===== >>>> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java: >>>> ... >>>> 67 // Opens the door file to the target VM. If the >>>> file is not >>>> 68 // found it might mean that the attach mechanism >>>> isn't started in the >>>> 69 // target VM so we attempt to start it and retry. >>>> 70 try { >>>> 71 fd = openDoor(pid); >>>> 72 } catch (FileNotFoundException fnf1) { >>>> 73 File f = createAttachFile(pid); >>>> 74 try { >>>> 75 sigquit(pid); >>>> 76 >>>> 77 // give the target VM time to start the >>>> attach mechanism >>>> 78 final int delay_step = 100; >>>> 79 final long timeout = attachTimeout(); >>>> 80 long time_spend = 0; >>>> 81 long delay = 0; >>>> 82 do { >>>> 83 // Increase timeout on each attempt >>>> to reduce polling >>>> 84 delay += delay_step; >>>> 85 try { >>>> 86 Thread.sleep(delay); >>>> 87 } catch (InterruptedException x) { } >>>> 88 try { >>>> 89 fd = openDoor(pid); >>>> 90 } catch (FileNotFoundException fnf2) { >>>> 91 // pass >>>> 92 } >>>> 93 >>>> 94 time_spend += delay; >>>> 95 if (time_spend > timeout/2 && fd == -1) { >>>> 96 // Send QUIT again to give target >>>> VM the last chance to react >>>> 97 sigquit(pid); >>>> 98 } >>>> 99 } while (time_spend <= timeout && fd == -1); >>>> 100 if (fd == -1) { >>>> 101 throw new AttachNotSupportedException( >>>> 102 String.format("Unable to open >>>> door %s: " + >>>> 103 "target process %d doesn't >>>> respond within %dms " + >>>> 104 "or HotSpot VM not loaded", >>>> socket_path, pid, time_spend)); >>>> 105 } >>>> ... >>>> 212 // The door is attached to .java_pid in the >>>> temporary directory. >>>> 213 private int openDoor(int pid) throws IOException { >>>> 214 socket_path = tmpdir + "/.java_pid" + pid; >>>> 215 fd = open(socket_path); >>>> 216 >>>> 217 // Check that the file owner/permission to avoid >>>> attaching to >>>> 218 // bogus process >>>> 219 try { >>>> 220 checkPermissions(socket_path); >>>> 221 } catch (IOException ioe) { >>>> 222 close(fd); >>>> 223 throw ioe; >>>> 224 } >>>> 225 return fd; >>>> 226 } >>>> >>>> ===== >>>> src/jdk.attach/solaris/native/libattach/VirtualMachineImpl.c: >>>> ... >>>> 59 JNIEXPORT jint JNICALL >>>> Java_sun_tools_attach_VirtualMachineImpl_open >>>> 60 (JNIEnv *env, jclass cls, jstring path) >>>> 61 { >>>> 62 jboolean isCopy; >>>> 63 const char* p = GetStringPlatformChars(env, path, >>>> &isCopy); >>>> 64 if (p == NULL) { >>>> 65 return 0; >>>> 66 } else { >>>> 67 int fd; >>>> 68 int err = 0; >>>> 69 >>>> 70 fd = open(p, O_RDWR); >>>> 71 if (fd == -1) { >>>> 72 err = errno; >>>> 73 } >>>> 74 >>>> 75 if (isCopy) { >>>> 76 JNU_ReleaseStringPlatformChars(env, path, p); >>>> 77 } >>>> 78 >>>> 79 if (fd == -1) { >>>> 80 if (err == ENOENT) { >>>> 81 JNU_ThrowByName(env, >>>> "java/io/FileNotFoundException", NULL); >>>> 82 } else { >>>> 83 char* msg = strdup(strerror(err)); >>>> 84 JNU_ThrowIOException(env, msg); >>>> 85 if (msg != NULL) { >>>> 86 free(msg); >>>> 87 } >>>> 88 } >>>> 89 } >>>> 90 return fd; >>>> 91 } >>>> 92 } >>>> ... >>>> 99 JNIEXPORT void JNICALL >>>> Java_sun_tools_attach_VirtualMachineImpl_checkPermissions >>>> 100 (JNIEnv *env, jclass cls, jstring path) >>>> 101 { >>>> 102 jboolean isCopy; >>>> 103 const char* p = GetStringPlatformChars(env, path, >>>> &isCopy); >>>> 104 if (p != NULL) { >>>> 105 struct stat64 sb; >>>> 106 uid_t uid, gid; >>>> 107 int res; >>>> 108 >>>> 109 memset(&sb, 0, sizeof(struct stat64)); >>>> 110 >>>> 111 /* >>>> 112 * Check that the path is owned by the effective >>>> uid/gid of this >>>> 113 * process. Also check that group/other access is >>>> not allowed. >>>> 114 */ >>>> 115 uid = geteuid(); >>>> 116 gid = getegid(); >>>> 117 >>>> 118 res = stat64(p, &sb); >>>> 119 if (res != 0) { >>>> 120 /* save errno */ >>>> 121 res = errno; >>>> 122 } >>>> 123 >>>> 124 if (res == 0) { >>>> 125 char msg[100]; >>>> 126 jboolean isError = JNI_FALSE; >>>> 127 if (sb.st_uid != uid && uid != ROOT_UID) { >>>> 128 snprintf(msg, sizeof(msg), >>>> 129 "file should be owned by the current >>>> user (which is %d) but is owned by %d", uid, sb.st_uid); >>>> 130 isError = JNI_TRUE; >>>> 131 } else if (sb.st_gid != gid && uid != ROOT_UID) { >>>> 132 snprintf(msg, sizeof(msg), >>>> 133 "file's group should be the current >>>> group (which is %d) but the group is %d", gid, sb.st_gid); >>>> 134 isError = JNI_TRUE; >>>> 135 } else if ((sb.st_mode & >>>> (S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)) != 0) { >>>> 136 snprintf(msg, sizeof(msg), >>>> 137 "file should only be readable and >>>> writable by the owner but has 0%03o access", sb.st_mode & 0777); >>>> 138 isError = JNI_TRUE; >>>> 139 } >>>> 140 if (isError) { >>>> 141 char buf[256]; >>>> 142 snprintf(buf, sizeof(buf), "well-known >>>> file %s is not secure: %s", p, msg); >>>> 143 JNU_ThrowIOException(env, buf); >>>> 144 } >>>> 145 } else { >>>> 146 char* msg = strdup(strerror(res)); >>>> 147 JNU_ThrowIOException(env, msg); >>>> 148 if (msg != NULL) { >>>> 149 free(msg); >>>> 150 } >>>> 151 } >>>> >>>> On 10/2/18, 6:23 PM, David Holmes wrote: >>>>> Minor correction: EPERM -> EACCES for Solaris >>>>> >>>>> Hard to see how to get a transient EACCES when opening a file ... >>>>> though as it is really a door I guess there could be additional >>>>> complexity. >>>>> >>>>> David >>>>> >>>>> On 3/10/2018 7:54 AM, Chris Plummer wrote: >>>>>> On 10/2/18 2:38 PM, David Holmes wrote: >>>>>>> Chris, >>>>>>> >>>>>>> On 3/10/2018 6:57 AM, Chris Plummer wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 10/2/18 1:44 PM, gary.adams at oracle.com wrote: >>>>>>>>> The general attach sequence ... >>>>>>>>> >>>>>>>>> src/jdk.attach/solaris/classes/sun/tools/attach/VirtualMachineImpl.java >>>>>>>>> >>>>>>>>> >>>>>>>>> the attacher creates an attach_pid file in a directory where >>>>>>>>> the attachee is runnning >>>>>>>>> issues a signal to the attacheee >>>>>>>>> >>>>>>>>> loops waiting for the java_pid file to be created >>>>>>>>> default timeout is 10 seconds >>>>>>>>> >>>>>>>> So getting a FileNotFoundException while in this loop is OK, >>>>>>>> but IOException is not. >>>>>>>> >>>>>>>>> src/hotspot/os/solaris/attachListener_solaris.cpp >>>>>>>>> >>>>>>>>> attachee creates the java_pid file >>>>>>>>> listens til the attacher opens the door >>>>>>>>> >>>>>>>> I'm don't think this is related, but JDK-8199811 made a fix in >>>>>>>> attachListener_solaris.cpp to make it wait up to 10 seconds for >>>>>>>> initialization to complete before failing the enqueue. >>>>>>>> >>>>>>>>> ... >>>>>>>>> Not sure when a bare IOException is thrown rather than the >>>>>>>>> more specific FileNotFoundException. >>>>>>>> Where is the IOException originating from? I wonder if the >>>>>>>> issue is that the file is in the process of being created, but >>>>>>>> is not fully created yet. Maybe it is there, but >>>>>>>> owner/group/permissions have not been set yet, and this results >>>>>>>> in an IOException instead of FileNotFoundException. >>>>>>> >>>>>>> The exception is shown in the bug report: >>>>>>> >>>>>>> [java.io.IOException: Permission denied >>>>>>> at jdk.attach/sun.tools.attach.VirtualMachineImpl.open(Native >>>>>>> Method) >>>>>>> at >>>>>>> jdk.attach/sun.tools.attach.VirtualMachineImpl.openDoor(VirtualMachineImpl.java:215) >>>>>>> >>>>>>> at >>>>>>> jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:71) >>>>>>> >>>>>>> at >>>>>>> jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58) >>>>>>> >>>>>>> at >>>>>>> jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207) >>>>>>> >>>>>>> at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:114) >>>>>>> at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:98) >>>>>>> >>>>>>> And if you look at the native code the EPERM from open will >>>>>>> cause IOException to be thrown. >>>>>>> >>>>>>> ./jdk.attach/solaris/native/libattach/VirtualMachineImpl.c >>>>>>> >>>>>>> JNIEXPORT jint JNICALL >>>>>>> Java_sun_tools_attach_VirtualMachineImpl_open >>>>>>> (JNIEnv *env, jclass cls, jstring path) >>>>>>> { >>>>>>> jboolean isCopy; >>>>>>> const char* p = GetStringPlatformChars(env, path, &isCopy); >>>>>>> if (p == NULL) { >>>>>>> return 0; >>>>>>> } else { >>>>>>> int fd; >>>>>>> int err = 0; >>>>>>> >>>>>>> fd = open(p, O_RDWR); >>>>>>> if (fd == -1) { >>>>>>> err = errno; >>>>>>> } >>>>>>> >>>>>>> if (isCopy) { >>>>>>> JNU_ReleaseStringPlatformChars(env, path, p); >>>>>>> } >>>>>>> >>>>>>> if (fd == -1) { >>>>>>> if (err == ENOENT) { >>>>>>> JNU_ThrowByName(env, >>>>>>> "java/io/FileNotFoundException", NULL); >>>>>>> } else { >>>>>>> char* msg = strdup(strerror(err)); >>>>>>> JNU_ThrowIOException(env, msg); >>>>>>> if (msg != NULL) { >>>>>>> free(msg); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> We should add the path to the exception message. >>>>>>> >>>>>> Thanks David. So if EPERM is the error and a retry 100ms later >>>>>> works, I think that supports my hypothesis that the file is not >>>>>> quite fully created. So Gary's fix is probably fine. The only >>>>>> other possible fix I can think of that wouldn't require an >>>>>> explicit delay (or multiple retries) is probably not worth the >>>>>> complexity. It would require that the attachee create two files, >>>>>> and the attacher try to open the second file first. When it >>>>>> either opens or returns EPERM, you know the first file can safety >>>>>> be opened. >>>>>> >>>>>> Chris >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> Chris >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/2/18 4:11 PM, Chris Plummer wrote: >>>>>>>>>> Can you summarize how the attach handshaking is suppose to >>>>>>>>>> work? I'm just wondering why the attacher would ever be >>>>>>>>>> looking for the file before the attachee has created it. It >>>>>>>>>> seems a proper handshake would prevent this. Maybe there's >>>>>>>>>> some sort of visibility issue where the attachee has indeed >>>>>>>>>> created the file, but it is not immediately visible to the >>>>>>>>>> attacher process. >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 10/2/18 12:27 PM, gary.adams at oracle.com wrote: >>>>>>>>>>> The problem reproduced pretty quickly. >>>>>>>>>>> I added a call to checkPermission and revealed the >>>>>>>>>>> "file not found" from the stat call when the IOException >>>>>>>>>>> was detected. >>>>>>>>>>> >>>>>>>>>>> There has been some flakiness from the Solaris test machines >>>>>>>>>>> today, >>>>>>>>>>> so I'll continue with the testing a bit longer. >>>>>>>>>>> >>>>>>>>>>> On 10/2/18 3:12 PM, Chris Plummer wrote: >>>>>>>>>>>> Without the fix was this issue easy enough to reproduce >>>>>>>>>>>> that you can be sure this is resolving it? >>>>>>>>>>>> >>>>>>>>>>>> Chris >>>>>>>>>>>> >>>>>>>>>>>> On 10/2/18 8:16 AM, Gary Adams wrote: >>>>>>>>>>>>> Solaris debug builds are failing tests that use the attach >>>>>>>>>>>>> interface. >>>>>>>>>>>>> An IOException is reported when the java_pid file is not >>>>>>>>>>>>> opened. >>>>>>>>>>>>> >>>>>>>>>>>>> It appears that the attempt to attach is taking place too >>>>>>>>>>>>> quickly. >>>>>>>>>>>>> This workaround will allow the open operation to be retried >>>>>>>>>>>>> after a short pause. >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8210337/webrev/ >>>>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8210337 >>>>>>>>>>>>> >>>>>>>>>>>>> Testing is in progress. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Oct 4 18:48:31 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 04 Oct 2018 14:48:31 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <30c4d83c-4f51-bf55-837a-15bcb7df8dc0@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> <5BB5FBDC.7080004@oracle.com> <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> <5BB63A09.7060803@oracle.com> <74d7b85f-0176-d6b0-cca2-7504e61eb4ac@oracle.com> <5BB6472B.7000100@oracle.com> <30c4d83c-4f51-bf55-837a-15bcb7df8dc0@oracle.com> Message-ID: <5BB6607F.1060708@oracle.com> fyi - I think JDK-8201603 tc02t001 is suffering from the same issue. A sleep(100) is used to provoke a contention with the debuggee thread. If the debuggee is not scheduled quickly enough, the main thread proceeds to release the contended object M and the test fails because not all the contended conditions were reported event. On 10/4/18, 1:03 PM, Daniel D. Daugherty wrote: > On 10/4/18 1:00 PM, Gary Adams wrote: >> On 10/4/18, 12:13 PM, Daniel D. Daugherty wrote: >>> On 10/4/18 12:04 PM, Gary Adams wrote: >>>> We currently use time factor 4 or 10 to scale up the jtreg tests. >>>> The change I proposed was already 10x100 = 1000. >>> >>> Agreed that you are already bumping it up by 10X. >>> >>> >>>> Since this is just a thread scheduling issue to let the debuggee >>>> run til it blocks, it should not require more time to get the >>>> switch to take place. >>> >>> Are you really trying to say that system load doesn't affect >>> thread scheduling time? >> In this particular test, the main thread and the debuggee thread >> are toggling back and forth around several monitors and >> synchronized code blocks. Not sure the tests are written >> for an arbitrarily high system load. >>> >>>> If this was a process scheduling issue, then more complex >>>> coordination might be worth considering. >>> >>> System load doesn't just affect process scheduling. It also >>> affects thread scheduling. If all the cores are busy, then >>> running another thread or another process is impacted. >>> >>> >>> In any case, I wasn't clear in my suggestion. >>> >>> - Thread.sleep(100); >>> + Thread.sleep(100 * timeoutFactor); >>> >>> assuming there is some easy way to get access to the -timeoutFactor >>> parameter. >> Currently, timeoutFactor has not been introduced to the vmTestbase/nsk >> test suite. > > Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG > so it is already supported in the test harness that is uses to > run the vmTestbase/nsk test suite... What am I missing here? > > Dan > > >>> >>> Dan >>> >>> >>> >>>> >>>> On 10/4/18, 11:45 AM, Daniel D. Daugherty wrote: >>>>> Sleeps don't scale under load. That said, I agree with Chris that >>>>> the code is already in place. One possible addition is to scale >>>>> the sleep value by the timeout factor for the test. That will >>>>> further reduce the likelihood of intermittent failures. >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 10/4/18 7:39 AM, Gary Adams wrote: >>>>>> Oops, wrong comment used in the patch. >>>>>> Fresh patch attached. >>>>>> >>>>>> On 10/4/18, 7:11 AM, Gary Adams wrote: >>>>>>> Patch attached. >>>>>>> >>>>>>> I think one reviewer is sufficient for a trivial patch. >>>>>>> >>>>>>> On 10/3/18, 4:49 PM, Chris Plummer wrote: >>>>>>>> Hi Gary, >>>>>>>> >>>>>>>> Although I don't like relying on timer delays for stuff like >>>>>>>> this, the code for it is already in place, so I'm ok with >>>>>>>> making the delay longer to make sure there is contention on the >>>>>>>> monitor. Could you update the comment to read "// pause to >>>>>>>> provoke contention on thread.endingMonitor" >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 10/3/18 11:55 AM, Gary Adams wrote: >>>>>>>>> While running a block of nsk/jvmti/scenarios tests, I noticed >>>>>>>>> an occasional failure >>>>>>>>> for cm02t001 in windows debug platform. After enabling the nsk >>>>>>>>> verbose >>>>>>>>> diagnostics and adding a few messages in the main test and the >>>>>>>>> debuggee >>>>>>>>> thread, it became clear that the missing contention was due to >>>>>>>>> the main thread >>>>>>>>> getting ahead of the debugee thread. >>>>>>>>> >>>>>>>>> The call to letFinish() below let's the deuggee thread wake up >>>>>>>>> from it's wait >>>>>>>>> and proceed to the contention for the endingMonitor. If the >>>>>>>>> main thread >>>>>>>>> waits a little longer it should reach the debuggee thread >>>>>>>>> synchronized block. >>>>>>>>> >>>>>>>>> I reopened an earlier bug that was closed as CNR. >>>>>>>>> >>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>>>>>>>> >>>>>>>>> >>>>>>>>> diff --git >>>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>> >>>>>>>>> --- >>>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>> +++ >>>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>> @@ -82,7 +82,7 @@ >>>>>>>>> thread.letFinish(); >>>>>>>>> >>>>>>>>> // pause to provoke contention >>>>>>>>> - Thread.sleep(100); >>>>>>>>> + Thread.sleep(1000); >>>>>>>>> } catch (InterruptedException e) { >>>>>>>>> throw new Failure(e); >>>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Thu Oct 4 19:06:11 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 4 Oct 2018 15:06:11 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: <5BB6607F.1060708@oracle.com> References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> <5BB5FBDC.7080004@oracle.com> <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> <5BB63A09.7060803@oracle.com> <74d7b85f-0176-d6b0-cca2-7504e61eb4ac@oracle.com> <5BB6472B.7000100@oracle.com> <30c4d83c-4f51-bf55-837a-15bcb7df8dc0@oracle.com> <5BB6607F.1060708@oracle.com> Message-ID: Just FYI... http://mail.openjdk.java.net/pipermail/jtreg-use/2013-September/000256.html shows how to access the test timeout factor. There are a few tests in the repo that show code examples: $ grep -r test.timeout.factor hotspot/jtreg hotspot/jtreg/runtime/appcds/TestCommon.java: System.getProperty("test.timeout.factor", "1.0"); hotspot/jtreg/runtime/appcds/TestCommon.java: cmd.add("-Dtest.timeout.factor=" + timeoutFactor); hotspot/jtreg/runtime/appcds/test-classes/ParallelLoad.java: Float.parseFloat(System.getProperty("test.timeout.factor", "1.0")); Your choice on how you want to proceed. Thumbs up from me either way. Dan On 10/4/18 2:48 PM, Gary Adams wrote: > fyi - I think JDK-8201603 tc02t001 is suffering from the same issue. > A sleep(100) is used to provoke a contention with the debuggee thread. > If the debuggee is not scheduled quickly enough, the main thread proceeds > to release the contended object M and the test fails because not all > the contended > conditions were reported event. > > On 10/4/18, 1:03 PM, Daniel D. Daugherty wrote: >> On 10/4/18 1:00 PM, Gary Adams wrote: >>> On 10/4/18, 12:13 PM, Daniel D. Daugherty wrote: >>>> On 10/4/18 12:04 PM, Gary Adams wrote: >>>>> We currently use time factor 4 or 10 to scale up the jtreg tests. >>>>> The change I proposed was already 10x100 = 1000. >>>> >>>> Agreed that you are already bumping it up by 10X. >>>> >>>> >>>>> Since this is just a thread scheduling issue to let the debuggee >>>>> run til it blocks, it should not require more time to get the >>>>> switch to take place. >>>> >>>> Are you really trying to say that system load doesn't affect >>>> thread scheduling time? >>> In this particular test, the main thread and the debuggee thread >>> are toggling back and forth around several monitors and >>> synchronized code blocks. Not sure the tests are written >>> for an arbitrarily high system load. >>>> >>>>> If this was a process scheduling issue, then? more complex >>>>> coordination might be worth considering. >>>> >>>> System load doesn't just affect process scheduling. It also >>>> affects thread scheduling. If all the cores are busy, then >>>> running another thread or another process is impacted. >>>> >>>> >>>> In any case, I wasn't clear in my suggestion. >>>> >>>> -??????????????? Thread.sleep(100); >>>> +??????????????? Thread.sleep(100 * timeoutFactor); >>>> >>>> assuming there is some easy way to get access to the -timeoutFactor >>>> parameter. >>> Currently, timeoutFactor has not been introduced to the vmTestbase/nsk >>> test suite. >> >> Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG >> so it is already supported in the test harness that is uses to >> run the vmTestbase/nsk test suite... What am I missing here? >> >> Dan >> >> >>>> >>>> Dan >>>> >>>> >>>> >>>>> >>>>> On 10/4/18, 11:45 AM, Daniel D. Daugherty wrote: >>>>>> Sleeps don't scale under load. That said, I agree with Chris that >>>>>> the code is already in place. One possible addition is to scale >>>>>> the sleep value by the timeout factor for the test. That will >>>>>> further reduce the likelihood of intermittent failures. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 10/4/18 7:39 AM, Gary Adams wrote: >>>>>>> Oops, wrong comment used in the patch. >>>>>>> Fresh patch attached. >>>>>>> >>>>>>> On 10/4/18, 7:11 AM, Gary Adams wrote: >>>>>>>> Patch attached. >>>>>>>> >>>>>>>> I think one reviewer is sufficient for a trivial patch. >>>>>>>> >>>>>>>> On 10/3/18, 4:49 PM, Chris Plummer wrote: >>>>>>>>> Hi Gary, >>>>>>>>> >>>>>>>>> Although I don't like relying on timer delays for stuff like >>>>>>>>> this, the code for it is already in place, so I'm ok with >>>>>>>>> making the delay longer to make sure there is contention on >>>>>>>>> the monitor. Could you update the comment to read "// pause to >>>>>>>>> provoke contention on thread.endingMonitor" >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> On 10/3/18 11:55 AM, Gary Adams wrote: >>>>>>>>>> While running a block of nsk/jvmti/scenarios tests, I noticed >>>>>>>>>> an occasional failure >>>>>>>>>> for cm02t001 in windows debug platform. After enabling the >>>>>>>>>> nsk verbose >>>>>>>>>> diagnostics and adding a few messages in the main test and >>>>>>>>>> the debuggee >>>>>>>>>> thread, it became clear that the missing contention was due >>>>>>>>>> to the main thread >>>>>>>>>> getting ahead of the debugee thread. >>>>>>>>>> >>>>>>>>>> The call to letFinish() below let's the deuggee thread wake >>>>>>>>>> up from it's wait >>>>>>>>>> and proceed to the contention for the endingMonitor. If the >>>>>>>>>> main thread >>>>>>>>>> waits a little longer it should reach the debuggee thread >>>>>>>>>> synchronized block. >>>>>>>>>> >>>>>>>>>> I reopened an earlier bug that was closed as CNR. >>>>>>>>>> >>>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> diff --git >>>>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>>> +++ >>>>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>>> @@ -82,7 +82,7 @@ >>>>>>>>>> ???????????????? thread.letFinish(); >>>>>>>>>> >>>>>>>>>> ???????????????? // pause to provoke contention >>>>>>>>>> -??????????????? Thread.sleep(100); >>>>>>>>>> +??????????????? Thread.sleep(1000); >>>>>>>>>> ???????????? } catch (InterruptedException e) { >>>>>>>>>> ???????????????? throw new Failure(e); >>>>>>>>>> ???????????? } >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > From serguei.spitsyn at oracle.com Thu Oct 4 20:56:57 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 4 Oct 2018 13:56:57 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> Message-ID: Hi Alex, Several minor suggestions. 77 new Thread(aRP, "jj1").start(); 78 new Thread(asRP, "jj2").start(); What mean aRP and asRP? In fact, it is confusing. Can they be renamed to something like obj1 and obj2. 79 // new Thread(aRP, "jj3").start(); 80 // new Thread(asRP, "jj4").start(); ?These lines can be removed. 94 // line of the last stop 95 int lastLine = -1; 96 // min line (-1 means "not known yet") 97 int minLine = -1; 98 // max line (-1 means "not known yet") 99 int maxLine = -1; ... 140 // the 1st stop in the thread 141 break; ? I'd suggest the refactor above as below: int lastLine = -1; // line of the last stop int minLine = -1; // min line (-1 means "not known yet") int maxLine = -1;// max line (-1 means "not known yet") ... break; // the 1st stop in the thread 116 private void next() { 117 List reply = jdb.command(JdbCommand.next()); 118 /* each "next" produces something like ("Breakpoint hit" line only if the line has BP) 119 Step completed: 120 Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), line=74 bci=12 121 74 ++count2; // @2 breakpoint 122 123 jj2[1] 124 */ It would better to have it in this style: 118 /* * Each "next" produces something like ("Breakpoint hit" line only if the line has BP). 119 * Step completed: 120 * Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), line=74 bci=12 121 * 74 ++count2; // @2 breakpoint 122 * 123 * jj2[1] 124 */ Otherwise, it looks Okay to me. Thanks, Serguei On 10/3/18 5:49 PM, Alex Menkov wrote: > Hi all, > > please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8211292 > webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ > > The fix converts manual shell test to automatic java (as Java allows > to parse jdb replies much easier). > This is the last sub-task for the "shell to java conversion" task, so > the fix also removes shared shell scripts. > > --alex -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Thu Oct 4 21:19:49 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 04 Oct 2018 14:19:49 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> Message-ID: <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> Hi Gary and Chris, Please review an updated version of the patch that has newly added test for the case when suspend policy is set to SUSPEND_EVENT_THREAD reimplemented using JDI API. Thus, the changes in src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java are no longer required. I think vmInterrupted() is not invoked when suspend policy is set to SUSPEND_EVENT_THREAD to address the case when different threads keep hitting the same breakpoint and to avoid the switching the current thread in the background. The actual behavior of the debugger in the case when the breakpoint is hit and suspend policy is set to SUSPEND_EVENT_THREAD is just to print "Breakpoint hit:" in the output without adding any additional information or new line character. After that you need to set the current thread by entering "thread" command , e.g. "thread 1" and only then jdb prints the prompt (e.g. "main[1]") . The behavior looks as confusing since it is not obvious for the user that some input is expected from him (e.g. to set the current thread). I created a separated issue for that at https://bugs.openjdk.java.net/browse/JDK-8211736 . Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.02/ Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 Thanks, --Daniil ?On 10/4/18, 10:28 AM, "Chris Plummer" wrote: On 10/4/18 5:12 AM, Gary Adams wrote: > In TTY.java do you need to force a simple prompt for the > breakpoint event output? What prevents currentThread from > being set at the time you are printing the prompt? > > > 103 // Print the prompt if suspend policy is > SUSPEND_EVENT_THREAD. In case of > 104 // SUSPEND_ALL policy this is handled by vmInterrupted() > method. > 105 if (be.request().suspendPolicy() == > EventRequest.SUSPEND_EVENT_THREAD) { > 106 MessageOutput.println(); > 107 MessageOutput.printPrompt(); Normally the thread is suspended after the above code is executed: public void run() { EventQueue queue = Env.vm().eventQueue(); while (connected) { try { EventSet eventSet = queue.remove(); boolean resumeStoppedApp = false; EventIterator it = eventSet.eventIterator(); while (it.hasNext()) { resumeStoppedApp |= !handleEvent(it.nextEvent()); <--- calls the modified code above } if (resumeStoppedApp) { eventSet.resume(); } else if (eventSet.suspendPolicy() == EventRequest.SUSPEND_ALL) { setCurrentThread(eventSet); <------ notifier.vmInterrupted(); } However, it only calls setCurrentThread() for SUSPEND_ALL policies. So what Daniil has done here is make it print a simple prompt if the policy is SUSPEND_EVENT_THREAD. It's unclear to me what the actual debugger behavior is in this case. Don't we still suspend and get a prompt from which we can type in the next command? In this case, wouldn't you want a full prompt? Related to that question, why is vmInterrupted() only called if we suspend all threads, and not when we just suspend the thread that the breakpoint came in on? Chris > > > In Jdb.java you allow the waiting for the simple prompt. > I don't see waitForSimplePrompt used in any existing tests. > Since it is only looking for a single character it could > produce false positives if the '>' was produced in the > output stream. Is this wait paired to the added prompt for the > break point event? > > 236 return waitForSimplePrompt ? waitForSimplePrompt(1, > cmd.allowExit) : waitForPrompt(1, cmd.allowExit); > > It might be a good idea to include a test with multiple > threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD > behavior. > > On 10/4/18, 12:29 AM, Daniil Titov wrote: >> Please review the changes that fix the deadlock in the debugger when >> the debugger is running with the tracing option on. >> >> The problem here is that when the tracing is on the "JDI Target VM >> Interface" thread (the thread that reads all replies and then >> notifies the thread that sent the request that the reply has been >> received) is waiting for a lock which is already acquired by the >> thread that sent the request and is waiting for reply. >> >> The fix itself is in >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >> >> The patch also reverts the changes done in 8129348 "Debugger hangs in >> trace mode with TRACE_SENDS" in >> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >> since they address only a specific case (VM is suspended and static >> method is invoked) while the proposed fix also solves issue 8129348 >> as well as issue 8193801 "Debugger hangs in trace mode for non-static >> methods". >> >> The changes include new tests for issues 8193879, 8193801 and 8129348. >> >> The changes in >> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >> solve the problem that the prompt is not printed in the debugger >> output when the breakpoint is hit and the suspend policy is >> SUSPEND_EVENT_THREAD. This is required for new tests to detect that >> command "stop thread at ..." is completed. >> >> Mach5 build and jdk_jdi tests succeeded. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >> >> Thanks, >> --Daniil >> >> >> > From alexey.menkov at oracle.com Thu Oct 4 21:53:07 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 4 Oct 2018 14:53:07 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> Message-ID: On 10/04/2018 10:28, Chris Plummer wrote: > On 10/4/18 5:12 AM, Gary Adams wrote: >> In TTY.java do you need to force a simple prompt for the >> breakpoint event output? What prevents currentThread from >> being set at the time you are printing the prompt? >> >> >> ?103???????? // Print the prompt if suspend policy is >> SUSPEND_EVENT_THREAD. In case of >> ?104???????? // SUSPEND_ALL policy this is handled by vmInterrupted() >> method. >> ?105???????? if (be.request().suspendPolicy() == >> EventRequest.SUSPEND_EVENT_THREAD) { >> ?106???????????? MessageOutput.println(); >> ?107???????????? MessageOutput.printPrompt(); > Normally the thread is suspended after the above code is executed: > > ??? public void run() { > ??????? EventQueue queue = Env.vm().eventQueue(); > ??????? while (connected) { > ??????????? try { > ??????????????? EventSet eventSet = queue.remove(); > ??????????????? boolean resumeStoppedApp = false; > ??????????????? EventIterator it = eventSet.eventIterator(); > ??????????????? while (it.hasNext()) { > ??????????????????? resumeStoppedApp |= !handleEvent(it.nextEvent()); > <--- calls the modified code above > ??????????????? } > > ??????????????? if (resumeStoppedApp) { > ??????????????????? eventSet.resume(); > ??????????????? } else if (eventSet.suspendPolicy() == > EventRequest.SUSPEND_ALL) { > ??????????????????? setCurrentThread(eventSet);?? <------ > ??????????????????? notifier.vmInterrupted(); > ??????????????? } > > However, it only calls setCurrentThread() for SUSPEND_ALL policies. So > what Daniil has done here is make it print a simple prompt if the policy > is SUSPEND_EVENT_THREAD. It's unclear to me what the actual debugger > behavior is in this case. Don't we still suspend and get a prompt from > which we can type in the next command? In this case, wouldn't you want a > full prompt? Related to that question, why is vmInterrupted() only > called if we suspend all threads, and not when we just suspend the > thread that the breakpoint came in on? Did a quick test - run debuggee (suspended), connect jdb: =========== VM Started: No frames on the current call stack main[1] stop thread at myclass:71 Deferring breakpoint myclass:71. It will be set after the class is loaded. main[1] run > Set deferred breakpoint myclass:71 Breakpoint hit: ===== I.e. we get only "Breakpoint hit: " without any info about the thread (and this doesn't look good), current thread is not set ("next" reports "Nothing suspended.") But if we handle SUSPEND_EVENT_THREAD like SUSPEND_ALL, we need to think how to handle possible race conditions when there are 2 threads, each of them is stopped by "stop thread at/in". Some notes about the fix (actually about the tests as the fix itself should be implemented): JdbStopThreadWithTraceOnTest.java 70 jdb.command("stop thread at " + DEBUGGEE_CLASS + ":" + bpLine); It would be better to introduce public static JdbCommand JdbCommand.stopThreadAt(String targetClass, int lineNum) Actually may be it would be better to drop Jdb.command(String) - it's required only by CommandCommentDelimiter (need to update it to use "new JdbCommand(...)"). If the fix will require "simple prompt" reply, I'd make it JdbCommand property (like JdbCommand.allowExit) --alex > > Chris >> >> >> In Jdb.java you allow the waiting for the simple prompt. >> I don't see waitForSimplePrompt used in any existing tests. >> Since it is only looking for a single character it could >> produce false positives if the '>' was produced in the >> output stream. Is this wait paired to the added prompt for the >> break point event? >> >> ?236???????? return waitForSimplePrompt ? waitForSimplePrompt(1, >> cmd.allowExit) : waitForPrompt(1, cmd.allowExit); >> >> It might be a good idea to include a test with multiple >> threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD >> behavior. >> >> On 10/4/18, 12:29 AM, Daniil Titov wrote: >>> Please review the changes that fix the deadlock in the debugger when >>> the debugger is running with the tracing option on. >>> >>> The problem here is that when the tracing is on the "JDI Target VM >>> Interface" thread (the thread that reads all replies and then >>> notifies the thread that sent the request that the reply has been >>> received) is waiting for a lock which is already acquired by the >>> thread that sent the request and is waiting for reply. >>> >>> The fix itself is in >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >>> >>> The patch also reverts the changes done in 8129348 "Debugger hangs in >>> trace mode with TRACE_SENDS" in >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>> since they address only a specific case (VM is suspended and static >>> method is invoked) while the proposed fix also solves issue 8129348 >>> as well as issue 8193801 "Debugger hangs in trace mode for non-static >>> methods". >>> >>> The changes include new tests for issues 8193879, 8193801 and 8129348. >>> >>> The changes in >>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >>> solve the problem that the prompt is not printed in the debugger >>> output when the breakpoint is hit and the suspend policy is >>> SUSPEND_EVENT_THREAD. This is required for new tests to detect that >>> command "stop thread at ..." is completed. >>> >>> Mach5 build and jdk_jdi tests succeeded. >>> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >>> >>> Thanks, >>> --Daniil >>> >>> >>> >> > From daniil.x.titov at oracle.com Thu Oct 4 22:13:17 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 04 Oct 2018 15:13:17 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> Message-ID: <244C4805-1237-4288-BCC6-77FCB2FBFDA9@oracle.com> Hi Alex, Just several minutes ago in another email I sent an updated patch on review (please see email attached). The patch has reimplemented tests and no longer uses JdbTest , so the changes you mentioned are no longer there. I also created issue https://bugs.openjdk.java.net/browse/JDK-8211736 to address the missing prompt problem. Thanks! --Daniil ?On 10/4/18, 2:53 PM, "Alex Menkov" wrote: On 10/04/2018 10:28, Chris Plummer wrote: > On 10/4/18 5:12 AM, Gary Adams wrote: >> In TTY.java do you need to force a simple prompt for the >> breakpoint event output? What prevents currentThread from >> being set at the time you are printing the prompt? >> >> >> 103 // Print the prompt if suspend policy is >> SUSPEND_EVENT_THREAD. In case of >> 104 // SUSPEND_ALL policy this is handled by vmInterrupted() >> method. >> 105 if (be.request().suspendPolicy() == >> EventRequest.SUSPEND_EVENT_THREAD) { >> 106 MessageOutput.println(); >> 107 MessageOutput.printPrompt(); > Normally the thread is suspended after the above code is executed: > > public void run() { > EventQueue queue = Env.vm().eventQueue(); > while (connected) { > try { > EventSet eventSet = queue.remove(); > boolean resumeStoppedApp = false; > EventIterator it = eventSet.eventIterator(); > while (it.hasNext()) { > resumeStoppedApp |= !handleEvent(it.nextEvent()); > <--- calls the modified code above > } > > if (resumeStoppedApp) { > eventSet.resume(); > } else if (eventSet.suspendPolicy() == > EventRequest.SUSPEND_ALL) { > setCurrentThread(eventSet); <------ > notifier.vmInterrupted(); > } > > However, it only calls setCurrentThread() for SUSPEND_ALL policies. So > what Daniil has done here is make it print a simple prompt if the policy > is SUSPEND_EVENT_THREAD. It's unclear to me what the actual debugger > behavior is in this case. Don't we still suspend and get a prompt from > which we can type in the next command? In this case, wouldn't you want a > full prompt? Related to that question, why is vmInterrupted() only > called if we suspend all threads, and not when we just suspend the > thread that the breakpoint came in on? Did a quick test - run debuggee (suspended), connect jdb: =========== VM Started: No frames on the current call stack main[1] stop thread at myclass:71 Deferring breakpoint myclass:71. It will be set after the class is loaded. main[1] run > Set deferred breakpoint myclass:71 Breakpoint hit: ===== I.e. we get only "Breakpoint hit: " without any info about the thread (and this doesn't look good), current thread is not set ("next" reports "Nothing suspended.") But if we handle SUSPEND_EVENT_THREAD like SUSPEND_ALL, we need to think how to handle possible race conditions when there are 2 threads, each of them is stopped by "stop thread at/in". Some notes about the fix (actually about the tests as the fix itself should be implemented): JdbStopThreadWithTraceOnTest.java 70 jdb.command("stop thread at " + DEBUGGEE_CLASS + ":" + bpLine); It would be better to introduce public static JdbCommand JdbCommand.stopThreadAt(String targetClass, int lineNum) Actually may be it would be better to drop Jdb.command(String) - it's required only by CommandCommentDelimiter (need to update it to use "new JdbCommand(...)"). If the fix will require "simple prompt" reply, I'd make it JdbCommand property (like JdbCommand.allowExit) --alex > > Chris >> >> >> In Jdb.java you allow the waiting for the simple prompt. >> I don't see waitForSimplePrompt used in any existing tests. >> Since it is only looking for a single character it could >> produce false positives if the '>' was produced in the >> output stream. Is this wait paired to the added prompt for the >> break point event? >> >> 236 return waitForSimplePrompt ? waitForSimplePrompt(1, >> cmd.allowExit) : waitForPrompt(1, cmd.allowExit); >> >> It might be a good idea to include a test with multiple >> threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD >> behavior. >> >> On 10/4/18, 12:29 AM, Daniil Titov wrote: >>> Please review the changes that fix the deadlock in the debugger when >>> the debugger is running with the tracing option on. >>> >>> The problem here is that when the tracing is on the "JDI Target VM >>> Interface" thread (the thread that reads all replies and then >>> notifies the thread that sent the request that the reply has been >>> received) is waiting for a lock which is already acquired by the >>> thread that sent the request and is waiting for reply. >>> >>> The fix itself is in >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >>> >>> The patch also reverts the changes done in 8129348 "Debugger hangs in >>> trace mode with TRACE_SENDS" in >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>> since they address only a specific case (VM is suspended and static >>> method is invoked) while the proposed fix also solves issue 8129348 >>> as well as issue 8193801 "Debugger hangs in trace mode for non-static >>> methods". >>> >>> The changes include new tests for issues 8193879, 8193801 and 8129348. >>> >>> The changes in >>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >>> solve the problem that the prompt is not printed in the debugger >>> output when the breakpoint is hit and the suspend policy is >>> SUSPEND_EVENT_THREAD. This is required for new tests to detect that >>> command "stop thread at ..." is completed. >>> >>> Mach5 build and jdk_jdi tests succeeded. >>> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >>> >>> Thanks, >>> --Daniil >>> >>> >>> >> > -------------- next part -------------- An embedded message was scrubbed... From: Daniil Titov Subject: Re: RFR 8193879: Java debugger hangs on method invocation Date: Thu, 04 Oct 2018 14:19:49 -0700 Size: 11231 URL: From alexey.menkov at oracle.com Thu Oct 4 22:53:23 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 4 Oct 2018 15:53:23 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <244C4805-1237-4288-BCC6-77FCB2FBFDA9@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <244C4805-1237-4288-BCC6-77FCB2FBFDA9@oracle.com> Message-ID: Looks good to me. --alex On 10/04/2018 15:13, Daniil Titov wrote: > Hi Alex, > > Just several minutes ago in another email I sent an updated patch on review (please see email attached). The patch has reimplemented tests and no longer uses JdbTest , so the changes you mentioned are no longer there. I also created issue https://bugs.openjdk.java.net/browse/JDK-8211736 to address the missing prompt problem. > > Thanks! > --Daniil > > ?On 10/4/18, 2:53 PM, "Alex Menkov" wrote: > > > > On 10/04/2018 10:28, Chris Plummer wrote: > > On 10/4/18 5:12 AM, Gary Adams wrote: > >> In TTY.java do you need to force a simple prompt for the > >> breakpoint event output? What prevents currentThread from > >> being set at the time you are printing the prompt? > >> > >> > >> 103 // Print the prompt if suspend policy is > >> SUSPEND_EVENT_THREAD. In case of > >> 104 // SUSPEND_ALL policy this is handled by vmInterrupted() > >> method. > >> 105 if (be.request().suspendPolicy() == > >> EventRequest.SUSPEND_EVENT_THREAD) { > >> 106 MessageOutput.println(); > >> 107 MessageOutput.printPrompt(); > > Normally the thread is suspended after the above code is executed: > > > > public void run() { > > EventQueue queue = Env.vm().eventQueue(); > > while (connected) { > > try { > > EventSet eventSet = queue.remove(); > > boolean resumeStoppedApp = false; > > EventIterator it = eventSet.eventIterator(); > > while (it.hasNext()) { > > resumeStoppedApp |= !handleEvent(it.nextEvent()); > > <--- calls the modified code above > > } > > > > if (resumeStoppedApp) { > > eventSet.resume(); > > } else if (eventSet.suspendPolicy() == > > EventRequest.SUSPEND_ALL) { > > setCurrentThread(eventSet); <------ > > notifier.vmInterrupted(); > > } > > > > However, it only calls setCurrentThread() for SUSPEND_ALL policies. So > > what Daniil has done here is make it print a simple prompt if the policy > > is SUSPEND_EVENT_THREAD. It's unclear to me what the actual debugger > > behavior is in this case. Don't we still suspend and get a prompt from > > which we can type in the next command? In this case, wouldn't you want a > > full prompt? Related to that question, why is vmInterrupted() only > > called if we suspend all threads, and not when we just suspend the > > thread that the breakpoint came in on? > > Did a quick test > - run debuggee (suspended), connect jdb: > =========== > VM Started: No frames on the current call stack > > main[1] stop thread at myclass:71 > Deferring breakpoint myclass:71. > It will be set after the class is loaded. > main[1] run > > Set deferred breakpoint myclass:71 > > Breakpoint hit: > ===== > I.e. we get only "Breakpoint hit: " without any info about the thread > (and this doesn't look good), current thread is not set ("next" reports > "Nothing suspended.") > > But if we handle SUSPEND_EVENT_THREAD like SUSPEND_ALL, we need to think > how to handle possible race conditions when there are 2 threads, each of > them is stopped by "stop thread at/in". > > Some notes about the fix (actually about the tests as the fix itself > should be implemented): > JdbStopThreadWithTraceOnTest.java > 70 jdb.command("stop thread at " + DEBUGGEE_CLASS + ":" + bpLine); > > It would be better to introduce > public static JdbCommand JdbCommand.stopThreadAt(String targetClass, int > lineNum) > Actually may be it would be better to drop Jdb.command(String) - it's > required only by CommandCommentDelimiter (need to update it to use "new > JdbCommand(...)"). > > If the fix will require "simple prompt" reply, I'd make it JdbCommand > property (like JdbCommand.allowExit) > > --alex > > > > > Chris > >> > >> > >> In Jdb.java you allow the waiting for the simple prompt. > >> I don't see waitForSimplePrompt used in any existing tests. > >> Since it is only looking for a single character it could > >> produce false positives if the '>' was produced in the > >> output stream. Is this wait paired to the added prompt for the > >> break point event? > >> > >> 236 return waitForSimplePrompt ? waitForSimplePrompt(1, > >> cmd.allowExit) : waitForPrompt(1, cmd.allowExit); > >> > >> It might be a good idea to include a test with multiple > >> threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD > >> behavior. > >> > >> On 10/4/18, 12:29 AM, Daniil Titov wrote: > >>> Please review the changes that fix the deadlock in the debugger when > >>> the debugger is running with the tracing option on. > >>> > >>> The problem here is that when the tracing is on the "JDI Target VM > >>> Interface" thread (the thread that reads all replies and then > >>> notifies the thread that sent the request that the reply has been > >>> received) is waiting for a lock which is already acquired by the > >>> thread that sent the request and is waiting for reply. > >>> > >>> The fix itself is in > >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. > >>> > >>> The patch also reverts the changes done in 8129348 "Debugger hangs in > >>> trace mode with TRACE_SENDS" in > >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java > >>> since they address only a specific case (VM is suspended and static > >>> method is invoked) while the proposed fix also solves issue 8129348 > >>> as well as issue 8193801 "Debugger hangs in trace mode for non-static > >>> methods". > >>> > >>> The changes include new tests for issues 8193879, 8193801 and 8129348. > >>> > >>> The changes in > >>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > >>> solve the problem that the prompt is not printed in the debugger > >>> output when the breakpoint is hit and the suspend policy is > >>> SUSPEND_EVENT_THREAD. This is required for new tests to detect that > >>> command "stop thread at ..." is completed. > >>> > >>> Mach5 build and jdk_jdi tests succeeded. > >>> > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 > >>> > >>> Thanks, > >>> --Daniil > >>> > >>> > >>> > >> > > > > From alexey.menkov at oracle.com Thu Oct 4 23:11:00 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 4 Oct 2018 16:11:00 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> Message-ID: <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> Hi Serguei, Updated webrev: http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ Fixed all issues except 140 // the 1st stop in the thread 141 break; In this case the comment is an explanation why we reach the block, not an explanation for the "break" statement. --alex On 10/04/2018 13:56, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Several minor suggestions. > > 77 new Thread(aRP, "jj1").start(); > 78 new Thread(asRP, "jj2").start(); What mean aRP and asRP? In fact, it > is confusing. Can they be renamed to something like obj1 and obj2. > > 79 // new Thread(aRP, "jj3").start(); > 80 // new Thread(asRP, "jj4").start(); > > ?These lines can be removed. > > 94 // line of the last stop > 95 int lastLine = -1; > 96 // min line (-1 means "not known yet") > 97 int minLine = -1; > 98 // max line (-1 means "not known yet") > 99 int maxLine = -1; ... 140 // the 1st stop in the thread > 141 break; > > ? I'd suggest the refactor above as below: > > int lastLine = -1; // line of the last stop > int minLine = -1; // min line (-1 means "not known yet") > int maxLine = -1;// max line (-1 means "not known yet") > ... > break; // the 1st stop in the thread > > 116 private void next() { > 117 List reply = jdb.command(JdbCommand.next()); > 118 /* each "next" produces something like ("Breakpoint hit" line only > if the line has BP) > 119 Step completed: > 120 Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), > line=74 bci=12 > 121 74 ++count2; // @2 breakpoint > 122 > 123 jj2[1] > 124 */ It would better to have it in this style: 118 /* * Each "next" > produces something like ("Breakpoint hit" line only if the line has BP). > 119 * Step completed: > 120 * Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), > line=74 bci=12 > 121 * 74 ++count2; // @2 breakpoint > 122 * > 123 * jj2[1] > 124 */ > > > Otherwise, it looks Okay to me. > > > Thanks, > Serguei > > On 10/3/18 5:49 PM, Alex Menkov wrote: >> Hi all, >> >> please review a fix for >> https://bugs.openjdk.java.net/browse/JDK-8211292 >> webrev: >> http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ >> >> The fix converts manual shell test to automatic java (as Java allows >> to parse jdb replies much easier). >> This is the last sub-task for the "shell to java conversion" task, so >> the fix also removes shared shell scripts. >> >> --alex > From chris.plummer at oracle.com Thu Oct 4 23:11:12 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 4 Oct 2018 16:11:12 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> Message-ID: <1b8b45bd-5ff2-c5b4-970f-90ea0e6dc83b@oracle.com> On 10/4/18 2:53 PM, Alex Menkov wrote: > > > On 10/04/2018 10:28, Chris Plummer wrote: >> On 10/4/18 5:12 AM, Gary Adams wrote: >>> In TTY.java do you need to force a simple prompt for the >>> breakpoint event output? What prevents currentThread from >>> being set at the time you are printing the prompt? >>> >>> >>> ?103???????? // Print the prompt if suspend policy is >>> SUSPEND_EVENT_THREAD. In case of >>> ?104???????? // SUSPEND_ALL policy this is handled by >>> vmInterrupted() method. >>> ?105???????? if (be.request().suspendPolicy() == >>> EventRequest.SUSPEND_EVENT_THREAD) { >>> ?106???????????? MessageOutput.println(); >>> ?107???????????? MessageOutput.printPrompt(); >> Normally the thread is suspended after the above code is executed: >> >> ???? public void run() { >> ???????? EventQueue queue = Env.vm().eventQueue(); >> ???????? while (connected) { >> ???????????? try { >> ???????????????? EventSet eventSet = queue.remove(); >> ???????????????? boolean resumeStoppedApp = false; >> ???????????????? EventIterator it = eventSet.eventIterator(); >> ???????????????? while (it.hasNext()) { >> ???????????????????? resumeStoppedApp |= >> !handleEvent(it.nextEvent()); <--- calls the modified code above >> ???????????????? } >> >> ???????????????? if (resumeStoppedApp) { >> ???????????????????? eventSet.resume(); >> ???????????????? } else if (eventSet.suspendPolicy() == >> EventRequest.SUSPEND_ALL) { >> ???????????????????? setCurrentThread(eventSet);?? <------ >> ???????????????????? notifier.vmInterrupted(); >> ???????????????? } >> >> However, it only calls setCurrentThread() for SUSPEND_ALL policies. >> So what Daniil has done here is make it print a simple prompt if the >> policy is SUSPEND_EVENT_THREAD. It's unclear to me what the actual >> debugger behavior is in this case. Don't we still suspend and get a >> prompt from which we can type in the next command? In this case, >> wouldn't you want a full prompt? Related to that question, why is >> vmInterrupted() only called if we suspend all threads, and not when >> we just suspend the thread that the breakpoint came in on? > > Did a quick test > - run debuggee (suspended), connect jdb: > =========== > VM Started: No frames on the current call stack > > main[1] stop thread at myclass:71 I don't see "stop thread at" in the jdb help output. I assume it means the same as "stop at", but only suspends the current thread. > Deferring breakpoint myclass:71. > It will be set after the class is loaded. > main[1] run > > Set deferred breakpoint myclass:71 > > Breakpoint hit: > ===== > I.e. we get only "Breakpoint hit: " without any info about the thread > (and this doesn't look good), current thread is not set ("next" > reports "Nothing suspended.") Where is the input cursor at this point? Right after "Breakpoint hit:" or on the next (empty) line. > > But if we handle SUSPEND_EVENT_THREAD like SUSPEND_ALL, we need to > think how to handle possible race conditions when there are 2 threads, > each of them is stopped by "stop thread at/in". Well, not really a race condition, but after hitting the breakpoint in one thread, you could hit the same breakpoint again in another thread. So you are in this state where you are both at the user command prompt, and new events can still come in. Also, now you have two threads suspended. I suppose to resume a thread you need to switch to it with "thread" and then execute "cont". Chris > > Some notes about the fix (actually about the tests as the fix itself > should be implemented): > JdbStopThreadWithTraceOnTest.java > 70???????? jdb.command("stop thread at " + DEBUGGEE_CLASS + ":" + > bpLine); > > It would be better to introduce > public static JdbCommand JdbCommand.stopThreadAt(String targetClass, > int lineNum) > Actually may be it would be better to drop Jdb.command(String) - it's > required only by CommandCommentDelimiter (need to update it to use > "new JdbCommand(...)"). > > If the fix will require "simple prompt" reply, I'd make it JdbCommand > property (like JdbCommand.allowExit) > > --alex > >> >> Chris >>> >>> >>> In Jdb.java you allow the waiting for the simple prompt. >>> I don't see waitForSimplePrompt used in any existing tests. >>> Since it is only looking for a single character it could >>> produce false positives if the '>' was produced in the >>> output stream. Is this wait paired to the added prompt for the >>> break point event? >>> >>> ?236???????? return waitForSimplePrompt ? waitForSimplePrompt(1, >>> cmd.allowExit) : waitForPrompt(1, cmd.allowExit); >>> >>> It might be a good idea to include a test with multiple >>> threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD >>> behavior. >>> >>> On 10/4/18, 12:29 AM, Daniil Titov wrote: >>>> Please review the changes that fix the deadlock in the debugger >>>> when the debugger is running with the tracing option on. >>>> >>>> The problem here is that when the tracing is on the "JDI Target VM >>>> Interface" thread (the thread that reads all replies and then >>>> notifies the thread that sent the request that the reply has been >>>> received) is waiting for a lock which is already acquired by the >>>> thread that sent the request and is waiting for reply. >>>> >>>> The fix itself is in >>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >>>> >>>> The patch also reverts the changes done in 8129348 "Debugger hangs >>>> in trace mode with TRACE_SENDS" in >>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>>> since they address only a specific case (VM is suspended and static >>>> method is invoked) while the proposed fix also solves issue 8129348 >>>> as well as issue 8193801 "Debugger hangs in trace mode for >>>> non-static methods". >>>> >>>> The changes include new tests for issues 8193879, 8193801 and 8129348. >>>> >>>> The changes in >>>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >>>> solve the problem that the prompt is not printed in the debugger >>>> output when the breakpoint is hit and the suspend policy is >>>> SUSPEND_EVENT_THREAD. This is required for new tests to detect that >>>> command "stop thread at ..." is completed. >>>> >>>> Mach5 build and jdk_jdi tests succeeded. >>>> >>>> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >>>> >>>> Thanks, >>>> --Daniil >>>> >>>> >>>> >>> >> From alexey.menkov at oracle.com Fri Oct 5 01:00:54 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 4 Oct 2018 18:00:54 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <1b8b45bd-5ff2-c5b4-970f-90ea0e6dc83b@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <1b8b45bd-5ff2-c5b4-970f-90ea0e6dc83b@oracle.com> Message-ID: <0a7e4f90-7437-4f61-fd8a-5a603ac5dd1e@oracle.com> On 10/04/2018 16:11, Chris Plummer wrote: > On 10/4/18 2:53 PM, Alex Menkov wrote: >> >> >> On 10/04/2018 10:28, Chris Plummer wrote: >>> On 10/4/18 5:12 AM, Gary Adams wrote: >>>> In TTY.java do you need to force a simple prompt for the >>>> breakpoint event output? What prevents currentThread from >>>> being set at the time you are printing the prompt? >>>> >>>> >>>> ?103???????? // Print the prompt if suspend policy is >>>> SUSPEND_EVENT_THREAD. In case of >>>> ?104???????? // SUSPEND_ALL policy this is handled by >>>> vmInterrupted() method. >>>> ?105???????? if (be.request().suspendPolicy() == >>>> EventRequest.SUSPEND_EVENT_THREAD) { >>>> ?106???????????? MessageOutput.println(); >>>> ?107???????????? MessageOutput.printPrompt(); >>> Normally the thread is suspended after the above code is executed: >>> >>> ???? public void run() { >>> ???????? EventQueue queue = Env.vm().eventQueue(); >>> ???????? while (connected) { >>> ???????????? try { >>> ???????????????? EventSet eventSet = queue.remove(); >>> ???????????????? boolean resumeStoppedApp = false; >>> ???????????????? EventIterator it = eventSet.eventIterator(); >>> ???????????????? while (it.hasNext()) { >>> ???????????????????? resumeStoppedApp |= >>> !handleEvent(it.nextEvent()); <--- calls the modified code above >>> ???????????????? } >>> >>> ???????????????? if (resumeStoppedApp) { >>> ???????????????????? eventSet.resume(); >>> ???????????????? } else if (eventSet.suspendPolicy() == >>> EventRequest.SUSPEND_ALL) { >>> ???????????????????? setCurrentThread(eventSet);?? <------ >>> ???????????????????? notifier.vmInterrupted(); >>> ???????????????? } >>> >>> However, it only calls setCurrentThread() for SUSPEND_ALL policies. >>> So what Daniil has done here is make it print a simple prompt if the >>> policy is SUSPEND_EVENT_THREAD. It's unclear to me what the actual >>> debugger behavior is in this case. Don't we still suspend and get a >>> prompt from which we can type in the next command? In this case, >>> wouldn't you want a full prompt? Related to that question, why is >>> vmInterrupted() only called if we suspend all threads, and not when >>> we just suspend the thread that the breakpoint came in on? >> >> Did a quick test >> - run debuggee (suspended), connect jdb: >> =========== >> VM Started: No frames on the current call stack >> >> main[1] stop thread at myclass:71 > I don't see "stop thread at" in the jdb help output. I assume it means > the same as "stop at", but only suspends the current thread. Yes, you're right. But the bug has "stop thread at" in the testcase. Actually stop at can be "stop go at ..." which means the policy is set to SUSPEND_NONE. This looks quite funny - breakpoint which doesn't break the execution :) > >> Deferring breakpoint myclass:71. >> It will be set after the class is loaded. >> main[1] run >> > Set deferred breakpoint myclass:71 >> >> Breakpoint hit: >> ===== >> I.e. we get only "Breakpoint hit: " without any info about the thread >> (and this doesn't look good), current thread is not set ("next" >> reports "Nothing suspended.") > Where is the input cursor at this point? Right after "Breakpoint hit:" > or on the next (empty) line. After "Breakpoint hit: " (space after the colon) >> >> But if we handle SUSPEND_EVENT_THREAD like SUSPEND_ALL, we need to >> think how to handle possible race conditions when there are 2 threads, >> each of them is stopped by "stop thread at/in". > Well, not really a race condition, but after hitting the breakpoint in > one thread, you could hit the same breakpoint again in another thread. > So you are in this state where you are both at the user command prompt, > and new events can still come in. Also, now you have two threads > suspended. I suppose to resume a thread you need to switch to it with > "thread" and then execute "cont". Yes, you are right. Considering this scenario set current thread for SUSPEND_EVENT_THREAD requests doesn't look good. --alex > > Chris >> >> Some notes about the fix (actually about the tests as the fix itself >> should be implemented): >> JdbStopThreadWithTraceOnTest.java >> 70???????? jdb.command("stop thread at " + DEBUGGEE_CLASS + ":" + >> bpLine); >> >> It would be better to introduce >> public static JdbCommand JdbCommand.stopThreadAt(String targetClass, >> int lineNum) >> Actually may be it would be better to drop Jdb.command(String) - it's >> required only by CommandCommentDelimiter (need to update it to use >> "new JdbCommand(...)"). >> >> If the fix will require "simple prompt" reply, I'd make it JdbCommand >> property (like JdbCommand.allowExit) >> >> --alex >> >>> >>> Chris >>>> >>>> >>>> In Jdb.java you allow the waiting for the simple prompt. >>>> I don't see waitForSimplePrompt used in any existing tests. >>>> Since it is only looking for a single character it could >>>> produce false positives if the '>' was produced in the >>>> output stream. Is this wait paired to the added prompt for the >>>> break point event? >>>> >>>> ?236???????? return waitForSimplePrompt ? waitForSimplePrompt(1, >>>> cmd.allowExit) : waitForPrompt(1, cmd.allowExit); >>>> >>>> It might be a good idea to include a test with multiple >>>> threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD >>>> behavior. >>>> >>>> On 10/4/18, 12:29 AM, Daniil Titov wrote: >>>>> Please review the changes that fix the deadlock in the debugger >>>>> when the debugger is running with the tracing option on. >>>>> >>>>> The problem here is that when the tracing is on the "JDI Target VM >>>>> Interface" thread (the thread that reads all replies and then >>>>> notifies the thread that sent the request that the reply has been >>>>> received) is waiting for a lock which is already acquired by the >>>>> thread that sent the request and is waiting for reply. >>>>> >>>>> The fix itself is in >>>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >>>>> >>>>> The patch also reverts the changes done in 8129348 "Debugger hangs >>>>> in trace mode with TRACE_SENDS" in >>>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>>>> since they address only a specific case (VM is suspended and static >>>>> method is invoked) while the proposed fix also solves issue 8129348 >>>>> as well as issue 8193801 "Debugger hangs in trace mode for >>>>> non-static methods". >>>>> >>>>> The changes include new tests for issues 8193879, 8193801 and 8129348. >>>>> >>>>> The changes in >>>>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >>>>> solve the problem that the prompt is not printed in the debugger >>>>> output when the breakpoint is hit and the suspend policy is >>>>> SUSPEND_EVENT_THREAD. This is required for new tests to detect that >>>>> command "stop thread at ..." is completed. >>>>> >>>>> Mach5 build and jdk_jdi tests succeeded. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >>>>> >>>>> Thanks, >>>>> --Daniil >>>>> >>>>> >>>>> >>>> >>> > > From serguei.spitsyn at oracle.com Fri Oct 5 01:31:05 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 4 Oct 2018 18:31:05 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> Message-ID: Hi Alex, It looks good to me. Could you, please, also remove the line? : 156 // No need in new webrev. Thanks, Serguei On 10/4/18 4:11 PM, Alex Menkov wrote: > Hi Serguei, > > Updated webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ > > Fixed all issues except > ?140???????????????? // the 1st stop in the thread > ?141???????????????? break; > In this case the comment is an explanation why we reach the block, not > an explanation for the "break" statement. > > --alex > > On 10/04/2018 13:56, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Several minor suggestions. >> >> 77 new Thread(aRP, "jj1").start(); >> 78 new Thread(asRP, "jj2").start(); What mean aRP and asRP? In fact, >> it is confusing. Can they be renamed to something like obj1 and obj2. >> >> 79 // new Thread(aRP, "jj3").start(); >> 80 // new Thread(asRP, "jj4").start(); >> >> ??These lines can be removed. >> >> 94 // line of the last stop >> 95 int lastLine = -1; >> 96 // min line (-1 means "not known yet") >> 97 int minLine = -1; >> 98 // max line (-1 means "not known yet") >> 99 int maxLine = -1; ... 140 // the 1st stop in the thread >> 141 break; >> >> ?? I'd suggest the refactor above as below: >> >> int lastLine = -1;? // line of the last stop >> int minLine = -1;? // min line (-1 means "not known yet") >> int maxLine = -1;// max line (-1 means "not known yet") >> ? ... >> break;? // the 1st stop in the thread >> >> 116 private void next() { >> 117 List reply = jdb.command(JdbCommand.next()); >> 118 /* each "next" produces something like ("Breakpoint hit" line >> only if the line has BP) >> 119 Step completed: >> 120 Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), >> line=74 bci=12 >> 121 74 ++count2; // @2 breakpoint >> 122 >> 123 jj2[1] >> 124 */ It would better to have it in this style: 118 /* * Each "next" >> produces something like ("Breakpoint hit" line only if the line has BP). >> 119 * Step completed: >> 120 * Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), >> line=74 bci=12 >> 121 * 74 ++count2; // @2 breakpoint >> 122 * >> 123 * jj2[1] >> 124 */ >> >> >> Otherwise, it looks Okay to me. >> >> >> Thanks, >> Serguei >> >> On 10/3/18 5:49 PM, Alex Menkov wrote: >>> Hi all, >>> >>> please review a fix for >>> https://bugs.openjdk.java.net/browse/JDK-8211292 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ >>> >>> The fix converts manual shell test to automatic java (as Java allows >>> to parse jdb replies much easier). >>> This is the last sub-task for the "shell to java conversion" task, >>> so the fix also removes shared shell scripts. >>> >>> --alex >> From chris.plummer at oracle.com Fri Oct 5 04:52:44 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 4 Oct 2018 21:52:44 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <0a7e4f90-7437-4f61-fd8a-5a603ac5dd1e@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <1b8b45bd-5ff2-c5b4-970f-90ea0e6dc83b@oracle.com> <0a7e4f90-7437-4f61-fd8a-5a603ac5dd1e@oracle.com> Message-ID: On 10/4/18 6:00 PM, Alex Menkov wrote: > > > On 10/04/2018 16:11, Chris Plummer wrote: >> On 10/4/18 2:53 PM, Alex Menkov wrote: >>> >>> >>> On 10/04/2018 10:28, Chris Plummer wrote: >>>> On 10/4/18 5:12 AM, Gary Adams wrote: >>>>> In TTY.java do you need to force a simple prompt for the >>>>> breakpoint event output? What prevents currentThread from >>>>> being set at the time you are printing the prompt? >>>>> >>>>> >>>>> ?103???????? // Print the prompt if suspend policy is >>>>> SUSPEND_EVENT_THREAD. In case of >>>>> ?104???????? // SUSPEND_ALL policy this is handled by >>>>> vmInterrupted() method. >>>>> ?105???????? if (be.request().suspendPolicy() == >>>>> EventRequest.SUSPEND_EVENT_THREAD) { >>>>> ?106???????????? MessageOutput.println(); >>>>> ?107???????????? MessageOutput.printPrompt(); >>>> Normally the thread is suspended after the above code is executed: >>>> >>>> ???? public void run() { >>>> ???????? EventQueue queue = Env.vm().eventQueue(); >>>> ???????? while (connected) { >>>> ???????????? try { >>>> ???????????????? EventSet eventSet = queue.remove(); >>>> ???????????????? boolean resumeStoppedApp = false; >>>> ???????????????? EventIterator it = eventSet.eventIterator(); >>>> ???????????????? while (it.hasNext()) { >>>> ???????????????????? resumeStoppedApp |= >>>> !handleEvent(it.nextEvent()); <--- calls the modified code above >>>> ???????????????? } >>>> >>>> ???????????????? if (resumeStoppedApp) { >>>> ???????????????????? eventSet.resume(); >>>> ???????????????? } else if (eventSet.suspendPolicy() == >>>> EventRequest.SUSPEND_ALL) { >>>> ???????????????????? setCurrentThread(eventSet); <------ >>>> ???????????????????? notifier.vmInterrupted(); >>>> ???????????????? } >>>> >>>> However, it only calls setCurrentThread() for SUSPEND_ALL policies. >>>> So what Daniil has done here is make it print a simple prompt if >>>> the policy is SUSPEND_EVENT_THREAD. It's unclear to me what the >>>> actual debugger behavior is in this case. Don't we still suspend >>>> and get a prompt from which we can type in the next command? In >>>> this case, wouldn't you want a full prompt? Related to that >>>> question, why is vmInterrupted() only called if we suspend all >>>> threads, and not when we just suspend the thread that the >>>> breakpoint came in on? >>> >>> Did a quick test >>> - run debuggee (suspended), connect jdb: >>> =========== >>> VM Started: No frames on the current call stack >>> >>> main[1] stop thread at myclass:71 >> I don't see "stop thread at" in the jdb help output. I assume it >> means the same as "stop at", but only suspends the current thread. > > Yes, you're right. But the bug has "stop thread at" in the testcase. > Actually stop at can be "stop go at ..." which means the policy is set > to SUSPEND_NONE. > This looks quite funny - breakpoint which doesn't break the execution :) I guess that's like a tracing feature, but it doesn't seem to tell you where you hit the breakpoint, only that one was hit, which isn't all that useful. I think we should call printCurrentLocation() for any breakpoint being hit, but we only do that for SUSPEND_ALL. > >> >>> Deferring breakpoint myclass:71. >>> It will be set after the class is loaded. >>> main[1] run >>> > Set deferred breakpoint myclass:71 >>> >>> Breakpoint hit: >>> ===== >>> I.e. we get only "Breakpoint hit: " without any info about the >>> thread (and this doesn't look good), current thread is not set >>> ("next" reports "Nothing suspended.") >> Where is the input cursor at this point? Right after "Breakpoint >> hit:" or on the next (empty) line. > > After "Breakpoint hit: " (space after the colon) So you don't even know which thread you hit the breakpoint in. Another reason calling printCurrentLocation() would be useful. > >>> >>> But if we handle SUSPEND_EVENT_THREAD like SUSPEND_ALL, we need to >>> think how to handle possible race conditions when there are 2 >>> threads, each of them is stopped by "stop thread at/in". >> Well, not really a race condition, but after hitting the breakpoint >> in one thread, you could hit the same breakpoint again in another >> thread. So you are in this state where you are both at the user >> command prompt, and new events can still come in. Also, now you have >> two threads suspended. I suppose to resume a thread you need to >> switch to it with "thread" and then execute "cont". > > Yes, you are right. > Considering this scenario set current thread for SUSPEND_EVENT_THREAD > requests doesn't look good. If we did set the current thread, you could then have a race condition with the jdb user. You hit the breakpoint, type in "cont", but another breakpoint comes in just before you press . You end up continuing the second thread in that case instead of the first as you intended. Chris > > --alex > >> >> Chris >>> >>> Some notes about the fix (actually about the tests as the fix itself >>> should be implemented): >>> JdbStopThreadWithTraceOnTest.java >>> 70???????? jdb.command("stop thread at " + DEBUGGEE_CLASS + ":" + >>> bpLine); >>> >>> It would be better to introduce >>> public static JdbCommand JdbCommand.stopThreadAt(String targetClass, >>> int lineNum) >>> Actually may be it would be better to drop Jdb.command(String) - >>> it's required only by CommandCommentDelimiter (need to update it to >>> use "new JdbCommand(...)"). >>> >>> If the fix will require "simple prompt" reply, I'd make it >>> JdbCommand property (like JdbCommand.allowExit) >>> >>> --alex >>> >>>> >>>> Chris >>>>> >>>>> >>>>> In Jdb.java you allow the waiting for the simple prompt. >>>>> I don't see waitForSimplePrompt used in any existing tests. >>>>> Since it is only looking for a single character it could >>>>> produce false positives if the '>' was produced in the >>>>> output stream. Is this wait paired to the added prompt for the >>>>> break point event? >>>>> >>>>> ?236???????? return waitForSimplePrompt ? waitForSimplePrompt(1, >>>>> cmd.allowExit) : waitForPrompt(1, cmd.allowExit); >>>>> >>>>> It might be a good idea to include a test with multiple >>>>> threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD >>>>> behavior. >>>>> >>>>> On 10/4/18, 12:29 AM, Daniil Titov wrote: >>>>>> Please review the changes that fix the deadlock in the debugger >>>>>> when the debugger is running with the tracing option on. >>>>>> >>>>>> The problem here is that when the tracing is on the "JDI Target >>>>>> VM Interface" thread (the thread that reads all replies and then >>>>>> notifies the thread that sent the request that the reply has been >>>>>> received) is waiting for a lock which is already acquired by the >>>>>> thread that sent the request and is waiting for reply. >>>>>> >>>>>> The fix itself is in >>>>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >>>>>> >>>>>> The patch also reverts the changes done in 8129348 "Debugger >>>>>> hangs in trace mode with TRACE_SENDS" in >>>>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >>>>>> since they address only a specific case (VM is suspended and >>>>>> static method is invoked) while the proposed fix also solves >>>>>> issue 8129348 as well as issue 8193801 "Debugger hangs in trace >>>>>> mode for non-static methods". >>>>>> >>>>>> The changes include new tests for issues 8193879, 8193801 and >>>>>> 8129348. >>>>>> >>>>>> The changes in >>>>>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >>>>>> solve the problem that the prompt is not printed in the debugger >>>>>> output when the breakpoint is hit and the suspend policy is >>>>>> SUSPEND_EVENT_THREAD. This is required for new tests to detect >>>>>> that command "stop thread at ..." is completed. >>>>>> >>>>>> Mach5 build and jdk_jdi tests succeeded. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >>>>>> >>>>>> Thanks, >>>>>> --Daniil >>>>>> >>>>>> >>>>>> >>>>> >>>> >> >> From doug.simon at oracle.com Fri Oct 5 15:22:18 2018 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 5 Oct 2018 17:22:18 +0200 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: <7FD94ACE-4CF4-488C-9A2B-C440429B915A@oracle.com> References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> <7FD94ACE-4CF4-488C-9A2B-C440429B915A@oracle.com> Message-ID: Hi, Testing found a bug in the original webrev. Namely, when clearing out a pending exception and returning null in the JVMCI ..._or_null stubs, the JavaThread::_vm_result field was not being set to NULL. I've addressed this in v2 of the webrev: Relative diff for bug fix: ----------------------------------------------------------------------------------------------- -// Manages a scope in which a failed heap allocation will throw an exception. -// The pending exception is cleared when leaving the scope. +// Manages a scope for a JVMCI runtime call that attempts a heap allocation. +// If there is a pending exception upon closing the scope and the runtime +// call is of the variety where allocation failure returns NULL without an +// exception, the following action is taken: +// 1. The pending exception is cleared +// 2. NULL is written to JavaThread::_vm_result +// 3. Checks that an OutOfMemoryError is Universe::out_of_memory_error_retry(). class RetryableAllocationMark: public StackObj { private: JavaThread* _thread; public: RetryableAllocationMark(JavaThread* thread, bool activate) { if (activate) { - assert(thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); + assert(!thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); _thread = thread; _thread->set_in_retryable_allocation(true); } else { @@ -136,6 +141,7 @@ ResourceMark rm; fatal("Unexpected exception in scope of retryable allocation: " INTPTR_FORMAT " of type %s", p2i(ex), ex->klass()->external_name()); } + _thread->set_vm_result(NULL); } } } ----------------------------------------------------------------------------------------------- I also took the opportunity to factor out negative array length checking: ----------------------------------------------------------------------------------------------- diff -r 4d36f5998a8b src/hotspot/share/oops/arrayKlass.cpp --- a/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 +++ b/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 @@ -130,9 +130,6 @@ } objArrayOop ArrayKlass::allocate_arrayArray(int n, int length, TRAPS) { - if (length < 0) { - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); - } check_array_allocation_length(length, arrayOopDesc::max_array_length(T_ARRAY), CHECK_0); int size = objArrayOopDesc::object_size(length); Klass* k = array_klass(n+dimension(), CHECK_0); diff -r 4d36f5998a8b src/hotspot/share/oops/instanceKlass.cpp --- a/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:04:06 2018 +0200 +++ b/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:17:17 2018 +0200 @@ -1201,9 +1201,6 @@ } objArrayOop InstanceKlass::allocate_objArray(int n, int length, TRAPS) { - if (length < 0) { - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); - } check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_NULL); int size = objArrayOopDesc::object_size(length); Klass* ak = array_klass(n, CHECK_NULL); diff -r 4d36f5998a8b src/hotspot/share/oops/klass.cpp --- a/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:04:06 2018 +0200 +++ b/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:17:17 2018 +0200 @@ -620,6 +620,8 @@ } else { THROW_OOP(Universe::out_of_memory_error_retry()); } + } else if (length < 0) { + THROW_MSG(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); } } diff -r 4d36f5998a8b src/hotspot/share/oops/klass.hpp --- a/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:04:06 2018 +0200 +++ b/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:17:17 2018 +0200 @@ -514,7 +514,7 @@ virtual Klass* array_klass_impl(bool or_null, int rank, TRAPS); virtual Klass* array_klass_impl(bool or_null, TRAPS); - // Error handling when length > max_length + // Error handling when length > max_length or length < 0 static void check_array_allocation_length(int length, int max_length, TRAPS); void set_vtable_length(int len) { _vtable_len= len; } diff -r 4d36f5998a8b src/hotspot/share/oops/objArrayKlass.cpp --- a/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 +++ b/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 @@ -170,14 +170,10 @@ } objArrayOop ObjArrayKlass::allocate(int length, TRAPS) { - if (length >= 0) { - check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); - int size = objArrayOopDesc::object_size(length); - return (objArrayOop)Universe::heap()->array_allocate(this, size, length, - /* do_zero */ true, THREAD); - } else { - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); - } + check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); + int size = objArrayOopDesc::object_size(length); + return (objArrayOop)Universe::heap()->array_allocate(this, size, length, + /* do_zero */ true, THREAD); } static int multi_alloc_counter = 0; diff -r 4d36f5998a8b src/hotspot/share/oops/typeArrayKlass.cpp --- a/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 +++ b/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 @@ -99,14 +99,10 @@ typeArrayOop TypeArrayKlass::allocate_common(int length, bool do_zero, TRAPS) { assert(log2_element_size() >= 0, "bad scale"); - if (length >= 0) { - check_array_allocation_length(length, max_length(), CHECK_NULL); - size_t size = typeArrayOopDesc::object_size(layout_helper(), length); - return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, - do_zero, CHECK_NULL); - } else { - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); - } + check_array_allocation_length(length, max_length(), CHECK_NULL); + size_t size = typeArrayOopDesc::object_size(layout_helper(), length); + return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, + do_zero, CHECK_NULL); } oop TypeArrayKlass::multi_allocate(int rank, jint* last_size, TRAPS) { ----------------------------------------------------------------------------------------------- Please confirm review these new changes: http://cr.openjdk.java.net/~dnsimon/8208686v2 -Doug > On 4 Oct 2018, at 00:20, Doug Simon wrote: > > Thanks for the reviews Serguei and Vladimir. > > Unless I hear objections in the next 24 hours, I'll push this webrev. > > -Doug > >> On 3 Oct 2018, at 03:14, serguei.spitsyn at oracle.com wrote: >> >> Hi Doug, >> >> The JVMTI related part looks good to me. >> Thank you for fixing it! >> >> Thanks, >> Serguei >> >> On 10/2/18 1:11 AM, Doug Simon wrote: >>> It would be great to get some input from the non-compilers teams on this RFR. >>> >>> -Doug >>> >>>> On 28 Sep 2018, at 19:51, Vladimir Kozlov wrote: >>>> >>>> To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>>>> Adding serviceability-dev at ... since this is JVM/TI... >>>>> Dan >>>>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>>>> A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. >>>>>> >>>>>> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, >>>>>> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. >>>>>> >>>>>> The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: >>>>>> * Returning null instead of throwing an exception on failure. >>>>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>>>> * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. >>>>>> This represents a significant number of changes. >>>>>> >>>>>> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. >>>>>> >>>>>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>>>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>>>> >>>>>> -Doug >> > From gary.adams at oracle.com Fri Oct 5 15:41:44 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 5 Oct 2018 11:41:44 -0400 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> Message-ID: <3e2e9d07-aece-6471-b263-fe1c5effca6a@oracle.com> Looks OK to me. On 10/4/18 5:19 PM, Daniil Titov wrote: > Hi Gary and Chris, > > Please review an updated version of the patch that has newly added test for the case when suspend policy is set to SUSPEND_EVENT_THREAD reimplemented using JDI API. Thus, the changes in src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java are no longer required. > > I think vmInterrupted() is not invoked when suspend policy is set to SUSPEND_EVENT_THREAD to address the case when different threads keep hitting the same breakpoint and to avoid the switching the current thread in the background. > > The actual behavior of the debugger in the case when the breakpoint is hit and suspend policy is set to SUSPEND_EVENT_THREAD is just to print "Breakpoint hit:" in the output without adding any additional information or new line character. After that you need to set the current thread by entering "thread" command , e.g. "thread 1" and only then jdb prints the prompt (e.g. "main[1]") . The behavior looks as confusing since it is not obvious for the user that some input is expected from him (e.g. to set the current thread). I created a separated issue for that at https://bugs.openjdk.java.net/browse/JDK-8211736 . > > Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.02/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 > > Thanks, > --Daniil > > ?On 10/4/18, 10:28 AM, "Chris Plummer" wrote: > > On 10/4/18 5:12 AM, Gary Adams wrote: > > In TTY.java do you need to force a simple prompt for the > > breakpoint event output? What prevents currentThread from > > being set at the time you are printing the prompt? > > > > > > 103 // Print the prompt if suspend policy is > > SUSPEND_EVENT_THREAD. In case of > > 104 // SUSPEND_ALL policy this is handled by vmInterrupted() > > method. > > 105 if (be.request().suspendPolicy() == > > EventRequest.SUSPEND_EVENT_THREAD) { > > 106 MessageOutput.println(); > > 107 MessageOutput.printPrompt(); > Normally the thread is suspended after the above code is executed: > > public void run() { > EventQueue queue = Env.vm().eventQueue(); > while (connected) { > try { > EventSet eventSet = queue.remove(); > boolean resumeStoppedApp = false; > EventIterator it = eventSet.eventIterator(); > while (it.hasNext()) { > resumeStoppedApp |= !handleEvent(it.nextEvent()); > <--- calls the modified code above > } > > if (resumeStoppedApp) { > eventSet.resume(); > } else if (eventSet.suspendPolicy() == > EventRequest.SUSPEND_ALL) { > setCurrentThread(eventSet); <------ > notifier.vmInterrupted(); > } > > However, it only calls setCurrentThread() for SUSPEND_ALL policies. So > what Daniil has done here is make it print a simple prompt if the policy > is SUSPEND_EVENT_THREAD. It's unclear to me what the actual debugger > behavior is in this case. Don't we still suspend and get a prompt from > which we can type in the next command? In this case, wouldn't you want a > full prompt? Related to that question, why is vmInterrupted() only > called if we suspend all threads, and not when we just suspend the > thread that the breakpoint came in on? > > Chris > > > > > > In Jdb.java you allow the waiting for the simple prompt. > > I don't see waitForSimplePrompt used in any existing tests. > > Since it is only looking for a single character it could > > produce false positives if the '>' was produced in the > > output stream. Is this wait paired to the added prompt for the > > break point event? > > > > 236 return waitForSimplePrompt ? waitForSimplePrompt(1, > > cmd.allowExit) : waitForPrompt(1, cmd.allowExit); > > > > It might be a good idea to include a test with multiple > > threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD > > behavior. > > > > On 10/4/18, 12:29 AM, Daniil Titov wrote: > >> Please review the changes that fix the deadlock in the debugger when > >> the debugger is running with the tracing option on. > >> > >> The problem here is that when the tracing is on the "JDI Target VM > >> Interface" thread (the thread that reads all replies and then > >> notifies the thread that sent the request that the reply has been > >> received) is waiting for a lock which is already acquired by the > >> thread that sent the request and is waiting for reply. > >> > >> The fix itself is in > >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. > >> > >> The patch also reverts the changes done in 8129348 "Debugger hangs in > >> trace mode with TRACE_SENDS" in > >> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java > >> since they address only a specific case (VM is suspended and static > >> method is invoked) while the proposed fix also solves issue 8129348 > >> as well as issue 8193801 "Debugger hangs in trace mode for non-static > >> methods". > >> > >> The changes include new tests for issues 8193879, 8193801 and 8129348. > >> > >> The changes in > >> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > >> solve the problem that the prompt is not printed in the debugger > >> output when the breakpoint is hit and the suspend policy is > >> SUSPEND_EVENT_THREAD. This is required for new tests to detect that > >> command "stop thread at ..." is completed. > >> > >> Mach5 build and jdk_jdi tests succeeded. > >> > >> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ > >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 > >> > >> Thanks, > >> --Daniil > >> > >> > >> > > > > > > From vladimir.kozlov at oracle.com Fri Oct 5 16:05:54 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 5 Oct 2018 09:05:54 -0700 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> <7FD94ACE-4CF4-488C-9A2B-C440429B915A@oracle.com> Message-ID: <407cc96c-c846-83f8-a924-9df6705a031f@oracle.com> Looks good. Thanks, Vladimir On 10/5/18 8:22 AM, Doug Simon wrote: > Hi, > > Testing found a bug in the original webrev. Namely, when clearing out a pending exception and returning null in the JVMCI ..._or_null stubs, the JavaThread::_vm_result field was not being set to NULL. I've addressed this in v2 of the webrev: > > Relative diff for bug fix: > > ----------------------------------------------------------------------------------------------- > -// Manages a scope in which a failed heap allocation will throw an exception. > -// The pending exception is cleared when leaving the scope. > +// Manages a scope for a JVMCI runtime call that attempts a heap allocation. > +// If there is a pending exception upon closing the scope and the runtime > +// call is of the variety where allocation failure returns NULL without an > +// exception, the following action is taken: > +// 1. The pending exception is cleared > +// 2. NULL is written to JavaThread::_vm_result > +// 3. Checks that an OutOfMemoryError is Universe::out_of_memory_error_retry(). > class RetryableAllocationMark: public StackObj { > private: > JavaThread* _thread; > public: > RetryableAllocationMark(JavaThread* thread, bool activate) { > if (activate) { > - assert(thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); > + assert(!thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); > _thread = thread; > _thread->set_in_retryable_allocation(true); > } else { > @@ -136,6 +141,7 @@ > ResourceMark rm; > fatal("Unexpected exception in scope of retryable allocation: " INTPTR_FORMAT " of type %s", p2i(ex), ex->klass()->external_name()); > } > + _thread->set_vm_result(NULL); > } > } > } > ----------------------------------------------------------------------------------------------- > > I also took the opportunity to factor out negative array length checking: > > ----------------------------------------------------------------------------------------------- > diff -r 4d36f5998a8b src/hotspot/share/oops/arrayKlass.cpp > --- a/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -130,9 +130,6 @@ > } > > objArrayOop ArrayKlass::allocate_arrayArray(int n, int length, TRAPS) { > - if (length < 0) { > - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > - } > check_array_allocation_length(length, arrayOopDesc::max_array_length(T_ARRAY), CHECK_0); > int size = objArrayOopDesc::object_size(length); > Klass* k = array_klass(n+dimension(), CHECK_0); > diff -r 4d36f5998a8b src/hotspot/share/oops/instanceKlass.cpp > --- a/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -1201,9 +1201,6 @@ > } > > objArrayOop InstanceKlass::allocate_objArray(int n, int length, TRAPS) { > - if (length < 0) { > - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > - } > check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_NULL); > int size = objArrayOopDesc::object_size(length); > Klass* ak = array_klass(n, CHECK_NULL); > diff -r 4d36f5998a8b src/hotspot/share/oops/klass.cpp > --- a/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -620,6 +620,8 @@ > } else { > THROW_OOP(Universe::out_of_memory_error_retry()); > } > + } else if (length < 0) { > + THROW_MSG(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > } > } > > diff -r 4d36f5998a8b src/hotspot/share/oops/klass.hpp > --- a/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:17:17 2018 +0200 > @@ -514,7 +514,7 @@ > virtual Klass* array_klass_impl(bool or_null, int rank, TRAPS); > virtual Klass* array_klass_impl(bool or_null, TRAPS); > > - // Error handling when length > max_length > + // Error handling when length > max_length or length < 0 > static void check_array_allocation_length(int length, int max_length, TRAPS); > > void set_vtable_length(int len) { _vtable_len= len; } > diff -r 4d36f5998a8b src/hotspot/share/oops/objArrayKlass.cpp > --- a/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -170,14 +170,10 @@ > } > > objArrayOop ObjArrayKlass::allocate(int length, TRAPS) { > - if (length >= 0) { > - check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); > - int size = objArrayOopDesc::object_size(length); > - return (objArrayOop)Universe::heap()->array_allocate(this, size, length, > - /* do_zero */ true, THREAD); > - } else { > - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > - } > + check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); > + int size = objArrayOopDesc::object_size(length); > + return (objArrayOop)Universe::heap()->array_allocate(this, size, length, > + /* do_zero */ true, THREAD); > } > > static int multi_alloc_counter = 0; > diff -r 4d36f5998a8b src/hotspot/share/oops/typeArrayKlass.cpp > --- a/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -99,14 +99,10 @@ > > typeArrayOop TypeArrayKlass::allocate_common(int length, bool do_zero, TRAPS) { > assert(log2_element_size() >= 0, "bad scale"); > - if (length >= 0) { > - check_array_allocation_length(length, max_length(), CHECK_NULL); > - size_t size = typeArrayOopDesc::object_size(layout_helper(), length); > - return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, > - do_zero, CHECK_NULL); > - } else { > - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > - } > + check_array_allocation_length(length, max_length(), CHECK_NULL); > + size_t size = typeArrayOopDesc::object_size(layout_helper(), length); > + return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, > + do_zero, CHECK_NULL); > } > > oop TypeArrayKlass::multi_allocate(int rank, jint* last_size, TRAPS) { > ----------------------------------------------------------------------------------------------- > > Please confirm review these new changes: > > http://cr.openjdk.java.net/~dnsimon/8208686v2 > > -Doug > > >> On 4 Oct 2018, at 00:20, Doug Simon wrote: >> >> Thanks for the reviews Serguei and Vladimir. >> >> Unless I hear objections in the next 24 hours, I'll push this webrev. >> >> -Doug >> >>> On 3 Oct 2018, at 03:14, serguei.spitsyn at oracle.com wrote: >>> >>> Hi Doug, >>> >>> The JVMTI related part looks good to me. >>> Thank you for fixing it! >>> >>> Thanks, >>> Serguei >>> >>> On 10/2/18 1:11 AM, Doug Simon wrote: >>>> It would be great to get some input from the non-compilers teams on this RFR. >>>> >>>> -Doug >>>> >>>>> On 28 Sep 2018, at 19:51, Vladimir Kozlov wrote: >>>>> >>>>> To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>>>>> Adding serviceability-dev at ... since this is JVM/TI... >>>>>> Dan >>>>>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>>>>> A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. >>>>>>> >>>>>>> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, >>>>>>> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. >>>>>>> >>>>>>> The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: >>>>>>> * Returning null instead of throwing an exception on failure. >>>>>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>>>>> * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. >>>>>>> This represents a significant number of changes. >>>>>>> >>>>>>> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. >>>>>>> >>>>>>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>>>>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>>>>> >>>>>>> -Doug >>> >> > From tom.rodriguez at oracle.com Fri Oct 5 17:27:08 2018 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 5 Oct 2018 10:27:08 -0700 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> <7FD94ACE-4CF4-488C-9A2B-C440429B915A@oracle.com> Message-ID: Looks good. tom Doug Simon wrote on 10/5/18 8:22 AM: > Hi, > > Testing found a bug in the original webrev. Namely, when clearing out a pending exception and returning null in the JVMCI ..._or_null stubs, the JavaThread::_vm_result field was not being set to NULL. I've addressed this in v2 of the webrev: > > Relative diff for bug fix: > > ----------------------------------------------------------------------------------------------- > -// Manages a scope in which a failed heap allocation will throw an exception. > -// The pending exception is cleared when leaving the scope. > +// Manages a scope for a JVMCI runtime call that attempts a heap allocation. > +// If there is a pending exception upon closing the scope and the runtime > +// call is of the variety where allocation failure returns NULL without an > +// exception, the following action is taken: > +// 1. The pending exception is cleared > +// 2. NULL is written to JavaThread::_vm_result > +// 3. Checks that an OutOfMemoryError is Universe::out_of_memory_error_retry(). > class RetryableAllocationMark: public StackObj { > private: > JavaThread* _thread; > public: > RetryableAllocationMark(JavaThread* thread, bool activate) { > if (activate) { > - assert(thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); > + assert(!thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); > _thread = thread; > _thread->set_in_retryable_allocation(true); > } else { > @@ -136,6 +141,7 @@ > ResourceMark rm; > fatal("Unexpected exception in scope of retryable allocation: " INTPTR_FORMAT " of type %s", p2i(ex), ex->klass()->external_name()); > } > + _thread->set_vm_result(NULL); > } > } > } > ----------------------------------------------------------------------------------------------- > > I also took the opportunity to factor out negative array length checking: > > ----------------------------------------------------------------------------------------------- > diff -r 4d36f5998a8b src/hotspot/share/oops/arrayKlass.cpp > --- a/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -130,9 +130,6 @@ > } > > objArrayOop ArrayKlass::allocate_arrayArray(int n, int length, TRAPS) { > - if (length < 0) { > - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > - } > check_array_allocation_length(length, arrayOopDesc::max_array_length(T_ARRAY), CHECK_0); > int size = objArrayOopDesc::object_size(length); > Klass* k = array_klass(n+dimension(), CHECK_0); > diff -r 4d36f5998a8b src/hotspot/share/oops/instanceKlass.cpp > --- a/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -1201,9 +1201,6 @@ > } > > objArrayOop InstanceKlass::allocate_objArray(int n, int length, TRAPS) { > - if (length < 0) { > - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > - } > check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_NULL); > int size = objArrayOopDesc::object_size(length); > Klass* ak = array_klass(n, CHECK_NULL); > diff -r 4d36f5998a8b src/hotspot/share/oops/klass.cpp > --- a/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -620,6 +620,8 @@ > } else { > THROW_OOP(Universe::out_of_memory_error_retry()); > } > + } else if (length < 0) { > + THROW_MSG(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > } > } > > diff -r 4d36f5998a8b src/hotspot/share/oops/klass.hpp > --- a/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:17:17 2018 +0200 > @@ -514,7 +514,7 @@ > virtual Klass* array_klass_impl(bool or_null, int rank, TRAPS); > virtual Klass* array_klass_impl(bool or_null, TRAPS); > > - // Error handling when length > max_length > + // Error handling when length > max_length or length < 0 > static void check_array_allocation_length(int length, int max_length, TRAPS); > > void set_vtable_length(int len) { _vtable_len= len; } > diff -r 4d36f5998a8b src/hotspot/share/oops/objArrayKlass.cpp > --- a/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -170,14 +170,10 @@ > } > > objArrayOop ObjArrayKlass::allocate(int length, TRAPS) { > - if (length >= 0) { > - check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); > - int size = objArrayOopDesc::object_size(length); > - return (objArrayOop)Universe::heap()->array_allocate(this, size, length, > - /* do_zero */ true, THREAD); > - } else { > - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > - } > + check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); > + int size = objArrayOopDesc::object_size(length); > + return (objArrayOop)Universe::heap()->array_allocate(this, size, length, > + /* do_zero */ true, THREAD); > } > > static int multi_alloc_counter = 0; > diff -r 4d36f5998a8b src/hotspot/share/oops/typeArrayKlass.cpp > --- a/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 > +++ b/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 > @@ -99,14 +99,10 @@ > > typeArrayOop TypeArrayKlass::allocate_common(int length, bool do_zero, TRAPS) { > assert(log2_element_size() >= 0, "bad scale"); > - if (length >= 0) { > - check_array_allocation_length(length, max_length(), CHECK_NULL); > - size_t size = typeArrayOopDesc::object_size(layout_helper(), length); > - return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, > - do_zero, CHECK_NULL); > - } else { > - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); > - } > + check_array_allocation_length(length, max_length(), CHECK_NULL); > + size_t size = typeArrayOopDesc::object_size(layout_helper(), length); > + return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, > + do_zero, CHECK_NULL); > } > > oop TypeArrayKlass::multi_allocate(int rank, jint* last_size, TRAPS) { > ----------------------------------------------------------------------------------------------- > > Please confirm review these new changes: > > http://cr.openjdk.java.net/~dnsimon/8208686v2 > > -Doug > > >> On 4 Oct 2018, at 00:20, Doug Simon wrote: >> >> Thanks for the reviews Serguei and Vladimir. >> >> Unless I hear objections in the next 24 hours, I'll push this webrev. >> >> -Doug >> >>> On 3 Oct 2018, at 03:14, serguei.spitsyn at oracle.com wrote: >>> >>> Hi Doug, >>> >>> The JVMTI related part looks good to me. >>> Thank you for fixing it! >>> >>> Thanks, >>> Serguei >>> >>> On 10/2/18 1:11 AM, Doug Simon wrote: >>>> It would be great to get some input from the non-compilers teams on this RFR. >>>> >>>> -Doug >>>> >>>>> On 28 Sep 2018, at 19:51, Vladimir Kozlov wrote: >>>>> >>>>> To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>>>>> Adding serviceability-dev at ... since this is JVM/TI... >>>>>> Dan >>>>>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>>>>> A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. >>>>>>> >>>>>>> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, >>>>>>> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. >>>>>>> >>>>>>> The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: >>>>>>> * Returning null instead of throwing an exception on failure. >>>>>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>>>>> * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. >>>>>>> This represents a significant number of changes. >>>>>>> >>>>>>> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. >>>>>>> >>>>>>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>>>>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>>>>> >>>>>>> -Doug >>> >> > From jcbeyler at google.com Fri Oct 5 17:34:55 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 5 Oct 2018 10:34:55 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> Message-ID: Hi Alex, One question and a comment on this: - I thought HashMap was not thread safe so I think you need to synchronize the access to the map threadData - I think your test code could be simplified if you moved it into a helper method (not tested but just for example): + private void next() { + List reply = jdb.command(JdbCommand.next()); + /* + * Each "next" produces something like ("Breakpoint hit" line only if the line has BP) + * Step completed: + * Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), line=74 bci=12 + * 74 ++count2; // @2 breakpoint + * + * jj2[1] + */ + // detect thread from the last line + String lastLine = reply.get(reply.size() - 1); + String threadName = parse(threadRegexp, lastLine); + String wholeReply = reply.stream().collect(Collectors.joining(Utils.NEW_LINE)); + int lineNum = Integer.parseInt(parse(lineRegexp, wholeReply)); + + System.out.println("got: thread=" + threadName + ", line=" + lineNum); + + ThreadData data = threadData.get(threadName); + if (data == null) { + data = new ThreadData(); + threadData.put(threadName, data); + } + processNewData(data, threadName, lineNum); + data.lastLine = lineNum; + } + + private void processNewData(ThreadData data, String threadName, int lineNum) { + if (data.lastLine < 0) { + // the 1st stop in the thread + return; + } + + if (lineNum == data.lastLine + 1) { + // expected. + return; + } + + if (lineNum < data.lastLine) { + // looks like step to the beginning of the cycle + if (data.minLine > 0) { + // minLine and maxLine are not set - verify + Asserts.assertEquals(lineNum, data.minLine, threadName + " - minLine"); + Asserts.assertEquals(data.lastLine, data.maxLine, threadName + " - maxLine"); + } else { + // set minLine/maxLine + data.minLine = lineNum; + data.maxLine = data.lastLine; + } + return; + } + + throw new RuntimeException(threadName + " (line " + lineNum + ") - unexpected." + + " lastLine=" + data.lastLine + ", minLine=" + data.minLine + ", maxLine=" + data.maxLine); + } Thanks, Jc On Thu, Oct 4, 2018 at 6:31 PM wrote: > Hi Alex, > > It looks good to me. > Could you, please, also remove the line? : > > 156 // > > No need in new webrev. > > Thanks, > Serguei > > > On 10/4/18 4:11 PM, Alex Menkov wrote: > > Hi Serguei, > > > > Updated webrev: > > > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ > > > > Fixed all issues except > > 140 // the 1st stop in the thread > > 141 break; > > In this case the comment is an explanation why we reach the block, not > > an explanation for the "break" statement. > > > > --alex > > > > On 10/04/2018 13:56, serguei.spitsyn at oracle.com wrote: > >> Hi Alex, > >> > >> Several minor suggestions. > >> > >> 77 new Thread(aRP, "jj1").start(); > >> 78 new Thread(asRP, "jj2").start(); What mean aRP and asRP? In fact, > >> it is confusing. Can they be renamed to something like obj1 and obj2. > >> > >> 79 // new Thread(aRP, "jj3").start(); > >> 80 // new Thread(asRP, "jj4").start(); > >> > >> These lines can be removed. > >> > >> 94 // line of the last stop > >> 95 int lastLine = -1; > >> 96 // min line (-1 means "not known yet") > >> 97 int minLine = -1; > >> 98 // max line (-1 means "not known yet") > >> 99 int maxLine = -1; ... 140 // the 1st stop in the thread > >> 141 break; > >> > >> I'd suggest the refactor above as below: > >> > >> int lastLine = -1; // line of the last stop > >> int minLine = -1; // min line (-1 means "not known yet") > >> int maxLine = -1;// max line (-1 means "not known yet") > >> ... > >> break; // the 1st stop in the thread > >> > >> 116 private void next() { > >> 117 List reply = jdb.command(JdbCommand.next()); > >> 118 /* each "next" produces something like ("Breakpoint hit" line > >> only if the line has BP) > >> 119 Step completed: > >> 120 Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), > >> line=74 bci=12 > >> 121 74 ++count2; // @2 breakpoint > >> 122 > >> 123 jj2[1] > >> 124 */ It would better to have it in this style: 118 /* * Each "next" > >> produces something like ("Breakpoint hit" line only if the line has BP). > >> 119 * Step completed: > >> 120 * Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), > >> line=74 bci=12 > >> 121 * 74 ++count2; // @2 breakpoint > >> 122 * > >> 123 * jj2[1] > >> 124 */ > >> > >> > >> Otherwise, it looks Okay to me. > >> > >> > >> Thanks, > >> Serguei > >> > >> On 10/3/18 5:49 PM, Alex Menkov wrote: > >>> Hi all, > >>> > >>> please review a fix for > >>> https://bugs.openjdk.java.net/browse/JDK-8211292 > >>> webrev: > >>> http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ > >>> > >>> The fix converts manual shell test to automatic java (as Java allows > >>> to parse jdb replies much easier). > >>> This is the last sub-task for the "shell to java conversion" task, > >>> so the fix also removes shared shell scripts. > >>> > >>> --alex > >> > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Fri Oct 5 17:58:39 2018 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 5 Oct 2018 19:58:39 +0200 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: <407cc96c-c846-83f8-a924-9df6705a031f@oracle.com> References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> <7FD94ACE-4CF4-488C-9A2B-C440429B915A@oracle.com> <407cc96c-c846-83f8-a924-9df6705a031f@oracle.com> Message-ID: Thanks for re-reviewing. -Doug > On 5 Oct 2018, at 18:05, Vladimir Kozlov wrote: > > Looks good. > > Thanks, > Vladimir > > On 10/5/18 8:22 AM, Doug Simon wrote: >> Hi, >> Testing found a bug in the original webrev. Namely, when clearing out a pending exception and returning null in the JVMCI ..._or_null stubs, the JavaThread::_vm_result field was not being set to NULL. I've addressed this in v2 of the webrev: >> Relative diff for bug fix: >> ----------------------------------------------------------------------------------------------- >> -// Manages a scope in which a failed heap allocation will throw an exception. >> -// The pending exception is cleared when leaving the scope. >> +// Manages a scope for a JVMCI runtime call that attempts a heap allocation. >> +// If there is a pending exception upon closing the scope and the runtime >> +// call is of the variety where allocation failure returns NULL without an >> +// exception, the following action is taken: >> +// 1. The pending exception is cleared >> +// 2. NULL is written to JavaThread::_vm_result >> +// 3. Checks that an OutOfMemoryError is Universe::out_of_memory_error_retry(). >> class RetryableAllocationMark: public StackObj { >> private: >> JavaThread* _thread; >> public: >> RetryableAllocationMark(JavaThread* thread, bool activate) { >> if (activate) { >> - assert(thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); >> + assert(!thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); >> _thread = thread; >> _thread->set_in_retryable_allocation(true); >> } else { >> @@ -136,6 +141,7 @@ >> ResourceMark rm; >> fatal("Unexpected exception in scope of retryable allocation: " INTPTR_FORMAT " of type %s", p2i(ex), ex->klass()->external_name()); >> } >> + _thread->set_vm_result(NULL); >> } >> } >> } >> ----------------------------------------------------------------------------------------------- >> I also took the opportunity to factor out negative array length checking: >> ----------------------------------------------------------------------------------------------- >> diff -r 4d36f5998a8b src/hotspot/share/oops/arrayKlass.cpp >> --- a/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -130,9 +130,6 @@ >> } >> objArrayOop ArrayKlass::allocate_arrayArray(int n, int length, TRAPS) { >> - if (length < 0) { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> - } >> check_array_allocation_length(length, arrayOopDesc::max_array_length(T_ARRAY), CHECK_0); >> int size = objArrayOopDesc::object_size(length); >> Klass* k = array_klass(n+dimension(), CHECK_0); >> diff -r 4d36f5998a8b src/hotspot/share/oops/instanceKlass.cpp >> --- a/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -1201,9 +1201,6 @@ >> } >> objArrayOop InstanceKlass::allocate_objArray(int n, int length, TRAPS) { >> - if (length < 0) { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> - } >> check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_NULL); >> int size = objArrayOopDesc::object_size(length); >> Klass* ak = array_klass(n, CHECK_NULL); >> diff -r 4d36f5998a8b src/hotspot/share/oops/klass.cpp >> --- a/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -620,6 +620,8 @@ >> } else { >> THROW_OOP(Universe::out_of_memory_error_retry()); >> } >> + } else if (length < 0) { >> + THROW_MSG(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> } >> } >> diff -r 4d36f5998a8b src/hotspot/share/oops/klass.hpp >> --- a/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -514,7 +514,7 @@ >> virtual Klass* array_klass_impl(bool or_null, int rank, TRAPS); >> virtual Klass* array_klass_impl(bool or_null, TRAPS); >> - // Error handling when length > max_length >> + // Error handling when length > max_length or length < 0 >> static void check_array_allocation_length(int length, int max_length, TRAPS); >> void set_vtable_length(int len) { _vtable_len= len; } >> diff -r 4d36f5998a8b src/hotspot/share/oops/objArrayKlass.cpp >> --- a/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -170,14 +170,10 @@ >> } >> objArrayOop ObjArrayKlass::allocate(int length, TRAPS) { >> - if (length >= 0) { >> - check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); >> - int size = objArrayOopDesc::object_size(length); >> - return (objArrayOop)Universe::heap()->array_allocate(this, size, length, >> - /* do_zero */ true, THREAD); >> - } else { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> - } >> + check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); >> + int size = objArrayOopDesc::object_size(length); >> + return (objArrayOop)Universe::heap()->array_allocate(this, size, length, >> + /* do_zero */ true, THREAD); >> } >> static int multi_alloc_counter = 0; >> diff -r 4d36f5998a8b src/hotspot/share/oops/typeArrayKlass.cpp >> --- a/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -99,14 +99,10 @@ >> typeArrayOop TypeArrayKlass::allocate_common(int length, bool do_zero, TRAPS) { >> assert(log2_element_size() >= 0, "bad scale"); >> - if (length >= 0) { >> - check_array_allocation_length(length, max_length(), CHECK_NULL); >> - size_t size = typeArrayOopDesc::object_size(layout_helper(), length); >> - return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, >> - do_zero, CHECK_NULL); >> - } else { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> - } >> + check_array_allocation_length(length, max_length(), CHECK_NULL); >> + size_t size = typeArrayOopDesc::object_size(layout_helper(), length); >> + return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, >> + do_zero, CHECK_NULL); >> } >> oop TypeArrayKlass::multi_allocate(int rank, jint* last_size, TRAPS) { >> ----------------------------------------------------------------------------------------------- >> Please confirm review these new changes: >> http://cr.openjdk.java.net/~dnsimon/8208686v2 >> -Doug >>> On 4 Oct 2018, at 00:20, Doug Simon wrote: >>> >>> Thanks for the reviews Serguei and Vladimir. >>> >>> Unless I hear objections in the next 24 hours, I'll push this webrev. >>> >>> -Doug >>> >>>> On 3 Oct 2018, at 03:14, serguei.spitsyn at oracle.com wrote: >>>> >>>> Hi Doug, >>>> >>>> The JVMTI related part looks good to me. >>>> Thank you for fixing it! >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/2/18 1:11 AM, Doug Simon wrote: >>>>> It would be great to get some input from the non-compilers teams on this RFR. >>>>> >>>>> -Doug >>>>> >>>>>> On 28 Sep 2018, at 19:51, Vladimir Kozlov wrote: >>>>>> >>>>>> To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>>>>>> Adding serviceability-dev at ... since this is JVM/TI... >>>>>>> Dan >>>>>>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>>>>>> A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. >>>>>>>> >>>>>>>> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, >>>>>>>> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. >>>>>>>> >>>>>>>> The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: >>>>>>>> * Returning null instead of throwing an exception on failure. >>>>>>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>>>>>> * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. >>>>>>>> This represents a significant number of changes. >>>>>>>> >>>>>>>> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. >>>>>>>> >>>>>>>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>>>>>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>>>>>> >>>>>>>> -Doug >>>> >>> From doug.simon at oracle.com Fri Oct 5 17:58:56 2018 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 5 Oct 2018 19:58:56 +0200 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> <7FD94ACE-4CF4-488C-9A2B-C440429B915A@oracle.com> Message-ID: Thanks for the review. -Doug > On 5 Oct 2018, at 19:27, Tom Rodriguez wrote: > > Looks good. > > tom > > Doug Simon wrote on 10/5/18 8:22 AM: >> Hi, >> Testing found a bug in the original webrev. Namely, when clearing out a pending exception and returning null in the JVMCI ..._or_null stubs, the JavaThread::_vm_result field was not being set to NULL. I've addressed this in v2 of the webrev: >> Relative diff for bug fix: >> ----------------------------------------------------------------------------------------------- >> -// Manages a scope in which a failed heap allocation will throw an exception. >> -// The pending exception is cleared when leaving the scope. >> +// Manages a scope for a JVMCI runtime call that attempts a heap allocation. >> +// If there is a pending exception upon closing the scope and the runtime >> +// call is of the variety where allocation failure returns NULL without an >> +// exception, the following action is taken: >> +// 1. The pending exception is cleared >> +// 2. NULL is written to JavaThread::_vm_result >> +// 3. Checks that an OutOfMemoryError is Universe::out_of_memory_error_retry(). >> class RetryableAllocationMark: public StackObj { >> private: >> JavaThread* _thread; >> public: >> RetryableAllocationMark(JavaThread* thread, bool activate) { >> if (activate) { >> - assert(thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); >> + assert(!thread->in_retryable_allocation(), "retryable allocation scope is non-reentrant"); >> _thread = thread; >> _thread->set_in_retryable_allocation(true); >> } else { >> @@ -136,6 +141,7 @@ >> ResourceMark rm; >> fatal("Unexpected exception in scope of retryable allocation: " INTPTR_FORMAT " of type %s", p2i(ex), ex->klass()->external_name()); >> } >> + _thread->set_vm_result(NULL); >> } >> } >> } >> ----------------------------------------------------------------------------------------------- >> I also took the opportunity to factor out negative array length checking: >> ----------------------------------------------------------------------------------------------- >> diff -r 4d36f5998a8b src/hotspot/share/oops/arrayKlass.cpp >> --- a/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/arrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -130,9 +130,6 @@ >> } >> objArrayOop ArrayKlass::allocate_arrayArray(int n, int length, TRAPS) { >> - if (length < 0) { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> - } >> check_array_allocation_length(length, arrayOopDesc::max_array_length(T_ARRAY), CHECK_0); >> int size = objArrayOopDesc::object_size(length); >> Klass* k = array_klass(n+dimension(), CHECK_0); >> diff -r 4d36f5998a8b src/hotspot/share/oops/instanceKlass.cpp >> --- a/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/instanceKlass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -1201,9 +1201,6 @@ >> } >> objArrayOop InstanceKlass::allocate_objArray(int n, int length, TRAPS) { >> - if (length < 0) { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> - } >> check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_NULL); >> int size = objArrayOopDesc::object_size(length); >> Klass* ak = array_klass(n, CHECK_NULL); >> diff -r 4d36f5998a8b src/hotspot/share/oops/klass.cpp >> --- a/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/klass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -620,6 +620,8 @@ >> } else { >> THROW_OOP(Universe::out_of_memory_error_retry()); >> } >> + } else if (length < 0) { >> + THROW_MSG(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> } >> } >> diff -r 4d36f5998a8b src/hotspot/share/oops/klass.hpp >> --- a/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/klass.hpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -514,7 +514,7 @@ >> virtual Klass* array_klass_impl(bool or_null, int rank, TRAPS); >> virtual Klass* array_klass_impl(bool or_null, TRAPS); >> - // Error handling when length > max_length >> + // Error handling when length > max_length or length < 0 >> static void check_array_allocation_length(int length, int max_length, TRAPS); >> void set_vtable_length(int len) { _vtable_len= len; } >> diff -r 4d36f5998a8b src/hotspot/share/oops/objArrayKlass.cpp >> --- a/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/objArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -170,14 +170,10 @@ >> } >> objArrayOop ObjArrayKlass::allocate(int length, TRAPS) { >> - if (length >= 0) { >> - check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); >> - int size = objArrayOopDesc::object_size(length); >> - return (objArrayOop)Universe::heap()->array_allocate(this, size, length, >> - /* do_zero */ true, THREAD); >> - } else { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> - } >> + check_array_allocation_length(length, arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); >> + int size = objArrayOopDesc::object_size(length); >> + return (objArrayOop)Universe::heap()->array_allocate(this, size, length, >> + /* do_zero */ true, THREAD); >> } >> static int multi_alloc_counter = 0; >> diff -r 4d36f5998a8b src/hotspot/share/oops/typeArrayKlass.cpp >> --- a/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/typeArrayKlass.cpp Fri Oct 05 17:17:17 2018 +0200 >> @@ -99,14 +99,10 @@ >> typeArrayOop TypeArrayKlass::allocate_common(int length, bool do_zero, TRAPS) { >> assert(log2_element_size() >= 0, "bad scale"); >> - if (length >= 0) { >> - check_array_allocation_length(length, max_length(), CHECK_NULL); >> - size_t size = typeArrayOopDesc::object_size(layout_helper(), length); >> - return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, >> - do_zero, CHECK_NULL); >> - } else { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), err_msg("%d", length)); >> - } >> + check_array_allocation_length(length, max_length(), CHECK_NULL); >> + size_t size = typeArrayOopDesc::object_size(layout_helper(), length); >> + return (typeArrayOop)Universe::heap()->array_allocate(this, (int)size, length, >> + do_zero, CHECK_NULL); >> } >> oop TypeArrayKlass::multi_allocate(int rank, jint* last_size, TRAPS) { >> ----------------------------------------------------------------------------------------------- >> Please confirm review these new changes: >> http://cr.openjdk.java.net/~dnsimon/8208686v2 >> -Doug >>> On 4 Oct 2018, at 00:20, Doug Simon wrote: >>> >>> Thanks for the reviews Serguei and Vladimir. >>> >>> Unless I hear objections in the next 24 hours, I'll push this webrev. >>> >>> -Doug >>> >>>> On 3 Oct 2018, at 03:14, serguei.spitsyn at oracle.com wrote: >>>> >>>> Hi Doug, >>>> >>>> The JVMTI related part looks good to me. >>>> Thank you for fixing it! >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/2/18 1:11 AM, Doug Simon wrote: >>>>> It would be great to get some input from the non-compilers teams on this RFR. >>>>> >>>>> -Doug >>>>> >>>>>> On 28 Sep 2018, at 19:51, Vladimir Kozlov wrote: >>>>>> >>>>>> To let you know, me and Tom R. did review these changes and agreed that it is the least intrusive changes for Hotspot shared code. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>>>>>> Adding serviceability-dev at ... since this is JVM/TI... >>>>>>> Dan >>>>>>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>>>>>> A major design point of Graal is to treat allocations as non-side effecting to give more freedom to the optimizer by reducing the number of distinct FrameStates that need to be managed. When failing an allocation, Graal will deoptimize to the last side effecting instruction before the allocation. This mean the VM code for heap allocation will potentially be executed twice, once from Graal compiled code and then again in the interpreter. While this is perfectly fine according to the JVM specification, it can cause confusing behavior for JVMTI based tools. They will receive 2 ResourceExhausted events for a single allocation. Furthermore, the first ResourceExhausted event (on the Graal allocation slow path) might denote a bytecode instruction that performs no allocation, making it hard to debug the memory failure. >>>>>>>> >>>>>>>> The proposed solution is to add an extra set of JVMCI VM runtime calls for allocation. These entry points will attempt the allocation and upon failure, >>>>>>>> skip side-effects such as posting JVMTI events or handling -XX:OnOutOfMemoryError. The compiled code using these entry points is expected deoptmize on null. >>>>>>>> >>>>>>>> The path from these new entry points to where allocation can fail goes through quite a bit of VM code. One could modify all these paths by: >>>>>>>> * Returning null instead of throwing an exception on failure. >>>>>>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>>>>>> * Adding extra null checking where necessary after each call to these methods when `null_on_fail == true`. >>>>>>>> This represents a significant number of changes. >>>>>>>> >>>>>>>> Instead, the proposed solution introduces a new _in_retryable_allocation thread-local. This way, only the entry points and allocation routines that raise an exception need to be modified. Failure is communicated back to the new entry points by throwing a special pre-allocated OOME object (i.e., Universe::out_of_memory_error_retry()) which must not propagate back to Java code. Use of this object is not strictly necessary; it is introduced to highlight/document the special allocation mode. >>>>>>>> >>>>>>>> The proposed solution is at http://cr.openjdk.java.net/~dnsimon/8208686. >>>>>>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>>>>>> >>>>>>>> -Doug >>>> >>> From jcbeyler at google.com Fri Oct 5 18:04:33 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 5 Oct 2018 11:04:33 -0700 Subject: RFR (M) 8211131: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[G-I]* In-Reply-To: <7be1b96d-def2-e347-7dcf-a64bfcafc850@oracle.com> References: <0be9bef2-6052-0768-fb9b-57ae43baff7c@oracle.com> <7be1b96d-def2-e347-7dcf-a64bfcafc850@oracle.com> Message-ID: Hi Alex and Serguei, Thanks for the reviews! I will push it through the submit and then push then! Jc Ps: the really long lines, as you said will get fixed in subsequent CLs so it should disappear in the very near future On Tue, Oct 2, 2018 at 10:22 PM wrote: > Hi Jc, > > Looks good to me. > > Thanks, > Serguei > > On 10/2/18 6:51 AM, JC Beyler wrote: > > Hi Alex, > > That is because this webrev was done before I added the 100 character > wrap, which I added when I was generating the next batch of changes. Here > is the webrev with the new version of the script: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 > > Thanks, let me know what you think! > Jc > > On Tue, Oct 2, 2018 at 2:56 AM Alex Menkov > wrote: > >> Hi Jc, >> >> Looking at your conversion script I expected things like >> >> if (!NSK_JVMTI_VERIFY( >> NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { >> >> to be converted to >> >> if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps))) { >> >> (then the final string is shorter than 100 symbols) >> >> But actually I see >> >> if (!NSK_JVMTI_VERIFY( >> - NSK_CPP_STUB2(AddCapabilities, jvmti, &caps))) { >> + jvmti->AddCapabilities(&caps))) { >> >> --alex >> >> On 09/26/2018 20:37, JC Beyler wrote: >> > Hi all, >> > >> > I continued the NSK_CPP_STUB removal with this webrev: >> > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211131/webrev.00/ >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8211131 >> > >> > This does the first 50 files of the jvmti subfolder, it is done >> > automatically by the scripts I put in the bug comments. >> > >> > Let me know what you think, >> > Jc >> > > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Oct 5 19:01:15 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 5 Oct 2018 12:01:15 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> Message-ID: <46c3d40c-c859-8af4-4d82-4955755f8f5d@oracle.com> Hi Jc, On 10/05/2018 10:34, JC Beyler wrote: > Hi Alex, > > One question and a comment on this: > - I thought HashMap was not thread safe so I think you need to > synchronize the access to the map threadData The map is accessed from a single thread (main test thread which sends jdb commands and handles jdb replies), so synchronization is not required. > > - I think your test code could be simplified if you moved it into a > helper method (not tested but just for example): I suppose you don't like do/break/while(false)? To me it's quite standard method to avoid multi-level if/then/else. In your suggestion I don't like that processNewData() method handles minLine/maxLine, but doesn't handle lastLine (i.e. it doesn't do all processing). But if "data.lastLine = lineNum" is moved into the method, we need something like do/break/while(false) in the method. --alex > > +? ? private void next() { > +? ? ? ? List reply = jdb.command(JdbCommand.next()); > +? ? ? ? /* > +? ? ? ? ?* Each "next" produces something like ("Breakpoint hit" line > only if the line has BP) > +? ? ? ? ?*? ?Step completed: > +? ? ? ? ?*? ? ?Breakpoint hit: "thread=jj2", > DeferredStepTestTarg$jj2.run(), line=74 bci=12 > +? ? ? ? ?*? ? ?74? ? ? ? ? ? ? ? ? ? ++count2; > ?// @2 breakpoint > +? ? ? ? ?*? ? ? > +? ? ? ? ?*? ? ?jj2[1] > +? ? ? ? ?*/ > +? ? ? ? // detect thread from the last line > +? ? ? ? String lastLine = reply.get(reply.size() - 1); > +? ? ? ? String threadName = parse(threadRegexp, lastLine); > +? ? ? ? String wholeReply = > reply.stream().collect(Collectors.joining(Utils.NEW_LINE)); > +? ? ? ? int lineNum = Integer.parseInt(parse(lineRegexp, wholeReply)); > + > +? ? ? ? System.out.println("got: thread=" + threadName + ", line=" + > lineNum); > + > +? ? ? ? ThreadData data = threadData.get(threadName); > +? ? ? ? if (data == null) { > +? ? ? ? ? ? data = new ThreadData(); > +? ? ? ? ? ? threadData.put(threadName, data); > +? ? ? ? } > +? ? ? ? processNewData(data, threadName, lineNum); > +? ? ? ? data.lastLine = lineNum; > +? ? } > + > +? private void processNewData(ThreadData data, String threadName, int > lineNum) { > +? ? ? ? if (data.lastLine < 0) { > +? ? ? ? ? ? // the 1st stop in the thread > +? ? ? ? ? ? return; > +? ? ? ? } > + > +? ? ? ? if (lineNum == data.lastLine + 1) { > +? ? ? ? ? ? // expected. > +? ? ? ? ? ? return; > +? ? ? ? } > + > +? ? ? ? if (lineNum < data.lastLine) { > +? ? ? ? ? ? // looks like step to the beginning of the cycle > +? ? ? ? ? ? if (data.minLine > 0) { > +? ? ? ? ? ? ? ?// minLine and maxLine are not set - verify > +? ? ? ? ? ? ? ?Asserts.assertEquals(lineNum, data.minLine, threadName + > " - minLine"); > +? ? ? ? ? ? ? ?Asserts.assertEquals(data.lastLine, data.maxLine, > threadName + " - maxLine"); > +? ? ? ? ? ? } else { > +? ? ? ? ? ? ? ? // set minLine/maxLine > +? ? ? ? ? ? ? ? data.minLine = lineNum; > +? ? ? ? ? ? ? ? data.maxLine = data.lastLine; > +? ? ? ? ? ?} > +? ? ? ? ? ?return; > +? ? ? ? } > + > +? ? ? ? throw new RuntimeException(threadName + " (line " + lineNum + > ") - unexpected." > +? ? ? ? ? ? + " lastLine=" + data.lastLine + ", minLine=" + > data.minLine + ", maxLine=" + data.maxLine); > + } > > Thanks, > Jc > > > > On Thu, Oct 4, 2018 at 6:31 PM > wrote: > > Hi Alex, > > It looks good to me. > Could you, please, also remove the line? : > > ? 156? ? ? ? ? ? ?// > > No need in new webrev. > > Thanks, > Serguei > > > On 10/4/18 4:11 PM, Alex Menkov wrote: > > Hi Serguei, > > > > Updated webrev: > > > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ > > > > > Fixed all issues except > > ?140???????????????? // the 1st stop in the thread > > ?141???????????????? break; > > In this case the comment is an explanation why we reach the > block, not > > an explanation for the "break" statement. > > > > --alex > > > > On 10/04/2018 13:56, serguei.spitsyn at oracle.com > wrote: > >> Hi Alex, > >> > >> Several minor suggestions. > >> > >> 77 new Thread(aRP, "jj1").start(); > >> 78 new Thread(asRP, "jj2").start(); What mean aRP and asRP? In > fact, > >> it is confusing. Can they be renamed to something like obj1 and > obj2. > >> > >> 79 // new Thread(aRP, "jj3").start(); > >> 80 // new Thread(asRP, "jj4").start(); > >> > >> ??These lines can be removed. > >> > >> 94 // line of the last stop > >> 95 int lastLine = -1; > >> 96 // min line (-1 means "not known yet") > >> 97 int minLine = -1; > >> 98 // max line (-1 means "not known yet") > >> 99 int maxLine = -1; ... 140 // the 1st stop in the thread > >> 141 break; > >> > >> ?? I'd suggest the refactor above as below: > >> > >> int lastLine = -1;? // line of the last stop > >> int minLine = -1;? // min line (-1 means "not known yet") > >> int maxLine = -1;// max line (-1 means "not known yet") > >> ? ... > >> break;? // the 1st stop in the thread > >> > >> 116 private void next() { > >> 117 List reply = jdb.command(JdbCommand.next()); > >> 118 /* each "next" produces something like ("Breakpoint hit" line > >> only if the line has BP) > >> 119 Step completed: > >> 120 Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), > >> line=74 bci=12 > >> 121 74 ++count2; // @2 breakpoint > >> 122 > >> 123 jj2[1] > >> 124 */ It would better to have it in this style: 118 /* * Each > "next" > >> produces something like ("Breakpoint hit" line only if the line > has BP). > >> 119 * Step completed: > >> 120 * Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), > >> line=74 bci=12 > >> 121 * 74 ++count2; // @2 breakpoint > >> 122 * > >> 123 * jj2[1] > >> 124 */ > >> > >> > >> Otherwise, it looks Okay to me. > >> > >> > >> Thanks, > >> Serguei > >> > >> On 10/3/18 5:49 PM, Alex Menkov wrote: > >>> Hi all, > >>> > >>> please review a fix for > >>> https://bugs.openjdk.java.net/browse/JDK-8211292 > >>> webrev: > >>> > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ > > >>> > >>> The fix converts manual shell test to automatic java (as Java > allows > >>> to parse jdb replies much easier). > >>> This is the last sub-task for the "shell to java conversion" task, > >>> so the fix also removes shared shell scripts. > >>> > >>> --alex > >> > > > > -- > > Thanks, > Jc From jcbeyler at google.com Fri Oct 5 19:10:50 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 5 Oct 2018 12:10:50 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: <46c3d40c-c859-8af4-4d82-4955755f8f5d@oracle.com> References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> <46c3d40c-c859-8af4-4d82-4955755f8f5d@oracle.com> Message-ID: You're right for the single threaded part; I misread that part and thought it would be multi-threaded as well. And fair enough for the keeping it then as a do..while(false); it just took me a while to figure out what was being done. You could put the data.lastLine in a local variable and update it at the start of the method (only using the local version for the rest of the method); then everything would be in there. But, I'll still say it is a more a question of style :) LGTM, Jc On Fri, Oct 5, 2018 at 12:01 PM Alex Menkov wrote: > Hi Jc, > > > On 10/05/2018 10:34, JC Beyler wrote: > > Hi Alex, > > > > One question and a comment on this: > > - I thought HashMap was not thread safe so I think you need to > > synchronize the access to the map threadData > > The map is accessed from a single thread (main test thread which sends > jdb commands and handles jdb replies), so synchronization is not required. > > > > > - I think your test code could be simplified if you moved it into a > > helper method (not tested but just for example): > > I suppose you don't like do/break/while(false)? > To me it's quite standard method to avoid multi-level if/then/else. > In your suggestion I don't like that processNewData() method handles > minLine/maxLine, but doesn't handle lastLine (i.e. it doesn't do all > processing). But if "data.lastLine = lineNum" is moved into the method, > we need something like do/break/while(false) in the method. > > --alex > > > > > + private void next() { > > + List reply = jdb.command(JdbCommand.next()); > > + /* > > + * Each "next" produces something like ("Breakpoint hit" line > > only if the line has BP) > > + * Step completed: > > + * Breakpoint hit: "thread=jj2", > > DeferredStepTestTarg$jj2.run(), line=74 bci=12 > > + * 74 ++count2; > > // @2 breakpoint > > + * > > + * jj2[1] > > + */ > > + // detect thread from the last line > > + String lastLine = reply.get(reply.size() - 1); > > + String threadName = parse(threadRegexp, lastLine); > > + String wholeReply = > > reply.stream().collect(Collectors.joining(Utils.NEW_LINE)); > > + int lineNum = Integer.parseInt(parse(lineRegexp, wholeReply)); > > + > > + System.out.println("got: thread=" + threadName + ", line=" + > > lineNum); > > + > > + ThreadData data = threadData.get(threadName); > > + if (data == null) { > > + data = new ThreadData(); > > + threadData.put(threadName, data); > > + } > > + processNewData(data, threadName, lineNum); > > + data.lastLine = lineNum; > > + } > > + > > + private void processNewData(ThreadData data, String threadName, int > > lineNum) { > > + if (data.lastLine < 0) { > > + // the 1st stop in the thread > > + return; > > + } > > + > > + if (lineNum == data.lastLine + 1) { > > + // expected. > > + return; > > + } > > + > > + if (lineNum < data.lastLine) { > > + // looks like step to the beginning of the cycle > > + if (data.minLine > 0) { > > + // minLine and maxLine are not set - verify > > + Asserts.assertEquals(lineNum, data.minLine, threadName + > > " - minLine"); > > + Asserts.assertEquals(data.lastLine, data.maxLine, > > threadName + " - maxLine"); > > + } else { > > + // set minLine/maxLine > > + data.minLine = lineNum; > > + data.maxLine = data.lastLine; > > + } > > + return; > > + } > > + > > + throw new RuntimeException(threadName + " (line " + lineNum + > > ") - unexpected." > > + + " lastLine=" + data.lastLine + ", minLine=" + > > data.minLine + ", maxLine=" + data.maxLine); > > + } > > > > Thanks, > > Jc > > > > > > > > On Thu, Oct 4, 2018 at 6:31 PM > > wrote: > > > > Hi Alex, > > > > It looks good to me. > > Could you, please, also remove the line? : > > > > 156 // > > > > No need in new webrev. > > > > Thanks, > > Serguei > > > > > > On 10/4/18 4:11 PM, Alex Menkov wrote: > > > Hi Serguei, > > > > > > Updated webrev: > > > > > > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ > > < > http://cr.openjdk.java.net/%7Eamenkov/sh2java/DeferredStep_final/webrev.02/ > > > > > > > > Fixed all issues except > > > 140 // the 1st stop in the thread > > > 141 break; > > > In this case the comment is an explanation why we reach the > > block, not > > > an explanation for the "break" statement. > > > > > > --alex > > > > > > On 10/04/2018 13:56, serguei.spitsyn at oracle.com > > wrote: > > >> Hi Alex, > > >> > > >> Several minor suggestions. > > >> > > >> 77 new Thread(aRP, "jj1").start(); > > >> 78 new Thread(asRP, "jj2").start(); What mean aRP and asRP? In > > fact, > > >> it is confusing. Can they be renamed to something like obj1 and > > obj2. > > >> > > >> 79 // new Thread(aRP, "jj3").start(); > > >> 80 // new Thread(asRP, "jj4").start(); > > >> > > >> These lines can be removed. > > >> > > >> 94 // line of the last stop > > >> 95 int lastLine = -1; > > >> 96 // min line (-1 means "not known yet") > > >> 97 int minLine = -1; > > >> 98 // max line (-1 means "not known yet") > > >> 99 int maxLine = -1; ... 140 // the 1st stop in the thread > > >> 141 break; > > >> > > >> I'd suggest the refactor above as below: > > >> > > >> int lastLine = -1; // line of the last stop > > >> int minLine = -1; // min line (-1 means "not known yet") > > >> int maxLine = -1;// max line (-1 means "not known yet") > > >> ... > > >> break; // the 1st stop in the thread > > >> > > >> 116 private void next() { > > >> 117 List reply = jdb.command(JdbCommand.next()); > > >> 118 /* each "next" produces something like ("Breakpoint hit" line > > >> only if the line has BP) > > >> 119 Step completed: > > >> 120 Breakpoint hit: "thread=jj2", DeferredStepTestTarg$jj2.run(), > > >> line=74 bci=12 > > >> 121 74 ++count2; // @2 breakpoint > > >> 122 > > >> 123 jj2[1] > > >> 124 */ It would better to have it in this style: 118 /* * Each > > "next" > > >> produces something like ("Breakpoint hit" line only if the line > > has BP). > > >> 119 * Step completed: > > >> 120 * Breakpoint hit: "thread=jj2", > DeferredStepTestTarg$jj2.run(), > > >> line=74 bci=12 > > >> 121 * 74 ++count2; // @2 breakpoint > > >> 122 * > > >> 123 * jj2[1] > > >> 124 */ > > >> > > >> > > >> Otherwise, it looks Okay to me. > > >> > > >> > > >> Thanks, > > >> Serguei > > >> > > >> On 10/3/18 5:49 PM, Alex Menkov wrote: > > >>> Hi all, > > >>> > > >>> please review a fix for > > >>> https://bugs.openjdk.java.net/browse/JDK-8211292 > > >>> webrev: > > >>> > > > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ > > < > http://cr.openjdk.java.net/%7Eamenkov/sh2java/DeferredStep_final/webrev/> > > >>> > > >>> The fix converts manual shell test to automatic java (as Java > > allows > > >>> to parse jdb replies much easier). > > >>> This is the last sub-task for the "shell to java conversion" > task, > > >>> so the fix also removes shared shell scripts. > > >>> > > >>> --alex > > >> > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Oct 5 19:37:29 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 5 Oct 2018 12:37:29 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> <46c3d40c-c859-8af4-4d82-4955755f8f5d@oracle.com> Message-ID: <803be3dc-9ebd-7dbb-8922-dae10f1bf0bf@oracle.com> In general, like the suggestion from Jc with the correction for lastLine to be a local. But leave it up to Alex to decide what is better as changes would require another round of testing. Thanks, Serguei On 10/5/18 12:10 PM, JC Beyler wrote: > You're right for the single threaded part; I misread that part and > thought it would be multi-threaded as well. And fair enough for the > keeping it then as a do..while(false); it just took me a while to > figure out what was being done. You could put the data.lastLine in a > local variable and update it at the start of the method (only using > the local version for the rest of the method); then everything would > be in there. But, I'll still say it is a more a question of style :) > > LGTM, > Jc > > On Fri, Oct 5, 2018 at 12:01 PM Alex Menkov > wrote: > > Hi Jc, > > > On 10/05/2018 10:34, JC Beyler wrote: > > Hi Alex, > > > > One question and a comment on this: > > - I thought HashMap was not thread safe so I think you need to > > synchronize the access to the map threadData > > The map is accessed from a single thread (main test thread which > sends > jdb commands and handles jdb replies), so synchronization is not > required. > > > > > - I think your test code could be simplified if you moved it into a > > helper method (not tested but just for example): > > I suppose you don't like do/break/while(false)? > To me it's quite standard method to avoid multi-level if/then/else. > In your suggestion I don't like that processNewData() method handles > minLine/maxLine, but doesn't handle lastLine (i.e. it doesn't do all > processing). But if "data.lastLine = lineNum" is moved into the > method, > we need something like do/break/while(false) in the method. > > --alex > > > > > +? ? private void next() { > > +? ? ? ? List reply = jdb.command(JdbCommand.next()); > > +? ? ? ? /* > > +? ? ? ? ?* Each "next" produces something like ("Breakpoint > hit" line > > only if the line has BP) > > +? ? ? ? ?*? ?Step completed: > > +? ? ? ? ?*? ? ?Breakpoint hit: "thread=jj2", > > DeferredStepTestTarg$jj2.run(), line=74 bci=12 > > +? ? ? ? ?*? ? ?74? ? ? ? ? ? ? ? ? ? ++count2; > >? ?// @2 breakpoint > > +? ? ? ? ?*? ? ? > > +? ? ? ? ?*? ? ?jj2[1] > > +? ? ? ? ?*/ > > +? ? ? ? // detect thread from the last line > > +? ? ? ? String lastLine = reply.get(reply.size() - 1); > > +? ? ? ? String threadName = parse(threadRegexp, lastLine); > > +? ? ? ? String wholeReply = > > reply.stream().collect(Collectors.joining(Utils.NEW_LINE)); > > +? ? ? ? int lineNum = Integer.parseInt(parse(lineRegexp, > wholeReply)); > > + > > +? ? ? ? System.out.println("got: thread=" + threadName + ", > line=" + > > lineNum); > > + > > +? ? ? ? ThreadData data = threadData.get(threadName); > > +? ? ? ? if (data == null) { > > +? ? ? ? ? ? data = new ThreadData(); > > +? ? ? ? ? ? threadData.put(threadName, data); > > +? ? ? ? } > > +? ? ? ? processNewData(data, threadName, lineNum); > > +? ? ? ? data.lastLine = lineNum; > > +? ? } > > + > > +? private void processNewData(ThreadData data, String > threadName, int > > lineNum) { > > +? ? ? ? if (data.lastLine < 0) { > > +? ? ? ? ? ? // the 1st stop in the thread > > +? ? ? ? ? ? return; > > +? ? ? ? } > > + > > +? ? ? ? if (lineNum == data.lastLine + 1) { > > +? ? ? ? ? ? // expected. > > +? ? ? ? ? ? return; > > +? ? ? ? } > > + > > +? ? ? ? if (lineNum < data.lastLine) { > > +? ? ? ? ? ? // looks like step to the beginning of the cycle > > +? ? ? ? ? ? if (data.minLine > 0) { > > +? ? ? ? ? ? ? ?// minLine and maxLine are not set - verify > > +? ? ? ? ? ? ? ?Asserts.assertEquals(lineNum, data.minLine, > threadName + > > " - minLine"); > > +? ? ? ? ? ? ? ?Asserts.assertEquals(data.lastLine, data.maxLine, > > threadName + " - maxLine"); > > +? ? ? ? ? ? } else { > > +? ? ? ? ? ? ? ? // set minLine/maxLine > > +? ? ? ? ? ? ? ? data.minLine = lineNum; > > +? ? ? ? ? ? ? ? data.maxLine = data.lastLine; > > +? ? ? ? ? ?} > > +? ? ? ? ? ?return; > > +? ? ? ? } > > + > > +? ? ? ? throw new RuntimeException(threadName + " (line " + > lineNum + > > ") - unexpected." > > +? ? ? ? ? ? + " lastLine=" + data.lastLine + ", minLine=" + > > data.minLine + ", maxLine=" + data.maxLine); > > + } > > > > Thanks, > > Jc > > > > > > > > On Thu, Oct 4, 2018 at 6:31 PM > > >> wrote: > > > >? ? ?Hi Alex, > > > >? ? ?It looks good to me. > >? ? ?Could you, please, also remove the line? : > > > >? ? ? ? 156? ? ? ? ? ? ?// > > > >? ? ?No need in new webrev. > > > >? ? ?Thanks, > >? ? ?Serguei > > > > > >? ? ?On 10/4/18 4:11 PM, Alex Menkov wrote: > >? ? ? > Hi Serguei, > >? ? ? > > >? ? ? > Updated webrev: > >? ? ? > > > > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ > > >? ? > ? > >? ? ? > > >? ? ? > Fixed all issues except > >? ? ? > ?140???????????????? // the 1st stop in the thread > >? ? ? > ?141???????????????? break; > >? ? ? > In this case the comment is an explanation why we reach the > >? ? ?block, not > >? ? ? > an explanation for the "break" statement. > >? ? ? > > >? ? ? > --alex > >? ? ? > > >? ? ? > On 10/04/2018 13:56, serguei.spitsyn at oracle.com > > >? ? ? > wrote: > >? ? ? >> Hi Alex, > >? ? ? >> > >? ? ? >> Several minor suggestions. > >? ? ? >> > >? ? ? >> 77 new Thread(aRP, "jj1").start(); > >? ? ? >> 78 new Thread(asRP, "jj2").start(); What mean aRP and > asRP? In > >? ? ?fact, > >? ? ? >> it is confusing. Can they be renamed to something like > obj1 and > >? ? ?obj2. > >? ? ? >> > >? ? ? >> 79 // new Thread(aRP, "jj3").start(); > >? ? ? >> 80 // new Thread(asRP, "jj4").start(); > >? ? ? >> > >? ? ? >> ??These lines can be removed. > >? ? ? >> > >? ? ? >> 94 // line of the last stop > >? ? ? >> 95 int lastLine = -1; > >? ? ? >> 96 // min line (-1 means "not known yet") > >? ? ? >> 97 int minLine = -1; > >? ? ? >> 98 // max line (-1 means "not known yet") > >? ? ? >> 99 int maxLine = -1; ... 140 // the 1st stop in the thread > >? ? ? >> 141 break; > >? ? ? >> > >? ? ? >> ?? I'd suggest the refactor above as below: > >? ? ? >> > >? ? ? >> int lastLine = -1;? // line of the last stop > >? ? ? >> int minLine = -1;? // min line (-1 means "not known yet") > >? ? ? >> int maxLine = -1;// max line (-1 means "not known yet") > >? ? ? >> ? ... > >? ? ? >> break;? // the 1st stop in the thread > >? ? ? >> > >? ? ? >> 116 private void next() { > >? ? ? >> 117 List reply = jdb.command(JdbCommand.next()); > >? ? ? >> 118 /* each "next" produces something like ("Breakpoint > hit" line > >? ? ? >> only if the line has BP) > >? ? ? >> 119 Step completed: > >? ? ? >> 120 Breakpoint hit: "thread=jj2", > DeferredStepTestTarg$jj2.run(), > >? ? ? >> line=74 bci=12 > >? ? ? >> 121 74 ++count2; // @2 breakpoint > >? ? ? >> 122 > >? ? ? >> 123 jj2[1] > >? ? ? >> 124 */ It would better to have it in this style: 118 /* > * Each > >? ? ?"next" > >? ? ? >> produces something like ("Breakpoint hit" line only if > the line > >? ? ?has BP). > >? ? ? >> 119 * Step completed: > >? ? ? >> 120 * Breakpoint hit: "thread=jj2", > DeferredStepTestTarg$jj2.run(), > >? ? ? >> line=74 bci=12 > >? ? ? >> 121 * 74 ++count2; // @2 breakpoint > >? ? ? >> 122 * > >? ? ? >> 123 * jj2[1] > >? ? ? >> 124 */ > >? ? ? >> > >? ? ? >> > >? ? ? >> Otherwise, it looks Okay to me. > >? ? ? >> > >? ? ? >> > >? ? ? >> Thanks, > >? ? ? >> Serguei > >? ? ? >> > >? ? ? >> On 10/3/18 5:49 PM, Alex Menkov wrote: > >? ? ? >>> Hi all, > >? ? ? >>> > >? ? ? >>> please review a fix for > >? ? ? >>> https://bugs.openjdk.java.net/browse/JDK-8211292 > >? ? ? >>> webrev: > >? ? ? >>> > > > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ > > >? ? > ? > >? ? ? >>> > >? ? ? >>> The fix converts manual shell test to automatic java > (as Java > >? ? ?allows > >? ? ? >>> to parse jdb replies much easier). > >? ? ? >>> This is the last sub-task for the "shell to java > conversion" task, > >? ? ? >>> so the fix also removes shared shell scripts. > >? ? ? >>> > >? ? ? >>> --alex > >? ? ? >> > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Oct 5 19:56:12 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 5 Oct 2018 12:56:12 -0700 Subject: RFR: 8208686: [AOT] JVMTI ResourceExhausted event repeated for same allocation In-Reply-To: <407cc96c-c846-83f8-a924-9df6705a031f@oracle.com> References: <910A4A3C-3EEF-4167-84D5-9819C83D6FC1@oracle.com> <64cbe730-5c9a-a04d-9eee-a56abfbb8e07@oracle.com> <015e8416-a948-fdc5-46db-8b5d80ba52e8@oracle.com> <5F46B759-4AF0-4EA2-B2B8-F076DD350F5A@oracle.com> <7FD94ACE-4CF4-488C-9A2B-C440429B915A@oracle.com> <407cc96c-c846-83f8-a924-9df6705a031f@oracle.com> Message-ID: +1 Thanks, Serguei On 10/5/18 9:05 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/5/18 8:22 AM, Doug Simon wrote: >> Hi, >> >> Testing found a bug in the original webrev. Namely, when clearing out >> a pending exception and returning null in the JVMCI ..._or_null >> stubs, the JavaThread::_vm_result field was not being set to NULL. >> I've addressed this in v2 of the webrev: >> >> Relative diff for bug fix: >> >> ----------------------------------------------------------------------------------------------- >> >> -// Manages a scope in which a failed heap allocation will throw an >> exception. >> -// The pending exception is cleared when leaving the scope. >> +// Manages a scope for a JVMCI runtime call that attempts a heap >> allocation. >> +// If there is a pending exception upon closing the scope and the >> runtime >> +// call is of the variety where allocation failure returns NULL >> without an >> +// exception, the following action is taken: >> +//?? 1. The pending exception is cleared >> +//?? 2. NULL is written to JavaThread::_vm_result >> +//?? 3. Checks that an OutOfMemoryError is >> Universe::out_of_memory_error_retry(). >> ? class RetryableAllocationMark: public StackObj { >> ?? private: >> ??? JavaThread* _thread; >> ?? public: >> ??? RetryableAllocationMark(JavaThread* thread, bool activate) { >> ????? if (activate) { >> -????? assert(thread->in_retryable_allocation(), "retryable >> allocation scope is non-reentrant"); >> +????? assert(!thread->in_retryable_allocation(), "retryable >> allocation scope is non-reentrant"); >> ??????? _thread = thread; >> ??????? _thread->set_in_retryable_allocation(true); >> ????? } else { >> @@ -136,6 +141,7 @@ >> ??????????? ResourceMark rm; >> ??????????? fatal("Unexpected exception in scope of retryable >> allocation: " INTPTR_FORMAT " of type %s", p2i(ex), >> ex->klass()->external_name()); >> ????????? } >> +??????? _thread->set_vm_result(NULL); >> ??????? } >> ????? } >> ??? } >> ----------------------------------------------------------------------------------------------- >> >> >> I also took the opportunity to factor out negative array length >> checking: >> >> ----------------------------------------------------------------------------------------------- >> >> diff -r 4d36f5998a8b src/hotspot/share/oops/arrayKlass.cpp >> --- a/src/hotspot/share/oops/arrayKlass.cpp??? Fri Oct 05 17:04:06 >> 2018 +0200 >> +++ b/src/hotspot/share/oops/arrayKlass.cpp??? Fri Oct 05 17:17:17 >> 2018 +0200 >> @@ -130,9 +130,6 @@ >> ? } >> ? ? objArrayOop ArrayKlass::allocate_arrayArray(int n, int length, >> TRAPS) { >> -? if (length < 0) { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), >> err_msg("%d", length)); >> -? } >> ??? check_array_allocation_length(length, >> arrayOopDesc::max_array_length(T_ARRAY), CHECK_0); >> ??? int size = objArrayOopDesc::object_size(length); >> ??? Klass* k = array_klass(n+dimension(), CHECK_0); >> diff -r 4d36f5998a8b src/hotspot/share/oops/instanceKlass.cpp >> --- a/src/hotspot/share/oops/instanceKlass.cpp??? Fri Oct 05 17:04:06 >> 2018 +0200 >> +++ b/src/hotspot/share/oops/instanceKlass.cpp??? Fri Oct 05 17:17:17 >> 2018 +0200 >> @@ -1201,9 +1201,6 @@ >> ? } >> ? ? objArrayOop InstanceKlass::allocate_objArray(int n, int length, >> TRAPS) { >> -? if (length < 0)? { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), >> err_msg("%d", length)); >> -? } >> ??? check_array_allocation_length(length, >> arrayOopDesc::max_array_length(T_OBJECT), CHECK_NULL); >> ??? int size = objArrayOopDesc::object_size(length); >> ??? Klass* ak = array_klass(n, CHECK_NULL); >> diff -r 4d36f5998a8b src/hotspot/share/oops/klass.cpp >> --- a/src/hotspot/share/oops/klass.cpp??? Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/klass.cpp??? Fri Oct 05 17:17:17 2018 +0200 >> @@ -620,6 +620,8 @@ >> ????? } else { >> ??????? THROW_OOP(Universe::out_of_memory_error_retry()); >> ????? } >> +? } else if (length < 0) { >> + THROW_MSG(vmSymbols::java_lang_NegativeArraySizeException(), >> err_msg("%d", length)); >> ??? } >> ? } >> ? diff -r 4d36f5998a8b src/hotspot/share/oops/klass.hpp >> --- a/src/hotspot/share/oops/klass.hpp??? Fri Oct 05 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/klass.hpp??? Fri Oct 05 17:17:17 2018 +0200 >> @@ -514,7 +514,7 @@ >> ??? virtual Klass* array_klass_impl(bool or_null, int rank, TRAPS); >> ??? virtual Klass* array_klass_impl(bool or_null, TRAPS); >> ? -? // Error handling when length > max_length >> +? // Error handling when length > max_length or length < 0 >> ??? static void check_array_allocation_length(int length, int >> max_length, TRAPS); >> ? ??? void set_vtable_length(int len) { _vtable_len= len; } >> diff -r 4d36f5998a8b src/hotspot/share/oops/objArrayKlass.cpp >> --- a/src/hotspot/share/oops/objArrayKlass.cpp??? Fri Oct 05 17:04:06 >> 2018 +0200 >> +++ b/src/hotspot/share/oops/objArrayKlass.cpp??? Fri Oct 05 17:17:17 >> 2018 +0200 >> @@ -170,14 +170,10 @@ >> ? } >> ? ? objArrayOop ObjArrayKlass::allocate(int length, TRAPS) { >> -? if (length >= 0) { >> -??? check_array_allocation_length(length, >> arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); >> -??? int size = objArrayOopDesc::object_size(length); >> -??? return (objArrayOop)Universe::heap()->array_allocate(this, size, >> length, >> -???????????????????????????????????????????????????????? /* do_zero >> */ true, THREAD); >> -? } else { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), >> err_msg("%d", length)); >> -? } >> +? check_array_allocation_length(length, >> arrayOopDesc::max_array_length(T_OBJECT), CHECK_0); >> +? int size = objArrayOopDesc::object_size(length); >> +? return (objArrayOop)Universe::heap()->array_allocate(this, size, >> length, >> +?????????????????????????????????????????????????????? /* do_zero */ >> true, THREAD); >> ? } >> ? ? static int multi_alloc_counter = 0; >> diff -r 4d36f5998a8b src/hotspot/share/oops/typeArrayKlass.cpp >> --- a/src/hotspot/share/oops/typeArrayKlass.cpp??? Fri Oct 05 >> 17:04:06 2018 +0200 >> +++ b/src/hotspot/share/oops/typeArrayKlass.cpp??? Fri Oct 05 >> 17:17:17 2018 +0200 >> @@ -99,14 +99,10 @@ >> ? ? typeArrayOop TypeArrayKlass::allocate_common(int length, bool >> do_zero, TRAPS) { >> ??? assert(log2_element_size() >= 0, "bad scale"); >> -? if (length >= 0) { >> -??? check_array_allocation_length(length, max_length(), CHECK_NULL); >> -??? size_t size = typeArrayOopDesc::object_size(layout_helper(), >> length); >> -??? return (typeArrayOop)Universe::heap()->array_allocate(this, >> (int)size, length, >> - do_zero, CHECK_NULL); >> -? } else { >> - THROW_MSG_0(vmSymbols::java_lang_NegativeArraySizeException(), >> err_msg("%d", length)); >> -? } >> +? check_array_allocation_length(length, max_length(), CHECK_NULL); >> +? size_t size = typeArrayOopDesc::object_size(layout_helper(), length); >> +? return (typeArrayOop)Universe::heap()->array_allocate(this, >> (int)size, length, >> + do_zero, CHECK_NULL); >> ? } >> ? ? oop TypeArrayKlass::multi_allocate(int rank, jint* last_size, >> TRAPS) { >> ----------------------------------------------------------------------------------------------- >> >> >> Please confirm review these new changes: >> >> http://cr.openjdk.java.net/~dnsimon/8208686v2 >> >> -Doug >> >> >>> On 4 Oct 2018, at 00:20, Doug Simon wrote: >>> >>> Thanks for the reviews Serguei and Vladimir. >>> >>> Unless I hear objections in the next 24 hours, I'll push this webrev. >>> >>> -Doug >>> >>>> On 3 Oct 2018, at 03:14, serguei.spitsyn at oracle.com wrote: >>>> >>>> Hi Doug, >>>> >>>> The JVMTI related part looks good to me. >>>> Thank you for fixing it! >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/2/18 1:11 AM, Doug Simon wrote: >>>>> It would be great to get some input from the non-compilers teams >>>>> on this RFR. >>>>> >>>>> -Doug >>>>> >>>>>> On 28 Sep 2018, at 19:51, Vladimir Kozlov >>>>>> wrote: >>>>>> >>>>>> To let you know, me and Tom R. did review these changes and >>>>>> agreed that it is the least intrusive changes for Hotspot shared >>>>>> code. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 9/25/18 8:11 AM, Daniel D. Daugherty wrote: >>>>>>> Adding serviceability-dev at ... since this is JVM/TI... >>>>>>> Dan >>>>>>> On 9/25/18 10:48 AM, Doug Simon wrote: >>>>>>>> A major design point of Graal is to treat allocations as >>>>>>>> non-side effecting to give more freedom to the optimizer by >>>>>>>> reducing the number of distinct FrameStates that need to be >>>>>>>> managed. When failing an allocation, Graal will deoptimize to >>>>>>>> the last side effecting instruction before the allocation. This >>>>>>>> mean the VM code for heap allocation will potentially be >>>>>>>> executed twice, once from Graal compiled code and then again in >>>>>>>> the interpreter. While this is perfectly fine according to the >>>>>>>> JVM specification, it can cause confusing behavior for JVMTI >>>>>>>> based tools. They will receive 2 ResourceExhausted events for a >>>>>>>> single allocation. Furthermore, the first ResourceExhausted >>>>>>>> event (on the Graal allocation slow path) might denote a >>>>>>>> bytecode instruction that performs no allocation, making it >>>>>>>> hard to debug the memory failure. >>>>>>>> >>>>>>>> The proposed solution is to add an extra set of JVMCI VM >>>>>>>> runtime calls for allocation. These entry points will attempt >>>>>>>> the allocation and upon failure, >>>>>>>> skip side-effects such as posting JVMTI events or handling >>>>>>>> -XX:OnOutOfMemoryError. The compiled code using these entry >>>>>>>> points is expected deoptmize on null. >>>>>>>> >>>>>>>> The path from these new entry points to where allocation can >>>>>>>> fail goes through quite a bit of VM code. One could modify all >>>>>>>> these paths by: >>>>>>>> * Returning null instead of throwing an exception on failure. >>>>>>>> * Adding a `bool null_on_fail` argument to all relevant methods. >>>>>>>> * Adding extra null checking where necessary after each call to >>>>>>>> these methods when `null_on_fail == true`. >>>>>>>> This represents a significant number of changes. >>>>>>>> >>>>>>>> Instead, the proposed solution introduces a new >>>>>>>> _in_retryable_allocation thread-local. This way, only the entry >>>>>>>> points and allocation routines that raise an exception need to >>>>>>>> be modified. Failure is communicated back to the new entry >>>>>>>> points by throwing a special pre-allocated OOME object (i.e., >>>>>>>> Universe::out_of_memory_error_retry()) which must not propagate >>>>>>>> back to Java code. Use of this object is not strictly >>>>>>>> necessary; it is introduced to highlight/document the special >>>>>>>> allocation mode. >>>>>>>> >>>>>>>> The proposed solution is at >>>>>>>> http://cr.openjdk.java.net/~dnsimon/8208686. >>>>>>>> THE JBS bug is: https://bugs.openjdk.java.net/browse/JDK-8208686 >>>>>>>> >>>>>>>> -Doug >>>> >>> >> From jcbeyler at google.com Fri Oct 5 22:00:54 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 5 Oct 2018 15:00:54 -0700 Subject: RFR (L) 8211782: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[I-S]* Message-ID: Hi all, I continued the NSK_CPP_STUB removal with this webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211782/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211782 This does another 50 file batch. I added the steps and scripts in this bug as well so that you can see what was done. Some extra long lines happen and I'm working on seeing if I can detect that ahead of time but it might remain a manual step every time. I've tested the modified changes on my machine, all modified tests pass. Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 5 23:02:43 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 5 Oct 2018 16:02:43 -0700 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* In-Reply-To: References: <2521fc07-1ce2-dd35-1e6e-a5fbfe786888@oracle.com> Message-ID: Just for completeness: @Chris, I created https://bugs.openjdk.java.net/browse/JDK-8211802 for the first case you were talking about, which is slightly different than assignments and perhaps we will do them together or not, we can see when I finish the macro replacements. Thanks! Jc On Mon, Oct 1, 2018 at 11:59 AM Chris Plummer wrote: > On 10/1/18 9:50 AM, JC Beyler wrote: > > Hi Chris, > > Thanks for the review! > > I think most of your comments are/should be future items, I inlined my > answers: > > On Fri, Sep 28, 2018 at 7:49 PM Chris Plummer > wrote: > >> Hi JC, >> >> In addition to Alex's ForceEarlyReturn001.cpp comment: >> >> There are many places where I see a space between two parens at the end >> of the line. For example, in attach020Agent00.cpp: >> >> 168 if (!NSK_JVMTI_VERIFY(jvmti->AddCapabilities(&caps)) ) { >> >> > I saw that too, that will disappear when I remove the NSK_JVMTI_VERIFY > altogether. These spaces were there before so I did not > want to try to fix them in this fix-up round since anyway we were going to > touch these lines again anyway. > > I looked and there are a lot of these across the vmTestbase folders. > > I created this bug to track it: > https://bugs.openjdk.java.net/browse/JDK-8211335 > (To be honest, every time I look a bit at the lines fixed right now, I see > things around I'm itching to fix next but I strive to keep the > transformation simple). > > >> Every place NSK_JNI_VERIFY is used there is ugliness with "if" >> expressions involving JNI results that are not already boolean. Besides >> a boolean being computed for the JNI result, often there is also an >> assignment to the JNI result. I'm not sure if you have plans to clean >> stuff like this up, but it would be best to always do the assignment >> first, even if currently there is no local variable being assigned to. >> It would simplify the boolean expression being passed to NSK_JNI_VERIFY. >> Here's one example: >> >> 137 if (!NSK_JNI_VERIFY(jni, (array = (jbyteArray) >> 138 jni->GetStaticObjectField(cls, fieldID)) != NULL)) { >> >> This would be much better: >> >> 137 array = (jbyteArray)jni->GetStaticObjectField(cls, fieldID); >> 138 if (!NSK_JNI_VERIFY(jni, array != NULL) { >> >> > I already have this on my future plate: > https://bugs.openjdk.java.net/browse/JDK-8210922 > > Ok, but sometimes it's just a comparison of the result, but no assignment. > You end up with the method call and args starting on one line, and the last > args and closing paren on the next, followed by a compare op. Would be nice > to instead create a local to assign the result to. > > > attach015Target.cpp: use of ?: is not needed and it should be explicitly >> checking if FindClass is NULL. >> >> 40 return jni->FindClass(LOADED_CLASS_NAME) ? JNI_TRUE : JNI_FALSE; >> >> > For this, I saw a conversation in hotspot ( > http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-August/033828.html) > saying we have to be careful here. I think returning != 0 will work, right? > If so, I'll create a bug to fix all of these up. > > Yes, that is what i was suggesting, except compare to NULL, no 0. > > > >> attach022Agent00.cpp: The empty line 88 and 141 should be removed. Also >> extra space near the end of the line: >> > > Done for the lines and the white space at the end of the line. > > ok. > > > > Basically, my ordering of refactoring would be if the reviewers agree: > - Remove the NSK_CPP_STUB* (which is what these refactoring to do) > - Remove the NSK_*_VERIFY macros at which point I'll remove that space > you saw for NSK_*_VERIFY lines; that will remove the ) in the lines > - Move out the assignments > - Remove the remaining spaces before a ) for l > > Let me know what you think, > > > Looks good. > > Chris > > Jc > > >> thanks, >> >> Chris >> >> On 9/27/18 10:15 PM, JC Beyler wrote: >> > Hi all, >> > >> > I continued the NSK_CPP_STUB removal with this webrev: >> > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211261/webrev.00/ >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8211261 >> > >> > This does the another set of 50 files of the jvmti subfolder, it is >> > done automatically by the scripts I put in the bug comments. >> > >> > This passes the tests changed on my dev machine. >> > >> > Let me know what you think, >> > Jc >> >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Oct 5 23:06:19 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 5 Oct 2018 16:06:19 -0700 Subject: RFR (M) 8211261: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[A-G]* In-Reply-To: References: <2521fc07-1ce2-dd35-1e6e-a5fbfe786888@oracle.com> Message-ID: <30601a1b-d025-7abc-a6a4-6ecff01a2999@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 5 23:50:05 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 5 Oct 2018 16:50:05 -0700 Subject: RFR (XL) 8211801: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[A-E] Message-ID: Hi all, I continued the NSK_CPP_STUB removal with this next webrev. My apologies, this one is big for 50 files; I can further cut it up if we prefer. It is straight-forward though, since it is just doing the same NSK_CPP_STUB removal. Without further ado: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211801/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211801 This does another 50 file batch. I did the same for https://bugs.openjdk.java.net/browse/JDK-8211782 so the scripts can be found there (and added a comment in this bug to link to that). I've tested the modified changes on my machine, all modified tests pass. Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Oct 5 23:53:11 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 5 Oct 2018 16:53:11 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: <803be3dc-9ebd-7dbb-8922-dae10f1bf0bf@oracle.com> References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> <46c3d40c-c859-8af4-4d82-4955755f8f5d@oracle.com> <803be3dc-9ebd-7dbb-8922-dae10f1bf0bf@oracle.com> Message-ID: ok, this is updated webrev: http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.03/ --alex On 10/05/2018 12:37, serguei.spitsyn at oracle.com wrote: > In general, like the suggestion from Jc with the correction for lastLine > to be a local. > But leave it up to Alex to decide what is better as changes would > require another round of testing. > > Thanks, > Serguei > > On 10/5/18 12:10 PM, JC Beyler wrote: >> You're right for the single threaded part; I misread that part and >> thought it would be multi-threaded as well. And fair enough for the >> keeping it then as a do..while(false); it just took me a while to >> figure out what was being done. You could put the data.lastLine in a >> local variable and update it at the start of the method (only using >> the local version for the rest of the method); then everything would >> be in there. But, I'll still say it is a more a question of style :) >> >> LGTM, >> Jc >> >> On Fri, Oct 5, 2018 at 12:01 PM Alex Menkov > > wrote: >> >> Hi Jc, >> >> >> On 10/05/2018 10:34, JC Beyler wrote: >> > Hi Alex, >> > >> > One question and a comment on this: >> > - I thought HashMap was not thread safe so I think you need to >> > synchronize the access to the map threadData >> >> The map is accessed from a single thread (main test thread which >> sends >> jdb commands and handles jdb replies), so synchronization is not >> required. >> >> > >> > - I think your test code could be simplified if you moved it into a >> > helper method (not tested but just for example): >> >> I suppose you don't like do/break/while(false)? >> To me it's quite standard method to avoid multi-level if/then/else. >> In your suggestion I don't like that processNewData() method handles >> minLine/maxLine, but doesn't handle lastLine (i.e. it doesn't do all >> processing). But if "data.lastLine = lineNum" is moved into the >> method, >> we need something like do/break/while(false) in the method. >> >> --alex >> >> > >> > +? ? private void next() { >> > +? ? ? ? List reply = jdb.command(JdbCommand.next()); >> > +? ? ? ? /* >> > +? ? ? ? ?* Each "next" produces something like ("Breakpoint >> hit" line >> > only if the line has BP) >> > +? ? ? ? ?*? ?Step completed: >> > +? ? ? ? ?*? ? ?Breakpoint hit: "thread=jj2", >> > DeferredStepTestTarg$jj2.run(), line=74 bci=12 >> > +? ? ? ? ?*? ? ?74? ? ? ? ? ? ? ? ? ? ++count2; >> >? ?// @2 breakpoint >> > +? ? ? ? ?*? ? ? >> > +? ? ? ? ?*? ? ?jj2[1] >> > +? ? ? ? ?*/ >> > +? ? ? ? // detect thread from the last line >> > +? ? ? ? String lastLine = reply.get(reply.size() - 1); >> > +? ? ? ? String threadName = parse(threadRegexp, lastLine); >> > +? ? ? ? String wholeReply = >> > reply.stream().collect(Collectors.joining(Utils.NEW_LINE)); >> > +? ? ? ? int lineNum = Integer.parseInt(parse(lineRegexp, >> wholeReply)); >> > + >> > +? ? ? ? System.out.println("got: thread=" + threadName + ", >> line=" + >> > lineNum); >> > + >> > +? ? ? ? ThreadData data = threadData.get(threadName); >> > +? ? ? ? if (data == null) { >> > +? ? ? ? ? ? data = new ThreadData(); >> > +? ? ? ? ? ? threadData.put(threadName, data); >> > +? ? ? ? } >> > +? ? ? ? processNewData(data, threadName, lineNum); >> > +? ? ? ? data.lastLine = lineNum; >> > +? ? } >> > + >> > +? private void processNewData(ThreadData data, String >> threadName, int >> > lineNum) { >> > +? ? ? ? if (data.lastLine < 0) { >> > +? ? ? ? ? ? // the 1st stop in the thread >> > +? ? ? ? ? ? return; >> > +? ? ? ? } >> > + >> > +? ? ? ? if (lineNum == data.lastLine + 1) { >> > +? ? ? ? ? ? // expected. >> > +? ? ? ? ? ? return; >> > +? ? ? ? } >> > + >> > +? ? ? ? if (lineNum < data.lastLine) { >> > +? ? ? ? ? ? // looks like step to the beginning of the cycle >> > +? ? ? ? ? ? if (data.minLine > 0) { >> > +? ? ? ? ? ? ? ?// minLine and maxLine are not set - verify >> > +? ? ? ? ? ? ? ?Asserts.assertEquals(lineNum, data.minLine, >> threadName + >> > " - minLine"); >> > +? ? ? ? ? ? ? ?Asserts.assertEquals(data.lastLine, data.maxLine, >> > threadName + " - maxLine"); >> > +? ? ? ? ? ? } else { >> > +? ? ? ? ? ? ? ? // set minLine/maxLine >> > +? ? ? ? ? ? ? ? data.minLine = lineNum; >> > +? ? ? ? ? ? ? ? data.maxLine = data.lastLine; >> > +? ? ? ? ? ?} >> > +? ? ? ? ? ?return; >> > +? ? ? ? } >> > + >> > +? ? ? ? throw new RuntimeException(threadName + " (line " + >> lineNum + >> > ") - unexpected." >> > +? ? ? ? ? ? + " lastLine=" + data.lastLine + ", minLine=" + >> > data.minLine + ", maxLine=" + data.maxLine); >> > + } >> > >> > Thanks, >> > Jc >> > >> > >> > >> > On Thu, Oct 4, 2018 at 6:31 PM > >> > > >> wrote: >> > >> >? ? ?Hi Alex, >> > >> >? ? ?It looks good to me. >> >? ? ?Could you, please, also remove the line? : >> > >> >? ? ? ? 156? ? ? ? ? ? ?// >> > >> >? ? ?No need in new webrev. >> > >> >? ? ?Thanks, >> >? ? ?Serguei >> > >> > >> >? ? ?On 10/4/18 4:11 PM, Alex Menkov wrote: >> >? ? ? > Hi Serguei, >> >? ? ? > >> >? ? ? > Updated webrev: >> >? ? ? > >> > >> http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ >> >> > >> ? >> >? ? ? > >> >? ? ? > Fixed all issues except >> >? ? ? > ?140???????????????? // the 1st stop in the thread >> >? ? ? > ?141???????????????? break; >> >? ? ? > In this case the comment is an explanation why we reach the >> >? ? ?block, not >> >? ? ? > an explanation for the "break" statement. >> >? ? ? > >> >? ? ? > --alex >> >? ? ? > >> >? ? ? > On 10/04/2018 13:56, serguei.spitsyn at oracle.com >> >> >? ? ?> > wrote: >> >? ? ? >> Hi Alex, >> >? ? ? >> >> >? ? ? >> Several minor suggestions. >> >? ? ? >> >> >? ? ? >> 77 new Thread(aRP, "jj1").start(); >> >? ? ? >> 78 new Thread(asRP, "jj2").start(); What mean aRP and >> asRP? In >> >? ? ?fact, >> >? ? ? >> it is confusing. Can they be renamed to something like >> obj1 and >> >? ? ?obj2. >> >? ? ? >> >> >? ? ? >> 79 // new Thread(aRP, "jj3").start(); >> >? ? ? >> 80 // new Thread(asRP, "jj4").start(); >> >? ? ? >> >> >? ? ? >> ??These lines can be removed. >> >? ? ? >> >> >? ? ? >> 94 // line of the last stop >> >? ? ? >> 95 int lastLine = -1; >> >? ? ? >> 96 // min line (-1 means "not known yet") >> >? ? ? >> 97 int minLine = -1; >> >? ? ? >> 98 // max line (-1 means "not known yet") >> >? ? ? >> 99 int maxLine = -1; ... 140 // the 1st stop in the thread >> >? ? ? >> 141 break; >> >? ? ? >> >> >? ? ? >> ?? I'd suggest the refactor above as below: >> >? ? ? >> >> >? ? ? >> int lastLine = -1;? // line of the last stop >> >? ? ? >> int minLine = -1;? // min line (-1 means "not known yet") >> >? ? ? >> int maxLine = -1;// max line (-1 means "not known yet") >> >? ? ? >> ? ... >> >? ? ? >> break;? // the 1st stop in the thread >> >? ? ? >> >> >? ? ? >> 116 private void next() { >> >? ? ? >> 117 List reply = jdb.command(JdbCommand.next()); >> >? ? ? >> 118 /* each "next" produces something like ("Breakpoint >> hit" line >> >? ? ? >> only if the line has BP) >> >? ? ? >> 119 Step completed: >> >? ? ? >> 120 Breakpoint hit: "thread=jj2", >> DeferredStepTestTarg$jj2.run(), >> >? ? ? >> line=74 bci=12 >> >? ? ? >> 121 74 ++count2; // @2 breakpoint >> >? ? ? >> 122 >> >? ? ? >> 123 jj2[1] >> >? ? ? >> 124 */ It would better to have it in this style: 118 /* >> * Each >> >? ? ?"next" >> >? ? ? >> produces something like ("Breakpoint hit" line only if >> the line >> >? ? ?has BP). >> >? ? ? >> 119 * Step completed: >> >? ? ? >> 120 * Breakpoint hit: "thread=jj2", >> DeferredStepTestTarg$jj2.run(), >> >? ? ? >> line=74 bci=12 >> >? ? ? >> 121 * 74 ++count2; // @2 breakpoint >> >? ? ? >> 122 * >> >? ? ? >> 123 * jj2[1] >> >? ? ? >> 124 */ >> >? ? ? >> >> >? ? ? >> >> >? ? ? >> Otherwise, it looks Okay to me. >> >? ? ? >> >> >? ? ? >> >> >? ? ? >> Thanks, >> >? ? ? >> Serguei >> >? ? ? >> >> >? ? ? >> On 10/3/18 5:49 PM, Alex Menkov wrote: >> >? ? ? >>> Hi all, >> >? ? ? >>> >> >? ? ? >>> please review a fix for >> >? ? ? >>> https://bugs.openjdk.java.net/browse/JDK-8211292 >> >? ? ? >>> webrev: >> >? ? ? >>> >> > >> http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ >> >> > >> ? >> >? ? ? >>> >> >? ? ? >>> The fix converts manual shell test to automatic java >> (as Java >> >? ? ?allows >> >? ? ? >>> to parse jdb replies much easier). >> >? ? ? >>> This is the last sub-task for the "shell to java >> conversion" task, >> >? ? ? >>> so the fix also removes shared shell scripts. >> >? ? ? >>> >> >? ? ? >>> --alex >> >? ? ? >> >> > >> > >> > >> > -- >> > >> > Thanks, >> > Jc >> >> >> >> -- >> >> Thanks, >> Jc > From serguei.spitsyn at oracle.com Sat Oct 6 00:00:21 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 5 Oct 2018 17:00:21 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> <46c3d40c-c859-8af4-4d82-4955755f8f5d@oracle.com> <803be3dc-9ebd-7dbb-8922-dae10f1bf0bf@oracle.com> Message-ID: <00caebf6-ef6b-690b-b2df-c7a3019ee782@oracle.com> Hi Alex, It looks good to me. Thank you for the update. Thanks, Serguei On 10/5/18 4:53 PM, Alex Menkov wrote: > ok, this is updated webrev: > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.03/ > > --alex > > On 10/05/2018 12:37, serguei.spitsyn at oracle.com wrote: >> In general, like the suggestion from Jc with the correction for >> lastLine to be a local. >> But leave it up to Alex to decide what is better as changes would >> require another round of testing. >> >> Thanks, >> Serguei >> >> On 10/5/18 12:10 PM, JC Beyler wrote: >>> You're right for the single threaded part; I misread that part and >>> thought it would be multi-threaded as well. And fair enough for the >>> keeping it then as a do..while(false); it just took me a while to >>> figure out what was being done. You could put the data.lastLine in a >>> local variable and update it at the start of the method (only using >>> the local version for the rest of the method); then everything would >>> be in there. But, I'll still say it is a more a question of style :) >>> >>> LGTM, >>> Jc >>> >>> On Fri, Oct 5, 2018 at 12:01 PM Alex Menkov >>> > wrote: >>> >>> ??? Hi Jc, >>> >>> >>> ??? On 10/05/2018 10:34, JC Beyler wrote: >>> ??? > Hi Alex, >>> ??? > >>> ??? > One question and a comment on this: >>> ??? > - I thought HashMap was not thread safe so I think you need to >>> ??? > synchronize the access to the map threadData >>> >>> ??? The map is accessed from a single thread (main test thread which >>> ??? sends >>> ??? jdb commands and handles jdb replies), so synchronization is not >>> ??? required. >>> >>> ??? > >>> ??? > - I think your test code could be simplified if you moved it >>> into a >>> ??? > helper method (not tested but just for example): >>> >>> ??? I suppose you don't like do/break/while(false)? >>> ??? To me it's quite standard method to avoid multi-level if/then/else. >>> ??? In your suggestion I don't like that processNewData() method >>> handles >>> ??? minLine/maxLine, but doesn't handle lastLine (i.e. it doesn't do >>> all >>> ??? processing). But if "data.lastLine = lineNum" is moved into the >>> ??? method, >>> ??? we need something like do/break/while(false) in the method. >>> >>> ??? --alex >>> >>> ??? > >>> ??? > +? ? private void next() { >>> ??? > +? ? ? ? List reply = jdb.command(JdbCommand.next()); >>> ??? > +? ? ? ? /* >>> ??? > +? ? ? ? ?* Each "next" produces something like ("Breakpoint >>> ??? hit" line >>> ??? > only if the line has BP) >>> ??? > +? ? ? ? ?*? ?Step completed: >>> ??? > +? ? ? ? ?*? ? ?Breakpoint hit: "thread=jj2", >>> ??? > DeferredStepTestTarg$jj2.run(), line=74 bci=12 >>> ??? > +? ? ? ? ?*? ? ?74? ? ? ? ? ? ? ? ? ? ++count2; >>> ??? >? ?// @2 breakpoint >>> ??? > +? ? ? ? ?*? ? ? >>> ??? > +? ? ? ? ?*? ? ?jj2[1] >>> ??? > +? ? ? ? ?*/ >>> ??? > +? ? ? ? // detect thread from the last line >>> ??? > +? ? ? ? String lastLine = reply.get(reply.size() - 1); >>> ??? > +? ? ? ? String threadName = parse(threadRegexp, lastLine); >>> ??? > +? ? ? ? String wholeReply = >>> ??? > reply.stream().collect(Collectors.joining(Utils.NEW_LINE)); >>> ??? > +? ? ? ? int lineNum = Integer.parseInt(parse(lineRegexp, >>> ??? wholeReply)); >>> ??? > + >>> ??? > +? ? ? ? System.out.println("got: thread=" + threadName + ", >>> ??? line=" + >>> ??? > lineNum); >>> ??? > + >>> ??? > +? ? ? ? ThreadData data = threadData.get(threadName); >>> ??? > +? ? ? ? if (data == null) { >>> ??? > +? ? ? ? ? ? data = new ThreadData(); >>> ??? > +? ? ? ? ? ? threadData.put(threadName, data); >>> ??? > +? ? ? ? } >>> ??? > +? ? ? ? processNewData(data, threadName, lineNum); >>> ??? > +? ? ? ? data.lastLine = lineNum; >>> ??? > +? ? } >>> ??? > + >>> ??? > +? private void processNewData(ThreadData data, String >>> ??? threadName, int >>> ??? > lineNum) { >>> ??? > +? ? ? ? if (data.lastLine < 0) { >>> ??? > +? ? ? ? ? ? // the 1st stop in the thread >>> ??? > +? ? ? ? ? ? return; >>> ??? > +? ? ? ? } >>> ??? > + >>> ??? > +? ? ? ? if (lineNum == data.lastLine + 1) { >>> ??? > +? ? ? ? ? ? // expected. >>> ??? > +? ? ? ? ? ? return; >>> ??? > +? ? ? ? } >>> ??? > + >>> ??? > +? ? ? ? if (lineNum < data.lastLine) { >>> ??? > +? ? ? ? ? ? // looks like step to the beginning of the cycle >>> ??? > +? ? ? ? ? ? if (data.minLine > 0) { >>> ??? > +? ? ? ? ? ? ? ?// minLine and maxLine are not set - verify >>> ??? > +? ? ? ? ? ? ? ?Asserts.assertEquals(lineNum, data.minLine, >>> ??? threadName + >>> ??? > " - minLine"); >>> ??? > +? ? ? ? ? ? ? ?Asserts.assertEquals(data.lastLine, data.maxLine, >>> ??? > threadName + " - maxLine"); >>> ??? > +? ? ? ? ? ? } else { >>> ??? > +? ? ? ? ? ? ? ? // set minLine/maxLine >>> ??? > +? ? ? ? ? ? ? ? data.minLine = lineNum; >>> ??? > +? ? ? ? ? ? ? ? data.maxLine = data.lastLine; >>> ??? > +? ? ? ? ? ?} >>> ??? > +? ? ? ? ? ?return; >>> ??? > +? ? ? ? } >>> ??? > + >>> ??? > +? ? ? ? throw new RuntimeException(threadName + " (line " + >>> ??? lineNum + >>> ??? > ") - unexpected." >>> ??? > +? ? ? ? ? ? + " lastLine=" + data.lastLine + ", minLine=" + >>> ??? > data.minLine + ", maxLine=" + data.maxLine); >>> ??? > + } >>> ??? > >>> ??? > Thanks, >>> ??? > Jc >>> ??? > >>> ??? > >>> ??? > >>> ??? > On Thu, Oct 4, 2018 at 6:31 PM >> ??? >>> ??? > >> ??? >> wrote: >>> ??? > >>> ??? >? ? ?Hi Alex, >>> ??? > >>> ??? >? ? ?It looks good to me. >>> ??? >? ? ?Could you, please, also remove the line? : >>> ??? > >>> ??? >? ? ? ? 156? ? ? ? ? ? ?// >>> ??? > >>> ??? >? ? ?No need in new webrev. >>> ??? > >>> ??? >? ? ?Thanks, >>> ??? >? ? ?Serguei >>> ??? > >>> ??? > >>> ??? >? ? ?On 10/4/18 4:11 PM, Alex Menkov wrote: >>> ??? >? ? ? > Hi Serguei, >>> ??? >? ? ? > >>> ??? >? ? ? > Updated webrev: >>> ??? >? ? ? > >>> ??? > >>> http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ >>> >>> ??? > >>> ? >>> ??? >? ? ? > >>> ??? >? ? ? > Fixed all issues except >>> ??? >? ? ? > ?140???????????????? // the 1st stop in the thread >>> ??? >? ? ? > ?141???????????????? break; >>> ??? >? ? ? > In this case the comment is an explanation why we reach >>> the >>> ??? >? ? ?block, not >>> ??? >? ? ? > an explanation for the "break" statement. >>> ??? >? ? ? > >>> ??? >? ? ? > --alex >>> ??? >? ? ? > >>> ??? >? ? ? > On 10/04/2018 13:56, serguei.spitsyn at oracle.com >>> ??? >>> ??? >? ? ?>> ??? > wrote: >>> ??? >? ? ? >> Hi Alex, >>> ??? >? ? ? >> >>> ??? >? ? ? >> Several minor suggestions. >>> ??? >? ? ? >> >>> ??? >? ? ? >> 77 new Thread(aRP, "jj1").start(); >>> ??? >? ? ? >> 78 new Thread(asRP, "jj2").start(); What mean aRP and >>> ??? asRP? In >>> ??? >? ? ?fact, >>> ??? >? ? ? >> it is confusing. Can they be renamed to something like >>> ??? obj1 and >>> ??? >? ? ?obj2. >>> ??? >? ? ? >> >>> ??? >? ? ? >> 79 // new Thread(aRP, "jj3").start(); >>> ??? >? ? ? >> 80 // new Thread(asRP, "jj4").start(); >>> ??? >? ? ? >> >>> ??? >? ? ? >> ??These lines can be removed. >>> ??? >? ? ? >> >>> ??? >? ? ? >> 94 // line of the last stop >>> ??? >? ? ? >> 95 int lastLine = -1; >>> ??? >? ? ? >> 96 // min line (-1 means "not known yet") >>> ??? >? ? ? >> 97 int minLine = -1; >>> ??? >? ? ? >> 98 // max line (-1 means "not known yet") >>> ??? >? ? ? >> 99 int maxLine = -1; ... 140 // the 1st stop in the >>> thread >>> ??? >? ? ? >> 141 break; >>> ??? >? ? ? >> >>> ??? >? ? ? >> ?? I'd suggest the refactor above as below: >>> ??? >? ? ? >> >>> ??? >? ? ? >> int lastLine = -1;? // line of the last stop >>> ??? >? ? ? >> int minLine = -1;? // min line (-1 means "not known yet") >>> ??? >? ? ? >> int maxLine = -1;// max line (-1 means "not known yet") >>> ??? >? ? ? >> ? ... >>> ??? >? ? ? >> break;? // the 1st stop in the thread >>> ??? >? ? ? >> >>> ??? >? ? ? >> 116 private void next() { >>> ??? >? ? ? >> 117 List reply = jdb.command(JdbCommand.next()); >>> ??? >? ? ? >> 118 /* each "next" produces something like ("Breakpoint >>> ??? hit" line >>> ??? >? ? ? >> only if the line has BP) >>> ??? >? ? ? >> 119 Step completed: >>> ??? >? ? ? >> 120 Breakpoint hit: "thread=jj2", >>> ??? DeferredStepTestTarg$jj2.run(), >>> ??? >? ? ? >> line=74 bci=12 >>> ??? >? ? ? >> 121 74 ++count2; // @2 breakpoint >>> ??? >? ? ? >> 122 >>> ??? >? ? ? >> 123 jj2[1] >>> ??? >? ? ? >> 124 */ It would better to have it in this style: 118 /* >>> ??? * Each >>> ??? >? ? ?"next" >>> ??? >? ? ? >> produces something like ("Breakpoint hit" line only if >>> ??? the line >>> ??? >? ? ?has BP). >>> ??? >? ? ? >> 119 * Step completed: >>> ??? >? ? ? >> 120 * Breakpoint hit: "thread=jj2", >>> ??? DeferredStepTestTarg$jj2.run(), >>> ??? >? ? ? >> line=74 bci=12 >>> ??? >? ? ? >> 121 * 74 ++count2; // @2 breakpoint >>> ??? >? ? ? >> 122 * >>> ??? >? ? ? >> 123 * jj2[1] >>> ??? >? ? ? >> 124 */ >>> ??? >? ? ? >> >>> ??? >? ? ? >> >>> ??? >? ? ? >> Otherwise, it looks Okay to me. >>> ??? >? ? ? >> >>> ??? >? ? ? >> >>> ??? >? ? ? >> Thanks, >>> ??? >? ? ? >> Serguei >>> ??? >? ? ? >> >>> ??? >? ? ? >> On 10/3/18 5:49 PM, Alex Menkov wrote: >>> ??? >? ? ? >>> Hi all, >>> ??? >? ? ? >>> >>> ??? >? ? ? >>> please review a fix for >>> ??? >? ? ? >>> https://bugs.openjdk.java.net/browse/JDK-8211292 >>> ??? >? ? ? >>> webrev: >>> ??? >? ? ? >>> >>> ??? > >>> http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ >>> >>> ??? > >>> ? >>> ??? >? ? ? >>> >>> ??? >? ? ? >>> The fix converts manual shell test to automatic java >>> ??? (as Java >>> ??? >? ? ?allows >>> ??? >? ? ? >>> to parse jdb replies much easier). >>> ??? >? ? ? >>> This is the last sub-task for the "shell to java >>> ??? conversion" task, >>> ??? >? ? ? >>> so the fix also removes shared shell scripts. >>> ??? >? ? ? >>> >>> ??? >? ? ? >>> --alex >>> ??? >? ? ? >> >>> ??? > >>> ??? > >>> ??? > >>> ??? > -- >>> ??? > >>> ??? > Thanks, >>> ??? > Jc >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> From serguei.spitsyn at oracle.com Sat Oct 6 00:06:35 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 5 Oct 2018 17:06:35 -0700 Subject: RFR (L) 8211782: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[I-S]* In-Reply-To: References: Message-ID: Hi Jc, It looks good to me. Thanks, Serguei On 10/5/18 3:00 PM, JC Beyler wrote: > Hi all, > > I continued the NSK_CPP_STUB removal with this webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211782/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211782 > > This does another 50 file batch. I added the steps and scripts in this > bug as well so that you can see what was done. Some extra long lines > happen and I'm working on seeing if I can detect that ahead of time > but it might remain a manual step every time. > > I've tested the modified changes on my machine, all modified tests pass. > > Let me know what you think, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Sat Oct 6 01:19:15 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 5 Oct 2018 18:19:15 -0700 Subject: RFR JDK-8211292: [TEST] convert com/sun/jdi/DeferredStepTest.sh test In-Reply-To: <00caebf6-ef6b-690b-b2df-c7a3019ee782@oracle.com> References: <95167cce-fec0-cd89-8afa-7fb1067dab2c@oracle.com> <7dddf1db-5586-f718-e538-0c43d31bbb1c@oracle.com> <46c3d40c-c859-8af4-4d82-4955755f8f5d@oracle.com> <803be3dc-9ebd-7dbb-8922-dae10f1bf0bf@oracle.com> <00caebf6-ef6b-690b-b2df-c7a3019ee782@oracle.com> Message-ID: Hi Alex, Thanks also for the update; looks great to me! Jc On Fri, Oct 5, 2018 at 5:00 PM wrote: > Hi Alex, > > It looks good to me. > Thank you for the update. > > Thanks, > Serguei > > On 10/5/18 4:53 PM, Alex Menkov wrote: > > ok, this is updated webrev: > > > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.03/ > > > > --alex > > > > On 10/05/2018 12:37, serguei.spitsyn at oracle.com wrote: > >> In general, like the suggestion from Jc with the correction for > >> lastLine to be a local. > >> But leave it up to Alex to decide what is better as changes would > >> require another round of testing. > >> > >> Thanks, > >> Serguei > >> > >> On 10/5/18 12:10 PM, JC Beyler wrote: > >>> You're right for the single threaded part; I misread that part and > >>> thought it would be multi-threaded as well. And fair enough for the > >>> keeping it then as a do..while(false); it just took me a while to > >>> figure out what was being done. You could put the data.lastLine in a > >>> local variable and update it at the start of the method (only using > >>> the local version for the rest of the method); then everything would > >>> be in there. But, I'll still say it is a more a question of style :) > >>> > >>> LGTM, > >>> Jc > >>> > >>> On Fri, Oct 5, 2018 at 12:01 PM Alex Menkov > >>> > wrote: > >>> > >>> Hi Jc, > >>> > >>> > >>> On 10/05/2018 10:34, JC Beyler wrote: > >>> > Hi Alex, > >>> > > >>> > One question and a comment on this: > >>> > - I thought HashMap was not thread safe so I think you need to > >>> > synchronize the access to the map threadData > >>> > >>> The map is accessed from a single thread (main test thread which > >>> sends > >>> jdb commands and handles jdb replies), so synchronization is not > >>> required. > >>> > >>> > > >>> > - I think your test code could be simplified if you moved it > >>> into a > >>> > helper method (not tested but just for example): > >>> > >>> I suppose you don't like do/break/while(false)? > >>> To me it's quite standard method to avoid multi-level if/then/else. > >>> In your suggestion I don't like that processNewData() method > >>> handles > >>> minLine/maxLine, but doesn't handle lastLine (i.e. it doesn't do > >>> all > >>> processing). But if "data.lastLine = lineNum" is moved into the > >>> method, > >>> we need something like do/break/while(false) in the method. > >>> > >>> --alex > >>> > >>> > > >>> > + private void next() { > >>> > + List reply = jdb.command(JdbCommand.next()); > >>> > + /* > >>> > + * Each "next" produces something like ("Breakpoint > >>> hit" line > >>> > only if the line has BP) > >>> > + * Step completed: > >>> > + * Breakpoint hit: "thread=jj2", > >>> > DeferredStepTestTarg$jj2.run(), line=74 bci=12 > >>> > + * 74 ++count2; > >>> > // @2 breakpoint > >>> > + * > >>> > + * jj2[1] > >>> > + */ > >>> > + // detect thread from the last line > >>> > + String lastLine = reply.get(reply.size() - 1); > >>> > + String threadName = parse(threadRegexp, lastLine); > >>> > + String wholeReply = > >>> > reply.stream().collect(Collectors.joining(Utils.NEW_LINE)); > >>> > + int lineNum = Integer.parseInt(parse(lineRegexp, > >>> wholeReply)); > >>> > + > >>> > + System.out.println("got: thread=" + threadName + ", > >>> line=" + > >>> > lineNum); > >>> > + > >>> > + ThreadData data = threadData.get(threadName); > >>> > + if (data == null) { > >>> > + data = new ThreadData(); > >>> > + threadData.put(threadName, data); > >>> > + } > >>> > + processNewData(data, threadName, lineNum); > >>> > + data.lastLine = lineNum; > >>> > + } > >>> > + > >>> > + private void processNewData(ThreadData data, String > >>> threadName, int > >>> > lineNum) { > >>> > + if (data.lastLine < 0) { > >>> > + // the 1st stop in the thread > >>> > + return; > >>> > + } > >>> > + > >>> > + if (lineNum == data.lastLine + 1) { > >>> > + // expected. > >>> > + return; > >>> > + } > >>> > + > >>> > + if (lineNum < data.lastLine) { > >>> > + // looks like step to the beginning of the cycle > >>> > + if (data.minLine > 0) { > >>> > + // minLine and maxLine are not set - verify > >>> > + Asserts.assertEquals(lineNum, data.minLine, > >>> threadName + > >>> > " - minLine"); > >>> > + Asserts.assertEquals(data.lastLine, data.maxLine, > >>> > threadName + " - maxLine"); > >>> > + } else { > >>> > + // set minLine/maxLine > >>> > + data.minLine = lineNum; > >>> > + data.maxLine = data.lastLine; > >>> > + } > >>> > + return; > >>> > + } > >>> > + > >>> > + throw new RuntimeException(threadName + " (line " + > >>> lineNum + > >>> > ") - unexpected." > >>> > + + " lastLine=" + data.lastLine + ", minLine=" + > >>> > data.minLine + ", maxLine=" + data.maxLine); > >>> > + } > >>> > > >>> > Thanks, > >>> > Jc > >>> > > >>> > > >>> > > >>> > On Thu, Oct 4, 2018 at 6:31 PM >>> > >>> > >>> >> wrote: > >>> > > >>> > Hi Alex, > >>> > > >>> > It looks good to me. > >>> > Could you, please, also remove the line? : > >>> > > >>> > 156 // > >>> > > >>> > No need in new webrev. > >>> > > >>> > Thanks, > >>> > Serguei > >>> > > >>> > > >>> > On 10/4/18 4:11 PM, Alex Menkov wrote: > >>> > > Hi Serguei, > >>> > > > >>> > > Updated webrev: > >>> > > > >>> > > >>> > http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev.02/ > >>> < > http://cr.openjdk.java.net/%7Eamenkov/sh2java/DeferredStep_final/webrev.02/ > > > >>> > > >>> < > http://cr.openjdk.java.net/%7Eamenkov/sh2java/DeferredStep_final/webrev.02/ > > > >>> > > > >>> > > Fixed all issues except > >>> > > 140 // the 1st stop in the thread > >>> > > 141 break; > >>> > > In this case the comment is an explanation why we reach > >>> the > >>> > block, not > >>> > > an explanation for the "break" statement. > >>> > > > >>> > > --alex > >>> > > > >>> > > On 10/04/2018 13:56, serguei.spitsyn at oracle.com > >>> > >>> > >>> > wrote: > >>> > >> Hi Alex, > >>> > >> > >>> > >> Several minor suggestions. > >>> > >> > >>> > >> 77 new Thread(aRP, "jj1").start(); > >>> > >> 78 new Thread(asRP, "jj2").start(); What mean aRP and > >>> asRP? In > >>> > fact, > >>> > >> it is confusing. Can they be renamed to something like > >>> obj1 and > >>> > obj2. > >>> > >> > >>> > >> 79 // new Thread(aRP, "jj3").start(); > >>> > >> 80 // new Thread(asRP, "jj4").start(); > >>> > >> > >>> > >> These lines can be removed. > >>> > >> > >>> > >> 94 // line of the last stop > >>> > >> 95 int lastLine = -1; > >>> > >> 96 // min line (-1 means "not known yet") > >>> > >> 97 int minLine = -1; > >>> > >> 98 // max line (-1 means "not known yet") > >>> > >> 99 int maxLine = -1; ... 140 // the 1st stop in the > >>> thread > >>> > >> 141 break; > >>> > >> > >>> > >> I'd suggest the refactor above as below: > >>> > >> > >>> > >> int lastLine = -1; // line of the last stop > >>> > >> int minLine = -1; // min line (-1 means "not known yet") > >>> > >> int maxLine = -1;// max line (-1 means "not known yet") > >>> > >> ... > >>> > >> break; // the 1st stop in the thread > >>> > >> > >>> > >> 116 private void next() { > >>> > >> 117 List reply = jdb.command(JdbCommand.next()); > >>> > >> 118 /* each "next" produces something like ("Breakpoint > >>> hit" line > >>> > >> only if the line has BP) > >>> > >> 119 Step completed: > >>> > >> 120 Breakpoint hit: "thread=jj2", > >>> DeferredStepTestTarg$jj2.run(), > >>> > >> line=74 bci=12 > >>> > >> 121 74 ++count2; // @2 breakpoint > >>> > >> 122 > >>> > >> 123 jj2[1] > >>> > >> 124 */ It would better to have it in this style: 118 /* > >>> * Each > >>> > "next" > >>> > >> produces something like ("Breakpoint hit" line only if > >>> the line > >>> > has BP). > >>> > >> 119 * Step completed: > >>> > >> 120 * Breakpoint hit: "thread=jj2", > >>> DeferredStepTestTarg$jj2.run(), > >>> > >> line=74 bci=12 > >>> > >> 121 * 74 ++count2; // @2 breakpoint > >>> > >> 122 * > >>> > >> 123 * jj2[1] > >>> > >> 124 */ > >>> > >> > >>> > >> > >>> > >> Otherwise, it looks Okay to me. > >>> > >> > >>> > >> > >>> > >> Thanks, > >>> > >> Serguei > >>> > >> > >>> > >> On 10/3/18 5:49 PM, Alex Menkov wrote: > >>> > >>> Hi all, > >>> > >>> > >>> > >>> please review a fix for > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8211292 > >>> > >>> webrev: > >>> > >>> > >>> > > >>> http://cr.openjdk.java.net/~amenkov/sh2java/DeferredStep_final/webrev/ > >>> < > http://cr.openjdk.java.net/%7Eamenkov/sh2java/DeferredStep_final/webrev/> > >>> > > >>> < > http://cr.openjdk.java.net/%7Eamenkov/sh2java/DeferredStep_final/webrev/> > >>> > >>> > >>> > >>> The fix converts manual shell test to automatic java > >>> (as Java > >>> > allows > >>> > >>> to parse jdb replies much easier). > >>> > >>> This is the last sub-task for the "shell to java > >>> conversion" task, > >>> > >>> so the fix also removes shared shell scripts. > >>> > >>> > >>> > >>> --alex > >>> > >> > >>> > > >>> > > >>> > > >>> > -- > >>> > > >>> > Thanks, > >>> > Jc > >>> > >>> > >>> > >>> -- > >>> > >>> Thanks, > >>> Jc > >> > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Oct 8 07:46:15 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Oct 2018 00:46:15 -0700 Subject: RFR (XL) 8211801: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[A-E] In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Mon Oct 8 11:30:20 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 08 Oct 2018 07:30:20 -0400 Subject: RFR: JDK-8036026: nsk/jvmti/scenarios/capability/CM02/cm02t001 fails intermittently In-Reply-To: References: <5BB510A3.6000207@oracle.com> <71de6bee-d278-b3fd-d313-84514faa8426@oracle.com> <5BB5F56D.6080902@oracle.com> <5BB5FBDC.7080004@oracle.com> <8cd6cdfc-5fff-82de-c0f1-35402a180ed0@oracle.com> <5BB63A09.7060803@oracle.com> <74d7b85f-0176-d6b0-cca2-7504e61eb4ac@oracle.com> <5BB6472B.7000100@oracle.com> <30c4d83c-4f51-bf55-837a-15bcb7df8dc0@oracle.com> <5BB6607F.1060708@oracle.com> Message-ID: <5BBB3FCC.60000@oracle.com> Patch attached. (Added Dan as a reviewer) Chris if you can push this, I still need patches sponsored. To add time factor support is a much bigger task that should be done consistently across all the vmTestbase/nsk suite. On 10/4/18, 3:06 PM, Daniel D. Daugherty wrote: > Just FYI... > > http://mail.openjdk.java.net/pipermail/jtreg-use/2013-September/000256.html > > > shows how to access the test timeout factor. > > There are a few tests in the repo that show code examples: > > $ grep -r test.timeout.factor hotspot/jtreg > hotspot/jtreg/runtime/appcds/TestCommon.java: > System.getProperty("test.timeout.factor", "1.0"); > hotspot/jtreg/runtime/appcds/TestCommon.java: > cmd.add("-Dtest.timeout.factor=" + timeoutFactor); > hotspot/jtreg/runtime/appcds/test-classes/ParallelLoad.java: > Float.parseFloat(System.getProperty("test.timeout.factor", "1.0")); > > Your choice on how you want to proceed. > > Thumbs up from me either way. > > Dan > > > On 10/4/18 2:48 PM, Gary Adams wrote: >> fyi - I think JDK-8201603 tc02t001 is suffering from the same issue. >> A sleep(100) is used to provoke a contention with the debuggee thread. >> If the debuggee is not scheduled quickly enough, the main thread >> proceeds >> to release the contended object M and the test fails because not all >> the contended >> conditions were reported event. >> >> On 10/4/18, 1:03 PM, Daniel D. Daugherty wrote: >>> On 10/4/18 1:00 PM, Gary Adams wrote: >>>> On 10/4/18, 12:13 PM, Daniel D. Daugherty wrote: >>>>> On 10/4/18 12:04 PM, Gary Adams wrote: >>>>>> We currently use time factor 4 or 10 to scale up the jtreg tests. >>>>>> The change I proposed was already 10x100 = 1000. >>>>> >>>>> Agreed that you are already bumping it up by 10X. >>>>> >>>>> >>>>>> Since this is just a thread scheduling issue to let the debuggee >>>>>> run til it blocks, it should not require more time to get the >>>>>> switch to take place. >>>>> >>>>> Are you really trying to say that system load doesn't affect >>>>> thread scheduling time? >>>> In this particular test, the main thread and the debuggee thread >>>> are toggling back and forth around several monitors and >>>> synchronized code blocks. Not sure the tests are written >>>> for an arbitrarily high system load. >>>>> >>>>>> If this was a process scheduling issue, then more complex >>>>>> coordination might be worth considering. >>>>> >>>>> System load doesn't just affect process scheduling. It also >>>>> affects thread scheduling. If all the cores are busy, then >>>>> running another thread or another process is impacted. >>>>> >>>>> >>>>> In any case, I wasn't clear in my suggestion. >>>>> >>>>> - Thread.sleep(100); >>>>> + Thread.sleep(100 * timeoutFactor); >>>>> >>>>> assuming there is some easy way to get access to the >>>>> -timeoutFactor parameter. >>>> Currently, timeoutFactor has not been introduced to the vmTestbase/nsk >>>> test suite. >>> >>> Ummmm.... The -timeoutFactor parameter comes with JavaTest/JTREG >>> so it is already supported in the test harness that is uses to >>> run the vmTestbase/nsk test suite... What am I missing here? >>> >>> Dan >>> >>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>>> >>>>>> On 10/4/18, 11:45 AM, Daniel D. Daugherty wrote: >>>>>>> Sleeps don't scale under load. That said, I agree with Chris that >>>>>>> the code is already in place. One possible addition is to scale >>>>>>> the sleep value by the timeout factor for the test. That will >>>>>>> further reduce the likelihood of intermittent failures. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 10/4/18 7:39 AM, Gary Adams wrote: >>>>>>>> Oops, wrong comment used in the patch. >>>>>>>> Fresh patch attached. >>>>>>>> >>>>>>>> On 10/4/18, 7:11 AM, Gary Adams wrote: >>>>>>>>> Patch attached. >>>>>>>>> >>>>>>>>> I think one reviewer is sufficient for a trivial patch. >>>>>>>>> >>>>>>>>> On 10/3/18, 4:49 PM, Chris Plummer wrote: >>>>>>>>>> Hi Gary, >>>>>>>>>> >>>>>>>>>> Although I don't like relying on timer delays for stuff like >>>>>>>>>> this, the code for it is already in place, so I'm ok with >>>>>>>>>> making the delay longer to make sure there is contention on >>>>>>>>>> the monitor. Could you update the comment to read "// pause >>>>>>>>>> to provoke contention on thread.endingMonitor" >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> >>>>>>>>>> Chris >>>>>>>>>> >>>>>>>>>> On 10/3/18 11:55 AM, Gary Adams wrote: >>>>>>>>>>> While running a block of nsk/jvmti/scenarios tests, I >>>>>>>>>>> noticed an occasional failure >>>>>>>>>>> for cm02t001 in windows debug platform. After enabling the >>>>>>>>>>> nsk verbose >>>>>>>>>>> diagnostics and adding a few messages in the main test and >>>>>>>>>>> the debuggee >>>>>>>>>>> thread, it became clear that the missing contention was due >>>>>>>>>>> to the main thread >>>>>>>>>>> getting ahead of the debugee thread. >>>>>>>>>>> >>>>>>>>>>> The call to letFinish() below let's the deuggee thread wake >>>>>>>>>>> up from it's wait >>>>>>>>>>> and proceed to the contention for the endingMonitor. If the >>>>>>>>>>> main thread >>>>>>>>>>> waits a little longer it should reach the debuggee thread >>>>>>>>>>> synchronized block. >>>>>>>>>>> >>>>>>>>>>> I reopened an earlier bug that was closed as CNR. >>>>>>>>>>> >>>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8036026 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> diff --git >>>>>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>>>> +++ >>>>>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001.java >>>>>>>>>>> @@ -82,7 +82,7 @@ >>>>>>>>>>> thread.letFinish(); >>>>>>>>>>> >>>>>>>>>>> // pause to provoke contention >>>>>>>>>>> - Thread.sleep(100); >>>>>>>>>>> + Thread.sleep(1000); >>>>>>>>>>> } catch (InterruptedException e) { >>>>>>>>>>> throw new Failure(e); >>>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8036026.patch URL: From gary.adams at oracle.com Mon Oct 8 11:47:00 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 08 Oct 2018 07:47:00 -0400 Subject: RFR: JDK-8201603: MonitorContendedEnter failure in nsk/jvmti/scenarios/contention/TC02/tc02t001 Message-ID: <5BBB43B4.6050103@oracle.com> The main thread in tc02t001 is using a sleep(100) to cause a monitor contention for the debuggee thread. On some slower platform builds the main thread continues before the debuggee thread observes the contention. Similar to the fix for cm02t001, this is a simple change to increase the pauses to allow the debuggee thread to run. Webrev: http://cr.openjdk.java.net/~gadams/8201603/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8201603 From gary.adams at oracle.com Mon Oct 8 18:15:02 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 08 Oct 2018 14:15:02 -0400 Subject: RFR: JDK-8211324: Link to java.lang.ThreadGroup in JDWP spec is broken Message-ID: <5BBB9EA6.9070209@oracle.com> Alan suggested in the bug report for the broken link from the jdwp-protocol spec to the java/lang/ThreadGroup documentation to simply remove the href link. Another possibility is to simply update the link to include the java.base subdirectory. I don't think the doc structure changes very often so either solution seems fine to me. diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec --- a/make/data/jdwp/jdwp.spec +++ b/make/data/jdwp/jdwp.spec @@ -2185,7 +2185,7 @@ "in this thread group. Threads and thread groups in child " "thread groups are not included. " "A thread is alive if it has been started and has not yet been stopped. " - "See java.lang.ThreadGroup + "See java.lang.ThreadGroup "for information about active ThreadGroups. (Out (threadGroupObject group "The thread group object ID. ") From chris.plummer at oracle.com Mon Oct 8 18:21:10 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 8 Oct 2018 11:21:10 -0700 Subject: RFR: JDK-8201603: MonitorContendedEnter failure in nsk/jvmti/scenarios/contention/TC02/tc02t001 In-Reply-To: <5BBB43B4.6050103@oracle.com> References: <5BBB43B4.6050103@oracle.com> Message-ID: <2768f7c7-bbaa-e8fb-070b-e7b868982205@oracle.com> Hi Gary, Looks good. Please add the comment "Wait for contended "sychronized (M)". thanks, Chris On 10/8/18 4:47 AM, Gary Adams wrote: > The main thread in tc02t001 is using a sleep(100) to cause a > monitor contention for the debuggee thread. On some slower > platform builds the main thread continues before the debuggee > thread observes the contention. > > Similar to the fix for cm02t001, this is a simple change to increase > the pauses to allow the debuggee thread to run. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8201603/webrev/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8201603 From chris.hegarty at oracle.com Mon Oct 8 18:30:11 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 8 Oct 2018 19:30:11 +0100 Subject: RFR: JDK-8211324: Link to java.lang.ThreadGroup in JDWP spec is broken In-Reply-To: <5BBB9EA6.9070209@oracle.com> References: <5BBB9EA6.9070209@oracle.com> Message-ID: <79723D43-5498-4360-A1C5-76AB2D122A5C@oracle.com> The updated link looks ok to me. -Chris > On 8 Oct 2018, at 19:15, Gary Adams wrote: > > Alan suggested in the bug report for the broken link from the jdwp-protocol > spec to the java/lang/ThreadGroup documentation to simply remove the > href link. Another possibility is to simply update the link to include the java.base > subdirectory. > > I don't think the doc structure changes very often so either solution > seems fine to me. > > diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec > --- a/make/data/jdwp/jdwp.spec > +++ b/make/data/jdwp/jdwp.spec > @@ -2185,7 +2185,7 @@ > "in this thread group. Threads and thread groups in child " > "thread groups are not included. " > "A thread is alive if it has been started and has not yet been stopped. " > - "See java.lang.ThreadGroup > + "See java.lang.ThreadGroup > "for information about active ThreadGroups. > (Out > (threadGroupObject group "The thread group object ID. ") From gary.adams at oracle.com Mon Oct 8 19:03:31 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 08 Oct 2018 15:03:31 -0400 Subject: RFR: JDK-8201603: MonitorContendedEnter failure in nsk/jvmti/scenarios/contention/TC02/tc02t001 In-Reply-To: <5BBBA9A8.2050409@oracle.com> References: <5BBBA9A8.2050409@oracle.com> Message-ID: <5BBBAA03.8090704@oracle.com> Patch attached. I think one reviewer is sufficient since this mimics the cm02t001 bug fix. On 10/8/18, 3:02 PM, Gary Adams wrote: > Hi Gary, > > Looks good. Please add the comment "Wait for contended "sychronized (M)". > > thanks, > > Chris > > On 10/8/18 4:47 AM, Gary Adams wrote: > >/ The main thread in tc02t001 is using a sleep(100) to cause a > />/ monitor contention for the debuggee thread. On some slower > />/ platform builds the main thread continues before the debuggee > />/ thread observes the contention. > />/ > />/ Similar to the fix for cm02t001, this is a simple change to increase > />/ the pauses to allow the debuggee thread to run. > />/ > />/ Webrev:http://cr.openjdk.java.net/~gadams/8201603/webrev/ > />/ Issue:https://bugs.openjdk.java.net/browse/JDK-8201603 > / > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8201603.patch URL: From alexey.menkov at oracle.com Mon Oct 8 19:12:43 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 8 Oct 2018 12:12:43 -0700 Subject: RFR (L) 8211782: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[I-S]* In-Reply-To: References: Message-ID: <033ee366-8b9b-6910-a453-198d28ae81eb@oracle.com> Looks good. For some reason one statement in nsk/jvmti/RetransformClasses/retransform003/retransform003.cpp (@@ -105,92 +97,35 @@) was not converted to 1-liner like others in the same file: + if (!NSK_VERIFY((loader_class = jni->GetObjectClass(loader) ) != NULL ) ) Could you please fix it (no need other round of review) --alex On 10/05/2018 17:06, serguei.spitsyn at oracle.com wrote: > Hi Jc, > > It looks good to me. > > Thanks, > Serguei > > On 10/5/18 3:00 PM, JC Beyler wrote: >> Hi all, >> >> I continued the NSK_CPP_STUB removal with this webrev: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211782/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211782 >> >> This does another 50 file batch. I added the steps and scripts in this >> bug as well so that you can see what was done. Some extra long lines >> happen and I'm working on seeing if I can detect that ahead of time >> but it might remain a manual step every time. >> >> I've tested the modified changes on my machine, all modified tests pass. >> >> Let me know what you think, >> Jc > From Alan.Bateman at oracle.com Mon Oct 8 19:39:22 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 8 Oct 2018 20:39:22 +0100 Subject: RFR: JDK-8211324: Link to java.lang.ThreadGroup in JDWP spec is broken In-Reply-To: <5BBB9EA6.9070209@oracle.com> References: <5BBB9EA6.9070209@oracle.com> Message-ID: <4d61992e-ae80-e219-62fa-84f945f1fef2@oracle.com> On 08/10/2018 19:15, Gary Adams wrote: > Alan suggested in the bug report for the broken link from the > jdwp-protocol > spec to the java/lang/ThreadGroup documentation to simply remove the > href link. Another possibility is to simply update the link to include > the java.base > subdirectory. My comment in the bug is just a concern is that spec <--> API refs have been very difficult to keep working. In this case, there is only one unimportant link from the JDWP spec to the API docs. I'm okay with the patch you have too. -Alan From serguei.spitsyn at oracle.com Mon Oct 8 19:58:14 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Oct 2018 12:58:14 -0700 Subject: RFR: JDK-8211324: Link to java.lang.ThreadGroup in JDWP spec is broken In-Reply-To: <79723D43-5498-4360-A1C5-76AB2D122A5C@oracle.com> References: <5BBB9EA6.9070209@oracle.com> <79723D43-5498-4360-A1C5-76AB2D122A5C@oracle.com> Message-ID: <80efcf56-f799-a45f-bfb4-5102cbf40b49@oracle.com> Hi Gary, +1 Thanks, Serguei On 10/8/18 11:30, Chris Hegarty wrote: > The updated link looks ok to me. > > -Chris > >> On 8 Oct 2018, at 19:15, Gary Adams wrote: >> >> Alan suggested in the bug report for the broken link from the jdwp-protocol >> spec to the java/lang/ThreadGroup documentation to simply remove the >> href link. Another possibility is to simply update the link to include the java.base >> subdirectory. >> >> I don't think the doc structure changes very often so either solution >> seems fine to me. >> >> diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec >> --- a/make/data/jdwp/jdwp.spec >> +++ b/make/data/jdwp/jdwp.spec >> @@ -2185,7 +2185,7 @@ >> "in this thread group. Threads and thread groups in child " >> "thread groups are not included. " >> "A thread is alive if it has been started and has not yet been stopped. " >> - "See java.lang.ThreadGroup >> + "See java.lang.ThreadGroup >> "for information about active ThreadGroups. >> (Out >> (threadGroupObject group "The thread group object ID. ") From jcbeyler at google.com Mon Oct 8 20:57:32 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 8 Oct 2018 13:57:32 -0700 Subject: RFR (L) 8211782: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/[I-S]* In-Reply-To: <033ee366-8b9b-6910-a453-198d28ae81eb@oracle.com> References: <033ee366-8b9b-6910-a453-198d28ae81eb@oracle.com> Message-ID: Thanks both, I pushed it with Alex' minor fix, Jc On Mon, Oct 8, 2018 at 12:12 PM Alex Menkov wrote: > Looks good. > > For some reason one statement in > nsk/jvmti/RetransformClasses/retransform003/retransform003.cpp > (@@ -105,92 +97,35 @@) > was not converted to 1-liner like others in the same file: > + if (!NSK_VERIFY((loader_class = jni->GetObjectClass(loader) > ) != NULL > ) > ) > Could you please fix it (no need other round of review) > > --alex > > On 10/05/2018 17:06, serguei.spitsyn at oracle.com wrote: > > Hi Jc, > > > > It looks good to me. > > > > Thanks, > > Serguei > > > > On 10/5/18 3:00 PM, JC Beyler wrote: > >> Hi all, > >> > >> I continued the NSK_CPP_STUB removal with this webrev: > >> > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211782/webrev.00/ > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211782 > >> > >> This does another 50 file batch. I added the steps and scripts in this > >> bug as well so that you can see what was done. Some extra long lines > >> happen and I'm working on seeing if I can detect that ahead of time > >> but it might remain a manual step every time. > >> > >> I've tested the modified changes on my machine, all modified tests pass. > >> > >> Let me know what you think, > >> Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Oct 8 21:53:22 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 8 Oct 2018 14:53:22 -0700 Subject: RFR (XL) 8211801: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[A-E] In-Reply-To: References: Message-ID: Hi Serguei, Normally, I try not to fix issues that already exist before the change. For the space after the NULL for example, that would get fixed by https://bugs.openjdk.java.net/browse/JDK-8211335. In this case, these are the only cases where this happens with a NULL so I fixed them. For the space missing before jvmti->X, I fixed my script to handle this correctly and add them automatically. Here is the new webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211801/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8211801 Thanks for the review! Jc On Mon, Oct 8, 2018 at 12:46 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Jc, > > > > http://cr.openjdk.java.net/%7Ejcbeyler/8211801/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.cpp.udiff.html > > if (!NSK_JNI_VERIFY(jni, (fid =- NSK_CPP_STUB4(GetStaticFieldID, jni,- debugeeClass,- "thread",- THREAD_CLS_SIGNATURE)) != NULL )) {+ jni->GetStaticFieldID(debugeeClass, "thread", THREAD_CLS_SIGNATURE)) != NULL )) { > nsk_jvmti_setFailStatus(); > break; > } > > if (!NSK_JNI_VERIFY(jni, (localRefThread =- NSK_CPP_STUB3(GetStaticObjectField, jni,- debugeeClass,- fid )) != NULL )) {+ jni->GetStaticObjectField(debugeeClass, fid)) != NULL )) { > NSK_COMPLAIN0("GetStaticObjectField returned NULL for 'thread' field value\n\n"); > nsk_jvmti_setFailStatus(); > break; > } > > Could you, please, remove extra space after NULL. > > > In many-many files (especially, in the foleder: scenarios/capability): > > + if (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->SuspendThread(thread))) > ...+ if (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->ResumeThread(thread))) > ...+ if (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->InterruptThread(thread))) > > > There are a lot of cases like above where a space before jvmti-> is missed. > > > Otherwise, looks good. > > > Thanks! > Serguei > > > On 10/5/18 16:50, JC Beyler wrote: > > Hi all, > > I continued the NSK_CPP_STUB removal with this next webrev. > > My apologies, this one is big for 50 files; I can further cut it up if we > prefer. It is straight-forward though, since it is just doing the same > NSK_CPP_STUB removal. > > Without further ado: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211801/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8211801 > > This does another 50 file batch. I did the same for > https://bugs.openjdk.java.net/browse/JDK-8211782 so the scripts can be > found there (and added a comment in this bug to link to that). > > I've tested the modified changes on my machine, all modified tests pass. > > Let me know what you think, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Oct 8 22:31:17 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Oct 2018 15:31:17 -0700 Subject: RFR (XL) 8211801: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[A-E] In-Reply-To: References: Message-ID: <13ff4afa-34d9-1168-53d6-666ca9b524db@oracle.com> An HTML attachment was scrubbed... URL: From hohensee at amazon.com Mon Oct 8 23:49:33 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 8 Oct 2018 23:49:33 +0000 Subject: RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions Message-ID: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8196989 CSR: https://bugs.openjdk.java.net/browse/JDK-8196991 Webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.02/ As requested, I split the jstat counter update off from the MXBean update. This is the MXBean update. The jstat counter RFE is https://bugs.openjdk.java.net/browse/JDK-8210965 and its CSR is https://bugs.openjdk.java.net/browse/JDK-8210966. The MXBean CSR is in draft state, I?d greatly appreciate review and sign-off. It?s been suggested that we add another pool to represent the free region set, but doing so would be incompatible with existing MXBean use invariants for all GCs. These are: 1. The sum of the pools? MemoryUsage.max properties is the total reserved heap size. 2. The sum of the pools? MemoryUsage.committed properties is the total committed size. 3. The sum of the pools? MemoryUsage.used properties is the total size of the memory containing objects, live and dead-and-yet-to-be-collected, as the case might be, plus intentional gaps between them. 4. The total free space is (sum of the max properties ? sum of the used properties). 5. The total uncommitted space is (sum of the max properties ? sum of the committed properties). 6. The total committed free space is (2) ? (3). To keep invariants 1, 2 and 3, the free region pool?s ?max? property should be ?undefined? (i.e., -1). The intuitive, to me, ?used? property value would be the total free space, but that would violate invariant 4 above. Defining the ?committed? property as the total committed free space would violate invariants 2 and 6. The patch passes the submit repo, hotspot tier1, and, separately, the serviceability, jfr, and gc jtreg tests. I?m uncertain how to construct a test that checks for valid MXBean content: the existing tests don?t. Any such test will be fragile due to possible future Hotspot changes that affect the values, and to run-to-run variability. I?ve done by-hand comparisons between the old and new MXBean content using the SwingSet2 demo, including using App CDS, and the numbers look reasonable. The guts of the change are in G1MonitoringSupport::recalculate_sizes, initialize_serviceability, memory_managers, memory_pools, and G1MonitoringScope. I also defined TraceConcMemoryManagerStats to track the concurrent cycle in a way analogous to TraceCMSMemoryManagerStats. The changes to the includes in g1FullGCOopClosures.inline.hpp and g1HeapVerifier.cpp are to satisfy compiler complaints. I changed the 3rd argument to the G1MonitoringScope constructor to a mixed_gc flag, and use accessor methods instead of direct field accesses when accessor methods exist. I believe I?ve minimized the latter. I updated the copyright date to 2018 in memoryService.hpp because I neglected to do so in my previous G1 MXBean patch. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Oct 9 00:53:41 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Oct 2018 17:53:41 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> Message-ID: <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Oct 9 00:57:30 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Oct 2018 17:57:30 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> Message-ID: <3bc104e0-9416-9e4f-abd3-168c9fdb2096@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Oct 9 01:12:53 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 08 Oct 2018 18:12:53 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> Message-ID: Hi Serguei, Chris, Alex, and Garry, Thank you for reviewing this change. I will remove added space in test/jdk/com/sun/jdi/TestScaffold.java ?resumeTo() method before pushing the change. It was accidentally added. -??????? return (BreakpointEvent)waitForRequestedEvent(request); +??????? return (BreakpointEvent) waitForRequestedEvent(request); Best regards, Daniil From: "serguei.spitsyn at oracle.com" Date: Monday, October 8, 2018 at 5:53 PM To: Daniil Titov , Chris Plummer , Cc: serviceability-dev Subject: Re: RFR 8193879: Java debugger hangs on method invocation Hi Daniil, It seems to me, this fix is going to work. The freeze() method only cares there are no pending resume commands: ? 99???? synchronized void freeze() { 100???????? if (cache == null && (pendingResumeCommands.isEmpty())) { 101???????????? /* 102????????????? * No pending resumes to worry about. The VM is suspended 103????????????? * and additional state can be cached. Notify all 104??? ??????????* interested listeners. 105????????????? */ 106???????????? processVMAction(new VMAction(vm, VMAction.VM_SUSPENDED)); 107???????????? enableCache(); 108???????? } 109???? } With new version of the notifyCommandComplete: ? 95???? void notifyCommandComplete(int id) { ? 96???????? pendingResumeCommands.remove(id); ? 97???? } a pending resume command can be deleted from the pendingResumeCommands set. This does not matter if the collection is already empty. The only other place for a potential conflict is the method: 111???? synchronized PacketStream thawCommand(CommandSender sender) { 112???????? PacketStream stream = sender.send(); 113???????? pendingResumeCommands.add(stream.id()); 114???????? thaw(); 115???????? return stream; 116???? } However, there is no problem here as the pendingResumeCommands is a synchronized set. -??????? return (BreakpointEvent)waitForRequestedEvent(request); +??????? return (BreakpointEvent) waitForRequestedEvent(request); Not sure why have you added space after the cast. We should not have it by coding convention. Also, the local style does not have it as well. Examples are: 761???????? StepEvent retEvent = (StepEvent)waitForRequestedEvent(sr); 835???????? return (Location)locs.get(0); 873???????? return (ClassPrepareEvent)waitForRequestedEvent(request); Otherwise, it looks pretty good to me. No need in another webrev if you fix the above. Thanks, Serguei On 10/4/18 14:19, Daniil Titov wrote: Hi Gary and Chris, Please review an updated version of the patch that has newly added test for the case when suspend policy is set to SUSPEND_EVENT_THREAD reimplemented using JDI API. Thus, the changes in src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java are no longer required. I think vmInterrupted() is not invoked when suspend policy is set to SUSPEND_EVENT_THREAD to address the case when different threads keep hitting the same breakpoint and to avoid the switching the current thread in the background. The actual behavior of the debugger in the case when the breakpoint is hit and suspend policy is set to SUSPEND_EVENT_THREAD is just to print "Breakpoint hit:" in the output without adding any additional information or new line character. After that you need to set the current thread by entering "thread" command , e.g. "thread 1" and? only then jdb prints the prompt (e.g. "main[1]") .? The behavior looks as confusing since it is not obvious for the user that some input is expected from him (e.g. to set the current thread).? I created a separated issue for that at https://bugs.openjdk.java.net/browse/JDK-8211736 . Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.02/ Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 Thanks, --Daniil ?On 10/4/18, 10:28 AM, "Chris Plummer" wrote: ??? On 10/4/18 5:12 AM, Gary Adams wrote: ??? > In TTY.java do you need to force a simple prompt for the ??? > breakpoint event output? What prevents currentThread from ??? > being set at the time you are printing the prompt? ??? > ??? > ??? >? 103???????? // Print the prompt if suspend policy is ????> SUSPEND_EVENT_THREAD. In case of ??? >? 104???????? // SUSPEND_ALL policy this is handled by vmInterrupted() ????> method. ??? >? 105???????? if (be.request().suspendPolicy() == ????> EventRequest.SUSPEND_EVENT_THREAD) { ??? >? 106???????????? MessageOutput.println(); ??? >? 107???????????? MessageOutput.printPrompt(); ??? Normally the thread is suspended after the above code is executed: ??? ?????????public void run() { ???????????? EventQueue queue = Env.vm().eventQueue(); ???????????? while (connected) { ???????????????? try { ???????????????????? EventSet eventSet = queue.remove(); ???????????????????? boolean resumeStoppedApp = false; ??? ?????????????????EventIterator it = eventSet.eventIterator(); ???????????????????? while (it.hasNext()) { ???????????????????????? resumeStoppedApp |= !handleEvent(it.nextEvent()); ????<--- calls the modified code above ???????????????????? } ??? ?????????????????????if (resumeStoppedApp) { ???????????????????????? eventSet.resume(); ???????????????????? } else if (eventSet.suspendPolicy() == ????EventRequest.SUSPEND_ALL) { ???????????????????????? setCurrentThread(eventSet);?? <------ ????????????????? ???????notifier.vmInterrupted(); ???????????????????? } ??? ????However, it only calls setCurrentThread() for SUSPEND_ALL policies. So ????what Daniil has done here is make it print a simple prompt if the policy ????is SUSPEND_EVENT_THREAD. It's unclear to me what the actual debugger ????behavior is in this case. Don't we still suspend and get a prompt from ????which we can type in the next command? In this case, wouldn't you want a ????full prompt? Related to that question, why is vmInterrupted() only ????called if we suspend all threads, and not when we just suspend the ????thread that the breakpoint came in on? ??? ????Chris ??? > ??? > ??? > In Jdb.java you allow the waiting for the simple prompt. ??? > I don't see waitForSimplePrompt used in any existing tests. ??? > Since it is only looking for a single character it could ??? > produce false positives if the '>' was produced in the ??? > output stream. Is this wait paired to the added prompt for the ??? > break point event? ??? > ??? >? 236???????? return waitForSimplePrompt ? waitForSimplePrompt(1, ????> cmd.allowExit) : waitForPrompt(1, cmd.allowExit); ??? > ??? > It might be a good idea to include a test with multiple ??? > threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD ??? > behavior. ??? > ??? > On 10/4/18, 12:29 AM, Daniil Titov wrote: ??? >> Please review the changes that fix the deadlock in the debugger when ????>> the debugger is running with the tracing option on. ??? >> ??? >> The problem here is that when the tracing is on the "JDI Target VM ????>> Interface" thread (the thread that reads all replies and then ????>> notifies the thread that sent the request that the reply has been ??? >> received) is waiting for a lock which is already acquired by the ????>> thread that sent the request and is waiting for reply. ??? >> ??? >> The fix itself is in ????>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. ??? >> ??? >> The patch also reverts the changes done in 8129348 "Debugger hangs in ????>> trace mode with TRACE_SENDS" in ????>> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java ????>> since they address only a specific case (VM is suspended and static ????>> method is invoked) while the proposed fix also solves issue 8129348 ????>> as well as issue 8193801 "Debugger hangs in trace mode for non-static ????>> methods". ??? >> ??? >> The changes include new tests for issues 8193879, 8193801 and 8129348. ??? >> ??? >> The changes in ????>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ????>> solve the problem that the prompt is not printed in the debugger ????>> output when the breakpoint is hit and the suspend policy is ????>> SUSPEND_EVENT_THREAD. This is required for new tests to detect that ????>> command "stop thread at ..." is completed. ??? >> ??? >> Mach5 build and jdk_jdi tests succeeded. ??? >> ??? >> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ ??? >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 ??? >> ??? >> Thanks, ??? >> --Daniil ??? >> ??? >> ??? >> ??? > ??? ???? -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Oct 9 01:17:11 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Oct 2018 18:17:11 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> Message-ID: <52e17b93-d82b-4b2f-bee4-fb4344314c80@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Oct 9 02:12:00 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 08 Oct 2018 19:12:00 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <52e17b93-d82b-4b2f-bee4-fb4344314c80@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> <52e17b93-d82b-4b2f-bee4-fb4344314c80@oracle.com> Message-ID: <224C7885-1EE9-4AA1-AC8C-87FA6116838B@oracle.com> Hi Serguei, Sure. That was my intention. Thanks! Bets regards, Daniil From: "serguei.spitsyn at oracle.com" Date: Monday, October 8, 2018 at 6:17 PM To: Daniil Titov , , Alex Menkov , Chris Plummer Cc: serviceability-dev Subject: Re: RFR 8193879: Java debugger hangs on method invocation Daniil, Could you wait a little bit for reply from Severin G.? Thanks, Serguei On 10/8/18 18:12, Daniil Titov wrote: Hi Serguei, Chris, Alex, and Garry, Thank you for reviewing this change. I will remove added space in test/jdk/com/sun/jdi/TestScaffold.java resumeTo() method before pushing the change. It was accidentally added. - return (BreakpointEvent)waitForRequestedEvent(request); + return (BreakpointEvent) waitForRequestedEvent(request); Best regards, Daniil From: "serguei.spitsyn at oracle.com" Date: Monday, October 8, 2018 at 5:53 PM To: Daniil Titov , Chris Plummer , Cc: serviceability-dev Subject: Re: RFR 8193879: Java debugger hangs on method invocation Hi Daniil, It seems to me, this fix is going to work. The freeze() method only cares there are no pending resume commands: 99 synchronized void freeze() { 100 if (cache == null && (pendingResumeCommands.isEmpty())) { 101 /* 102 * No pending resumes to worry about. The VM is suspended 103 * and additional state can be cached. Notify all 104 * interested listeners. 105 */ 106 processVMAction(new VMAction(vm, VMAction.VM_SUSPENDED)); 107 enableCache(); 108 } 109 } With new version of the notifyCommandComplete: 95 void notifyCommandComplete(int id) { 96 pendingResumeCommands.remove(id); 97 } a pending resume command can be deleted from the pendingResumeCommands set. This does not matter if the collection is already empty. The only other place for a potential conflict is the method: 111 synchronized PacketStream thawCommand(CommandSender sender) { 112 PacketStream stream = sender.send(); 113 pendingResumeCommands.add(stream.id()); 114 thaw(); 115 return stream; 116 } However, there is no problem here as the pendingResumeCommands is a synchronized set. - return (BreakpointEvent)waitForRequestedEvent(request); + return (BreakpointEvent) waitForRequestedEvent(request); Not sure why have you added space after the cast. We should not have it by coding convention. Also, the local style does not have it as well. Examples are: 761 StepEvent retEvent = (StepEvent)waitForRequestedEvent(sr); 835 return (Location)locs.get(0); 873 return (ClassPrepareEvent)waitForRequestedEvent(request); Otherwise, it looks pretty good to me. No need in another webrev if you fix the above. Thanks, Serguei On 10/4/18 14:19, Daniil Titov wrote: Hi Gary and Chris, Please review an updated version of the patch that has newly added test for the case when suspend policy is set to SUSPEND_EVENT_THREAD reimplemented using JDI API. Thus, the changes in src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java are no longer required. I think vmInterrupted() is not invoked when suspend policy is set to SUSPEND_EVENT_THREAD to address the case when different threads keep hitting the same breakpoint and to avoid the switching the current thread in the background. The actual behavior of the debugger in the case when the breakpoint is hit and suspend policy is set to SUSPEND_EVENT_THREAD is just to print "Breakpoint hit:" in the output without adding any additional information or new line character. After that you need to set the current thread by entering "thread" command , e.g. "thread 1" and only then jdb prints the prompt (e.g. "main[1]") . The behavior looks as confusing since it is not obvious for the user that some input is expected from him (e.g. to set the current thread). I created a separated issue for that at https://bugs.openjdk.java.net/browse/JDK-8211736 . Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.02/ Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 Thanks, --Daniil ?On 10/4/18, 10:28 AM, "Chris Plummer" wrote: On 10/4/18 5:12 AM, Gary Adams wrote: > In TTY.java do you need to force a simple prompt for the > breakpoint event output? What prevents currentThread from > being set at the time you are printing the prompt? > > > 103 // Print the prompt if suspend policy is > SUSPEND_EVENT_THREAD. In case of > 104 // SUSPEND_ALL policy this is handled by vmInterrupted() > method. > 105 if (be.request().suspendPolicy() == > EventRequest.SUSPEND_EVENT_THREAD) { > 106 MessageOutput.println(); > 107 MessageOutput.printPrompt(); Normally the thread is suspended after the above code is executed: public void run() { EventQueue queue = Env.vm().eventQueue(); while (connected) { try { EventSet eventSet = queue.remove(); boolean resumeStoppedApp = false; EventIterator it = eventSet.eventIterator(); while (it.hasNext()) { resumeStoppedApp |= !handleEvent(it.nextEvent()); <--- calls the modified code above } if (resumeStoppedApp) { eventSet.resume(); } else if (eventSet.suspendPolicy() == EventRequest.SUSPEND_ALL) { setCurrentThread(eventSet); <------ notifier.vmInterrupted(); } However, it only calls setCurrentThread() for SUSPEND_ALL policies. So what Daniil has done here is make it print a simple prompt if the policy is SUSPEND_EVENT_THREAD. It's unclear to me what the actual debugger behavior is in this case. Don't we still suspend and get a prompt from which we can type in the next command? In this case, wouldn't you want a full prompt? Related to that question, why is vmInterrupted() only called if we suspend all threads, and not when we just suspend the thread that the breakpoint came in on? Chris > > > In Jdb.java you allow the waiting for the simple prompt. > I don't see waitForSimplePrompt used in any existing tests. > Since it is only looking for a single character it could > produce false positives if the '>' was produced in the > output stream. Is this wait paired to the added prompt for the > break point event? > > 236 return waitForSimplePrompt ? waitForSimplePrompt(1, > cmd.allowExit) : waitForPrompt(1, cmd.allowExit); > > It might be a good idea to include a test with multiple > threads each with a breakpoint that will trigger SUSPEND_EVENT_THREAD > behavior. > > On 10/4/18, 12:29 AM, Daniil Titov wrote: >> Please review the changes that fix the deadlock in the debugger when >> the debugger is running with the tracing option on. >> >> The problem here is that when the tracing is on the "JDI Target VM >> Interface" thread (the thread that reads all replies and then >> notifies the thread that sent the request that the reply has been >> received) is waiting for a lock which is already acquired by the >> thread that sent the request and is waiting for reply. >> >> The fix itself is in >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >> >> The patch also reverts the changes done in 8129348 "Debugger hangs in >> trace mode with TRACE_SENDS" in >> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java >> since they address only a specific case (VM is suspended and static >> method is invoked) while the proposed fix also solves issue 8129348 >> as well as issue 8193801 "Debugger hangs in trace mode for non-static >> methods". >> >> The changes include new tests for issues 8193879, 8193801 and 8129348. >> >> The changes in >> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >> solve the problem that the prompt is not printed in the debugger >> output when the breakpoint is hit and the suspend policy is >> SUSPEND_EVENT_THREAD. This is required for new tests to detect that >> command "stop thread at ..." is completed. >> >> Mach5 build and jdk_jdi tests succeeded. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >> >> Thanks, >> --Daniil >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Oct 9 03:54:55 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 8 Oct 2018 20:54:55 -0700 Subject: RFR (XS) 8211905: Remove multiple casts for EM06 file Message-ID: Hi all, Seems like there is an over-zealous casting in the file nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) NSK_CPP_STUB3(CallObjectMethod, jni_env, klass, This webrev fixes that: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211905/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211905 Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Oct 9 03:59:58 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 8 Oct 2018 20:59:58 -0700 Subject: RFR (XS) 8211905: Remove multiple casts for EM06 file In-Reply-To: References: Message-ID: <4ccac60e-f811-8eff-f06d-0e1e15b89b54@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Oct 9 04:21:30 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 8 Oct 2018 21:21:30 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] Message-ID: Hi all, I am continuing the NSK_CPP_STUB removal with this next webrev. Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 The change is still straight-forward though, since it is just doing the same NSK_CPP_STUB removal. However when I was looking at the changes, a lot of these changes are touching lines with spaces before/after parenthesis. I've almost never touched the spaces except if I was refactoring by hand the line at the same time. The rationale being that the lines will get fixed a few more times and are, at worse, covered by the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which I've commited to doing. Two exceptions are here where I pushed out the code into assignments due to really long lines and complex if structures: - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp And one exception here where a commented line was doing the out-of-if assignment so I just uncommented it and used the variable: - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp I've tested the modified changes on my machine, all modified tests pass. Let me know what you think, Jc Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Tue Oct 9 06:01:52 2018 From: jini.george at oracle.com (Jini George) Date: Tue, 9 Oct 2018 11:31:52 +0530 Subject: RFR: (S): JDK-8200613: SA: jstack throws UnmappedAddressException with a CDS core file Message-ID: <864997e5-2581-7ac9-44f7-76cc31c9ad93@oracle.com> Hello! [Including runtime-dev since the changes are in runtime code] Requesting reviews for: Webrev: http://cr.openjdk.java.net/~jgeorge/8200613/webrev.01/ BugID: https://bugs.openjdk.java.net/browse/JDK-8200613 Issue: jhsdb jstack would throw an UnmappedAddressException with a core file generated from a CDS enabled java process. This is seen only with Linux and with G1GC, while trying to read in data from the shared strings region (the closed archive heap space). This region (which is a file backed private memory region) is not dumped into the corefile for Linux. This, being a heap region (and therefore being a read-write region) is also not read in from the classes.jsa file in SA since only the read only regions are read in while processing the core file. (The expectation being that the read write regions are in the core file). Proposed solution: The proposed solution is to have the coredump_filter value corresponding to the CDS process to include bit 2 (file-backed private memory), so that the file-backed private memory region also gets dumped into the corefile. The proposed fix is in src/hotspot/os/linux/os_linux.cpp. Thanks, Jini. From chris.plummer at oracle.com Tue Oct 9 06:08:33 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 8 Oct 2018 23:08:33 -0700 Subject: RFR (XS) 8211905: Remove multiple casts for EM06 file In-Reply-To: References: Message-ID: <58cb869b-c020-fc2b-3618-676657867c0f@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Oct 9 06:14:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 Oct 2018 16:14:55 +1000 Subject: RFR (XS) 8211905: Remove multiple casts for EM06 file In-Reply-To: <58cb869b-c020-fc2b-3618-676657867c0f@oracle.com> References: <58cb869b-c020-fc2b-3618-676657867c0f@oracle.com> Message-ID: <1c459058-044a-6e8a-59b8-e519cac03d2a@oracle.com> On 9/10/2018 4:08 PM, Chris Plummer wrote: > Looks good. Any idea what caused it, other than it was introduced by > JDK-8209611? It wasn't in the original webrev for 8209611 (no cast at all) so I'm guessing it was a last minute change that somehow went awry. I wonder if compilers have a -Wunnecessary_cast warning that may have caught it ;-) David > Chris > > On 10/8/18 8:54 PM, JC Beyler wrote: >> Hi all, >> >> Seems like there is an over-zealous casting in the file >> nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: >> >> jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) >> (jstring) (jstring) (jstring) (jstring) >> NSK_CPP_STUB3(CallObjectMethod, jni_env, klass, >> >> This webrev fixes that: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211905/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211905 >> >> Thanks, >> Jc > > From gary.adams at oracle.com Tue Oct 9 11:39:25 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 09 Oct 2018 07:39:25 -0400 Subject: RFR: JDK-8211324: Link to java.lang.ThreadGroup in JDWP spec is broken In-Reply-To: <80efcf56-f799-a45f-bfb4-5102cbf40b49@oracle.com> References: <5BBB9EA6.9070209@oracle.com> <79723D43-5498-4360-A1C5-76AB2D122A5C@oracle.com> <80efcf56-f799-a45f-bfb4-5102cbf40b49@oracle.com> Message-ID: <5BBC936D.8090708@oracle.com> Patch attached. I'll need a sponsor for the push. On 10/8/18, 3:58 PM, serguei.spitsyn at oracle.com wrote: > Hi Gary, > > +1 > > Thanks, > Serguei > > On 10/8/18 11:30, Chris Hegarty wrote: >> The updated link looks ok to me. >> >> -Chris >> >>> On 8 Oct 2018, at 19:15, Gary Adams wrote: >>> >>> Alan suggested in the bug report for the broken link from the >>> jdwp-protocol >>> spec to the java/lang/ThreadGroup documentation to simply remove the >>> href link. Another possibility is to simply update the link to >>> include the java.base >>> subdirectory. >>> >>> I don't think the doc structure changes very often so either solution >>> seems fine to me. >>> >>> diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec >>> --- a/make/data/jdwp/jdwp.spec >>> +++ b/make/data/jdwp/jdwp.spec >>> @@ -2185,7 +2185,7 @@ >>> "in this thread group. Threads and thread groups in child " >>> "thread groups are not included. " >>> "A thread is alive if it has been started and has not yet >>> been stopped. " >>> - "See >> href=../../../api/java/lang/ThreadGroup.html>java.lang.ThreadGroup >>> + "See >> href=../../api/java.base/java/lang/ThreadGroup.html>java.lang.ThreadGroup >>> >>> "for information about active ThreadGroups. >>> (Out >>> (threadGroupObject group "The thread group object ID. ") > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 8211324.patch URL: From sgehwolf at redhat.com Tue Oct 9 15:50:30 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 09 Oct 2018 17:50:30 +0200 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <3bc104e0-9416-9e4f-abd3-168c9fdb2096@oracle.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> <3bc104e0-9416-9e4f-abd3-168c9fdb2096@oracle.com> Message-ID: <28c738264e871777d0301b69c91e7c717cbf1f2d.camel@redhat.com> Hi Seguei, On Mon, 2018-10-08 at 17:57 -0700, serguei.spitsyn at oracle.com wrote: > Hi Severin, > > You already fixed a couple of deadlocks in the debugger method > invocation and have an expertise in this area. > Do you have any time to review the webrev from Daniil? Sorry, not at the moment. It's also been a while since spelunking in that area. > Otherwise, I'd like to keep you aware about this fix. OK, thanks! I'll try to have a look at it post-push. Any particular reason why the bug is private? I don't seem to be able to view it: https://bugs.openjdk.java.net/browse/JDK-8193879 Thanks, Severin > Thanks, > Serguei > > > On 10/8/18 17:53, serguei.spitsyn at oracle.com wrote: > > Hi Daniil, > > > > It seems to me, this fix is going to work. > > > > The freeze() method only cares there are no pending resume > > commands: > > 99 synchronized void freeze() { > > 100 if (cache == null && > > (pendingResumeCommands.isEmpty())) { > > 101 /* > > 102 * No pending resumes to worry about. The VM is > > suspended > > 103 * and additional state can be cached. Notify all > > 104 * interested listeners. > > 105 */ > > 106 processVMAction(new VMAction(vm, > > VMAction.VM_SUSPENDED)); > > 107 enableCache(); > > 108 } > > 109 } > > With new version of the notifyCommandComplete: > > 95 void notifyCommandComplete(int id) { > > 96 pendingResumeCommands.remove(id); > > 97 } > > a pending resume command can be deleted from the > > pendingResumeCommands set. > > This does not matter if the collection is already empty. > > > > The only other place for a potential conflict is the method: > > 111 synchronized PacketStream thawCommand(CommandSender > > sender) { > > 112 PacketStream stream = sender.send(); > > 113 pendingResumeCommands.add(stream.id()); > > 114 thaw(); > > 115 return stream; > > 116 } > > However, there is no problem here as the pendingResumeCommands is a > > synchronized set. > > > > > > - return (BreakpointEvent)waitForRequestedEvent(request); > > + return (BreakpointEvent) waitForRequestedEvent(request); > > Not sure why have you added space after the cast. > > We should not have it by coding convention. > > Also, the local style does not have it as well. > > Examples are: > > 761 StepEvent retEvent = > > (StepEvent)waitForRequestedEvent(sr); > > 835 return (Location)locs.get(0); > > 873 return > > (ClassPrepareEvent)waitForRequestedEvent(request); > > > > Otherwise, it looks pretty good to me. > > No need in another webrev if you fix the above. > > > > Thanks, > > Serguei > > > > > > On 10/4/18 14:19, Daniil Titov wrote: > > > Hi Gary and Chris, > > > > > > Please review an updated version of the patch that has newly > > > added test for the case when suspend policy is set to > > > SUSPEND_EVENT_THREAD reimplemented using JDI API. Thus, the > > > changes in > > > src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.jav > > > a are no longer required. > > > > > > I think vmInterrupted() is not invoked when suspend policy is set > > > to SUSPEND_EVENT_THREAD to address the case when different > > > threads keep hitting the same breakpoint and to avoid the > > > switching the current thread in the background. > > > > > > The actual behavior of the debugger in the case when the > > > breakpoint is hit and suspend policy is set to > > > SUSPEND_EVENT_THREAD is just to print "Breakpoint hit:" in the > > > output without adding any additional information or new line > > > character. After that you need to set the current thread by > > > entering "thread" command , e.g. "thread 1" and only then jdb > > > prints the prompt (e.g. "main[1]") . The behavior looks as > > > confusing since it is not obvious for the user that some input is > > > expected from him (e.g. to set the current thread). I created a > > > separated issue for that at > > > https://bugs.openjdk.java.net/browse/JDK-8211736 . > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.02/ > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 > > > > > > Thanks, > > > --Daniil > > > > > > ?On 10/4/18, 10:28 AM, "Chris Plummer" > > > wrote: > > > > > > On 10/4/18 5:12 AM, Gary Adams wrote: > > > > In TTY.java do you need to force a simple prompt for the > > > > breakpoint event output? What prevents currentThread from > > > > being set at the time you are printing the prompt? > > > > > > > > > > > > 103 // Print the prompt if suspend policy is > > > > SUSPEND_EVENT_THREAD. In case of > > > > 104 // SUSPEND_ALL policy this is handled by > > > vmInterrupted() > > > > method. > > > > 105 if (be.request().suspendPolicy() == > > > > EventRequest.SUSPEND_EVENT_THREAD) { > > > > 106 MessageOutput.println(); > > > > 107 MessageOutput.printPrompt(); > > > Normally the thread is suspended after the above code is > > > executed: > > > > > > public void run() { > > > EventQueue queue = Env.vm().eventQueue(); > > > while (connected) { > > > try { > > > EventSet eventSet = queue.remove(); > > > boolean resumeStoppedApp = false; > > > EventIterator it = eventSet.eventIterator(); > > > while (it.hasNext()) { > > > resumeStoppedApp |= > > > !handleEvent(it.nextEvent()); > > > <--- calls the modified code above > > > } > > > > > > if (resumeStoppedApp) { > > > eventSet.resume(); > > > } else if (eventSet.suspendPolicy() == > > > EventRequest.SUSPEND_ALL) { > > > setCurrentThread(eventSet); <------ > > > notifier.vmInterrupted(); > > > } > > > > > > However, it only calls setCurrentThread() for SUSPEND_ALL > > > policies. So > > > what Daniil has done here is make it print a simple prompt if > > > the policy > > > is SUSPEND_EVENT_THREAD. It's unclear to me what the actual > > > debugger > > > behavior is in this case. Don't we still suspend and get a > > > prompt from > > > which we can type in the next command? In this case, wouldn't > > > you want a > > > full prompt? Related to that question, why is vmInterrupted() > > > only > > > called if we suspend all threads, and not when we just > > > suspend the > > > thread that the breakpoint came in on? > > > > > > Chris > > > > > > > > > > > > In Jdb.java you allow the waiting for the simple prompt. > > > > I don't see waitForSimplePrompt used in any existing tests. > > > > Since it is only looking for a single character it could > > > > produce false positives if the '>' was produced in the > > > > output stream. Is this wait paired to the added prompt for > > > the > > > > break point event? > > > > > > > > 236 return waitForSimplePrompt ? > > > waitForSimplePrompt(1, > > > > cmd.allowExit) : waitForPrompt(1, cmd.allowExit); > > > > > > > > It might be a good idea to include a test with multiple > > > > threads each with a breakpoint that will trigger > > > SUSPEND_EVENT_THREAD > > > > behavior. > > > > > > > > On 10/4/18, 12:29 AM, Daniil Titov wrote: > > > >> Please review the changes that fix the deadlock in the > > > debugger when > > > >> the debugger is running with the tracing option on. > > > >> > > > >> The problem here is that when the tracing is on the "JDI > > > Target VM > > > >> Interface" thread (the thread that reads all replies and > > > then > > > >> notifies the thread that sent the request that the reply > > > has been > > > >> received) is waiting for a lock which is already acquired > > > by the > > > >> thread that sent the request and is waiting for reply. > > > >> > > > >> The fix itself is in > > > >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. > > > >> > > > >> The patch also reverts the changes done in 8129348 > > > "Debugger hangs in > > > >> trace mode with TRACE_SENDS" in > > > >> > > > src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.jav > > > a > > > >> since they address only a specific case (VM is suspended > > > and static > > > >> method is invoked) while the proposed fix also solves > > > issue 8129348 > > > >> as well as issue 8193801 "Debugger hangs in trace mode for > > > non-static > > > >> methods". > > > >> > > > >> The changes include new tests for issues 8193879, 8193801 > > > and 8129348. > > > >> > > > >> The changes in > > > >> > > > src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.jav > > > a > > > >> solve the problem that the prompt is not printed in the > > > debugger > > > >> output when the breakpoint is hit and the suspend policy > > > is > > > >> SUSPEND_EVENT_THREAD. This is required for new tests to > > > detect that > > > >> command "stop thread at ..." is completed. > > > >> > > > >> Mach5 build and jdk_jdi tests succeeded. > > > >> > > > >> Webrev: > > > http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ > > > >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 > > > >> > > > >> Thanks, > > > >> --Daniil > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > From sharath.ballal at oracle.com Tue Oct 9 16:20:14 2018 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Tue, 9 Oct 2018 16:20:14 +0000 (UTC) Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file In-Reply-To: References: <8114c71e-8123-4be0-be9c-0c1bcddf773b@default> <07713e7d6f9b481d8b9a3570d97a2586@sap.com> <7ef145ac-4eb1-475f-822f-1dfb19ba7851@default> Message-ID: <05fe2b72-f555-47f8-b76a-00755c6a320b@default> Hi Goetz, Here is the webrev for the backport to jdk11u. http://cr.openjdk.java.net/~sballal/8207745/jdk_11u/webrev.00/ Tests are passing in Mach5 run. Thanks, Sharath -----Original Message----- From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] Sent: Thursday, October 04, 2018 12:51 PM To: Sharath Ballal; serviceability-dev Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file Hi Sharath, I don't think you need a bug for this. You need to flag the other bug with "fix-request" http://openjdk.java.net/projects/jdk-updates/approval.html But unfortunately we need a new review because the patch does not apply cleanly. Will you send the RFR? I could do the review. Best regards, Goetz. > -----Original Message----- > From: Sharath Ballal > Sent: Mittwoch, 3. Oktober 2018 08:03 > To: Lindenmaier, Goetz ; serviceability-dev > > Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > times out parsing a 4GB hprof file > > Hi Goetz, > > I have opened https://bugs.openjdk.java.net/browse/JDK-8211421 for the > backport. > > > Thanks, > Sharath > > > -----Original Message----- > From: Lindenmaier, Goetz [mailto:goetz.lindenmaier at sap.com] > Sent: Friday, September 28, 2018 8:41 PM > To: Sharath Ballal; serviceability-dev > Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > times out parsing a 4GB hprof file > > Hi Sharath, > > what do you think about bringing this fix to jdk11u? > We run the tests there regularly and see this problem, too. > > Best regards, > Goetz. > > > -----Original Message----- > > From: serviceability-dev > > > > On Behalf Of Sharath Ballal > > Sent: Montag, 24. September 2018 05:49 > > To: serviceability-dev > > Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java > > times out parsing a 4GB hprof file > > > > Hi, > > > > > > > > Pls review this test fix to add "-Xmx512m" to SA tests which create > > either core file or heap dump, to avoid timeout due to large heap sizes. > > > > > > > > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745 > > > > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/ > > > > > > > > > > SA tests passed on Mach5 run. > > > > > > > > Thanks, > > > > Sharath > > > > > > > > From serguei.spitsyn at oracle.com Tue Oct 9 17:01:20 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Oct 2018 10:01:20 -0700 Subject: RFR: JDK-8211324: Link to java.lang.ThreadGroup in JDWP spec is broken In-Reply-To: <5BBC936D.8090708@oracle.com> References: <5BBB9EA6.9070209@oracle.com> <79723D43-5498-4360-A1C5-76AB2D122A5C@oracle.com> <80efcf56-f799-a45f-bfb4-5102cbf40b49@oracle.com> <5BBC936D.8090708@oracle.com> Message-ID: <84f3ba75-f03e-8d18-db41-4db571b2b463@oracle.com> I'll push it. Thanks, Serguei On 10/9/18 4:39 AM, Gary Adams wrote: > Patch attached. > > I'll need a sponsor for the push. > > On 10/8/18, 3:58 PM, serguei.spitsyn at oracle.com wrote: >> Hi Gary, >> >> +1 >> >> Thanks, >> Serguei >> >> On 10/8/18 11:30, Chris Hegarty wrote: >>> The updated link looks ok to me. >>> >>> -Chris >>> >>>> On 8 Oct 2018, at 19:15, Gary Adams wrote: >>>> >>>> Alan suggested in the bug report for the broken link from the >>>> jdwp-protocol >>>> spec to the java/lang/ThreadGroup documentation to simply remove the >>>> href link. Another possibility is to simply update the link to >>>> include the java.base >>>> subdirectory. >>>> >>>> I don't think the doc structure changes very often so either solution >>>> seems fine to me. >>>> >>>> diff --git a/make/data/jdwp/jdwp.spec b/make/data/jdwp/jdwp.spec >>>> --- a/make/data/jdwp/jdwp.spec >>>> +++ b/make/data/jdwp/jdwp.spec >>>> @@ -2185,7 +2185,7 @@ >>>> ???????? "in this thread group. Threads and thread groups in child " >>>> ???????? "thread groups are not included. " >>>> ???????? "A thread is alive if it has been started and has not yet >>>> been stopped. " >>>> -??????? "See >>> href=../../../api/java/lang/ThreadGroup.html>java.lang.ThreadGroup >>>> >>>> +??????? "See >>> href=../../api/java.base/java/lang/ThreadGroup.html>java.lang.ThreadGroup >>>> >>>> ???????? "for information about active ThreadGroups. >>>> ???????? (Out >>>> ???????????? (threadGroupObject group "The thread group object ID. ") >> > From serguei.spitsyn at oracle.com Tue Oct 9 21:00:58 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 9 Oct 2018 14:00:58 -0700 Subject: RFR 8193879: Java debugger hangs on method invocation In-Reply-To: <28c738264e871777d0301b69c91e7c717cbf1f2d.camel@redhat.com> References: <0DCAA514-5188-4C97-B5F6-8FF37EDD3B1E@oracle.com> <5BB60397.7050807@oracle.com> <0383c7ba-0393-4cba-64de-5c450af2290a@oracle.com> <5197AE43-6372-42F0-AABE-1CBD675374F8@oracle.com> <0ef8b9f0-27fa-da97-b7c7-795661955603@oracle.com> <3bc104e0-9416-9e4f-abd3-168c9fdb2096@oracle.com> <28c738264e871777d0301b69c91e7c717cbf1f2d.camel@redhat.com> Message-ID: Hi Severin, On 10/9/18 8:50 AM, Severin Gehwolf wrote: > Hi Seguei, > > On Mon, 2018-10-08 at 17:57 -0700, serguei.spitsyn at oracle.com wrote: >> Hi Severin, >> >> You already fixed a couple of deadlocks in the debugger method >> invocation and have an expertise in this area. >> Do you have any time to review the webrev from Daniil? > Sorry, not at the moment. It's also been a while since spelunking in > that area. > >> Otherwise, I'd like to keep you aware about this fix. > OK, thanks! I'll try to have a look at it post-push. Okay, thanks! > Any particular reason why the bug is private? I don't seem to be able > to view it: > https://bugs.openjdk.java.net/browse/JDK-8193879 Most likely, it is because it is a shadow bug from the internal bug tracking system reflecting external support. These bugs are confidential by default. this bug was from JetBrains folks. If you want, I could send you the pieces you need separately. Thanks, Serguei > Thanks, > Severin > >> Thanks, >> Serguei >> >> >> On 10/8/18 17:53, serguei.spitsyn at oracle.com wrote: >>> Hi Daniil, >>> >>> It seems to me, this fix is going to work. >>> >>> The freeze() method only cares there are no pending resume >>> commands: >>> 99 synchronized void freeze() { >>> 100 if (cache == null && >>> (pendingResumeCommands.isEmpty())) { >>> 101 /* >>> 102 * No pending resumes to worry about. The VM is >>> suspended >>> 103 * and additional state can be cached. Notify all >>> 104 * interested listeners. >>> 105 */ >>> 106 processVMAction(new VMAction(vm, >>> VMAction.VM_SUSPENDED)); >>> 107 enableCache(); >>> 108 } >>> 109 } >>> With new version of the notifyCommandComplete: >>> 95 void notifyCommandComplete(int id) { >>> 96 pendingResumeCommands.remove(id); >>> 97 } >>> a pending resume command can be deleted from the >>> pendingResumeCommands set. >>> This does not matter if the collection is already empty. >>> >>> The only other place for a potential conflict is the method: >>> 111 synchronized PacketStream thawCommand(CommandSender >>> sender) { >>> 112 PacketStream stream = sender.send(); >>> 113 pendingResumeCommands.add(stream.id()); >>> 114 thaw(); >>> 115 return stream; >>> 116 } >>> However, there is no problem here as the pendingResumeCommands is a >>> synchronized set. >>> >>> >>> - return (BreakpointEvent)waitForRequestedEvent(request); >>> + return (BreakpointEvent) waitForRequestedEvent(request); >>> Not sure why have you added space after the cast. >>> We should not have it by coding convention. >>> Also, the local style does not have it as well. >>> Examples are: >>> 761 StepEvent retEvent = >>> (StepEvent)waitForRequestedEvent(sr); >>> 835 return (Location)locs.get(0); >>> 873 return >>> (ClassPrepareEvent)waitForRequestedEvent(request); >>> >>> Otherwise, it looks pretty good to me. >>> No need in another webrev if you fix the above. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/4/18 14:19, Daniil Titov wrote: >>>> Hi Gary and Chris, >>>> >>>> Please review an updated version of the patch that has newly >>>> added test for the case when suspend policy is set to >>>> SUSPEND_EVENT_THREAD reimplemented using JDI API. Thus, the >>>> changes in >>>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.jav >>>> a are no longer required. >>>> >>>> I think vmInterrupted() is not invoked when suspend policy is set >>>> to SUSPEND_EVENT_THREAD to address the case when different >>>> threads keep hitting the same breakpoint and to avoid the >>>> switching the current thread in the background. >>>> >>>> The actual behavior of the debugger in the case when the >>>> breakpoint is hit and suspend policy is set to >>>> SUSPEND_EVENT_THREAD is just to print "Breakpoint hit:" in the >>>> output without adding any additional information or new line >>>> character. After that you need to set the current thread by >>>> entering "thread" command , e.g. "thread 1" and only then jdb >>>> prints the prompt (e.g. "main[1]") . The behavior looks as >>>> confusing since it is not obvious for the user that some input is >>>> expected from him (e.g. to set the current thread). I created a >>>> separated issue for that at >>>> https://bugs.openjdk.java.net/browse/JDK-8211736 . >>>> >>>> Webrev: http://cr.openjdk.java.net/~dtitov/8193879/webrev.02/ >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >>>> >>>> Thanks, >>>> --Daniil >>>> >>>> ?On 10/4/18, 10:28 AM, "Chris Plummer" >>>> wrote: >>>> >>>> On 10/4/18 5:12 AM, Gary Adams wrote: >>>> > In TTY.java do you need to force a simple prompt for the >>>> > breakpoint event output? What prevents currentThread from >>>> > being set at the time you are printing the prompt? >>>> > >>>> > >>>> > 103 // Print the prompt if suspend policy is >>>> > SUSPEND_EVENT_THREAD. In case of >>>> > 104 // SUSPEND_ALL policy this is handled by >>>> vmInterrupted() >>>> > method. >>>> > 105 if (be.request().suspendPolicy() == >>>> > EventRequest.SUSPEND_EVENT_THREAD) { >>>> > 106 MessageOutput.println(); >>>> > 107 MessageOutput.printPrompt(); >>>> Normally the thread is suspended after the above code is >>>> executed: >>>> >>>> public void run() { >>>> EventQueue queue = Env.vm().eventQueue(); >>>> while (connected) { >>>> try { >>>> EventSet eventSet = queue.remove(); >>>> boolean resumeStoppedApp = false; >>>> EventIterator it = eventSet.eventIterator(); >>>> while (it.hasNext()) { >>>> resumeStoppedApp |= >>>> !handleEvent(it.nextEvent()); >>>> <--- calls the modified code above >>>> } >>>> >>>> if (resumeStoppedApp) { >>>> eventSet.resume(); >>>> } else if (eventSet.suspendPolicy() == >>>> EventRequest.SUSPEND_ALL) { >>>> setCurrentThread(eventSet); <------ >>>> notifier.vmInterrupted(); >>>> } >>>> >>>> However, it only calls setCurrentThread() for SUSPEND_ALL >>>> policies. So >>>> what Daniil has done here is make it print a simple prompt if >>>> the policy >>>> is SUSPEND_EVENT_THREAD. It's unclear to me what the actual >>>> debugger >>>> behavior is in this case. Don't we still suspend and get a >>>> prompt from >>>> which we can type in the next command? In this case, wouldn't >>>> you want a >>>> full prompt? Related to that question, why is vmInterrupted() >>>> only >>>> called if we suspend all threads, and not when we just >>>> suspend the >>>> thread that the breakpoint came in on? >>>> >>>> Chris >>>> > >>>> > >>>> > In Jdb.java you allow the waiting for the simple prompt. >>>> > I don't see waitForSimplePrompt used in any existing tests. >>>> > Since it is only looking for a single character it could >>>> > produce false positives if the '>' was produced in the >>>> > output stream. Is this wait paired to the added prompt for >>>> the >>>> > break point event? >>>> > >>>> > 236 return waitForSimplePrompt ? >>>> waitForSimplePrompt(1, >>>> > cmd.allowExit) : waitForPrompt(1, cmd.allowExit); >>>> > >>>> > It might be a good idea to include a test with multiple >>>> > threads each with a breakpoint that will trigger >>>> SUSPEND_EVENT_THREAD >>>> > behavior. >>>> > >>>> > On 10/4/18, 12:29 AM, Daniil Titov wrote: >>>> >> Please review the changes that fix the deadlock in the >>>> debugger when >>>> >> the debugger is running with the tracing option on. >>>> >> >>>> >> The problem here is that when the tracing is on the "JDI >>>> Target VM >>>> >> Interface" thread (the thread that reads all replies and >>>> then >>>> >> notifies the thread that sent the request that the reply >>>> has been >>>> >> received) is waiting for a lock which is already acquired >>>> by the >>>> >> thread that sent the request and is waiting for reply. >>>> >> >>>> >> The fix itself is in >>>> >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java. >>>> >> >>>> >> The patch also reverts the changes done in 8129348 >>>> "Debugger hangs in >>>> >> trace mode with TRACE_SENDS" in >>>> >> >>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.jav >>>> a >>>> >> since they address only a specific case (VM is suspended >>>> and static >>>> >> method is invoked) while the proposed fix also solves >>>> issue 8129348 >>>> >> as well as issue 8193801 "Debugger hangs in trace mode for >>>> non-static >>>> >> methods". >>>> >> >>>> >> The changes include new tests for issues 8193879, 8193801 >>>> and 8129348. >>>> >> >>>> >> The changes in >>>> >> >>>> src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.jav >>>> a >>>> >> solve the problem that the prompt is not printed in the >>>> debugger >>>> >> output when the breakpoint is hit and the suspend policy >>>> is >>>> >> SUSPEND_EVENT_THREAD. This is required for new tests to >>>> detect that >>>> >> command "stop thread at ..." is completed. >>>> >> >>>> >> Mach5 build and jdk_jdi tests succeeded. >>>> >> >>>> >> Webrev: >>>> http://cr.openjdk.java.net/~dtitov/8193879/webrev.01/ >>>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8193879 >>>> >> >>>> >> Thanks, >>>> >> --Daniil >>>> >> >>>> >> >>>> >> >>>> > >>>> >>>> >>>> >>>> >>> >> From jcbeyler at google.com Tue Oct 9 21:22:13 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 9 Oct 2018 14:22:13 -0700 Subject: RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp Message-ID: Hi all, When I pushed the fix for JDK-8210842 , I failed to realize there was seemingly an issue when using std::string. This provoked a failure for Windows and Solaris builds described in the bug for this fix. Therefore I offer a solution using const char* instead to not have any issues: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211432 The incremental between the previous fix and this one is here so that it helps see the differences: http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.inc/ Finally, this has passed the submit-repo smoke-screen. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Tue Oct 9 22:54:25 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 9 Oct 2018 22:54:25 +0000 Subject: RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp In-Reply-To: References: Message-ID: <36AC2419-0ABA-4012-B9D9-687660053443@amazon.com> Is the pointer itself constant? I.e., ?const char* const base_msg?? Paul From: serviceability-dev on behalf of JC Beyler Date: Tuesday, October 9, 2018 at 5:23 PM To: "serviceability-dev at openjdk.java.net" Subject: RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp Hi all, When I pushed the fix for JDK-8210842, I failed to realize there was seemingly an issue when using std::string. This provoked a failure for Windows and Solaris builds described in the bug for this fix. Therefore I offer a solution using const char* instead to not have any issues: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211432 The incremental between the previous fix and this one is here so that it helps see the differences: http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.inc/ Finally, this has passed the submit-repo smoke-screen. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Oct 9 23:09:36 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 9 Oct 2018 16:09:36 -0700 Subject: RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp In-Reply-To: <36AC2419-0ABA-4012-B9D9-687660053443@amazon.com> References: <36AC2419-0ABA-4012-B9D9-687660053443@amazon.com> Message-ID: Hi Paul, Yes base_msg can be doubly const so I did that in my local version. I'll push a new webrev once I get more reviews :) Thanks! Jc On Tue, Oct 9, 2018 at 3:54 PM Hohensee, Paul wrote: > Is the pointer itself constant? I.e., ?const char* const base_msg?? > > > > Paul > > > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Tuesday, October 9, 2018 at 5:23 PM > *To: *"serviceability-dev at openjdk.java.net" < > serviceability-dev at openjdk.java.net> > *Subject: *RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp > > > > Hi all, > > > > When I pushed the fix for JDK-8210842 > , I failed to realize > there was seemingly an issue when using std::string. This provoked a > failure for Windows and Solaris builds described in the bug for this fix. > > > > Therefore I offer a solution using const char* instead to not have any > issues: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211432 > > > > The incremental between the previous fix and this one is here so that it > helps see the differences: > > http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.inc/ > > > > Finally, this has passed the submit-repo smoke-screen. > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Oct 10 03:57:45 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 9 Oct 2018 20:57:45 -0700 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods Message-ID: Hi all, When talking with Serguei about JDK-8201655 , we talked about why ThreadHeapSampler has an enabled/disabled when we could have just used the should_post_sampled_object_alloc to begin with. Could I get a review for this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 This passed my testing on my dev machine in release and fastdebug. The question I would like to raise here at the same time (in order to reduce email spam and because it should be included in the review I believe) is: - When I did the enable/disable, I used OrderAccess to do so after a reviewer asked for it - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and does instead: #define JVMTI_SUPPORT_FLAG(key) \ private: \ static bool _##key; \ public: \ inline static void set_##key(bool on) { \ JVMTI_ONLY(_##key = (on != 0)); \ NOT_JVMTI(report_unsupported(on)); \ } \ inline static bool key() { \ JVMTI_ONLY(return _##key); \ NOT_JVMTI(return false); \ } Should it (ie in a future bug/webrev)? Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Wed Oct 10 17:10:29 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 10 Oct 2018 17:10:29 +0000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: References: Message-ID: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> There used to be a rule against using ?namespace?. Don?t know if that?s still true or not: I believe it is. Hence the ?static const ?. You only need OrderAccess if there could be a race on accesses to whatever you?re guarding. Looks like the old code wanted to make sure that log_table was initialized and its content available to other threads before the _enabled flag was set. I.e., the _enabled flag acted as a store visibility barrier for log_table, and possibly other ThreadHeapSampler data structures. If no thread can ever see a partially initialized log_table, then no need for ordering. The old code used a MutexLocker in init_log_table(), which former has a fence in its destructor and probably (haven?t dived into the code) guards all accesses to log_table, so the release_store() on _enabled in enable() was redundant. Same with the release_store() in disable(), unless there was some reason to make sure all threads saw previous stores to ThreadHeapSampler related memory before _enabled was set to zero. The load_acquire in enabled() may not have been needed either, because it only prevents subsequent loads from being executed before the load from _enabled, so if _enabled was being used to guard access only to ThreadHeapSampler data such as log_table, the release_store() on _enabled would guarantee that all necessary stores would be done before _enabled was set to one and seen by enabled(). Yeah, that?s hard to follow, and I wrote it. :) It comes down to what you?re guarding with OrderAccess. If it?s only ThreadHeapSampler data, and since only a Thread has one, and since ThreadHeapSampler statics are initialized before construction of the first _heap_sampler, and since the construction of a Thread is guarded by multiple mutexes which will force visibility of any ThreadHeapSampler statics before a Thread is used, you don?t need OrderAccess. I?d put anything to do with ThreadHeapSampler into its class definition rather than define them at file scope in threadHeapSampler.cpp. I.e., all of FastLogNumBits, FastLogMask, and internal_log_table (and name it back to that log_table). File scope data is a no-no. Hope this helps, Paul From: serviceability-dev on behalf of JC Beyler Date: Tuesday, October 9, 2018 at 11:58 PM To: "serviceability-dev at openjdk.java.net" Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods Hi all, When talking with Serguei about JDK-8201655, we talked about why ThreadHeapSampler has an enabled/disabled when we could have just used the should_post_sampled_object_alloc to begin with. Could I get a review for this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 This passed my testing on my dev machine in release and fastdebug. The question I would like to raise here at the same time (in order to reduce email spam and because it should be included in the review I believe) is: - When I did the enable/disable, I used OrderAccess to do so after a reviewer asked for it - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and does instead: #define JVMTI_SUPPORT_FLAG(key) \ private: \ static bool _##key; \ public: \ inline static void set_##key(bool on) { \ JVMTI_ONLY(_##key = (on != 0)); \ NOT_JVMTI(report_unsupported(on)); \ } \ inline static bool key() { \ JVMTI_ONLY(return _##key); \ NOT_JVMTI(return false); \ } Should it (ie in a future bug/webrev)? Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Oct 10 17:21:43 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 10 Oct 2018 10:21:43 -0700 Subject: RFR (XL) 8211801: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[A-E] In-Reply-To: <13ff4afa-34d9-1168-53d6-666ca9b524db@oracle.com> References: <13ff4afa-34d9-1168-53d6-666ca9b524db@oracle.com> Message-ID: +1 --alex On 10/08/2018 15:31, serguei.spitsyn at oracle.com wrote: > Hi Jc, > > Thank you for the update! > It looks good to me. > > Thanks, > Serguei > > > On 10/8/18 14:53, JC Beyler wrote: >> Hi Serguei, >> >> Normally, I try not to fix issues that already exist before the >> change. For the space after the NULL for example, that would get fixed >> by https://bugs.openjdk.java.net/browse/JDK-8211335. In this case, >> these are the only cases where this happens with a NULL so I fixed them. >> >> For the space missing before jvmti->X, I fixed my script to handle >> this correctly and add them automatically. >> >> Here is the new webrev: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211801/webrev.01 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211801 >> >> Thanks for the review! >> Jc >> >> On Mon, Oct 8, 2018 at 12:46 AM serguei.spitsyn at oracle.com >> > > wrote: >> >> Hi Jc, >> >> >> http://cr.openjdk.java.net/%7Ejcbeyler/8211801/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.cpp.udiff.html >> >> if (!NSK_JNI_VERIFY(jni, (fid = >> - NSK_CPP_STUB4(GetStaticFieldID, jni, >> - debugeeClass, >> - "thread", >> - THREAD_CLS_SIGNATURE)) != NULL )) { >> + jni->GetStaticFieldID(debugeeClass, "thread", >> THREAD_CLS_SIGNATURE)) != NULL )) { >> nsk_jvmti_setFailStatus(); >> break; >> } >> >> if (!NSK_JNI_VERIFY(jni, (localRefThread = >> - NSK_CPP_STUB3(GetStaticObjectField, jni, >> - debugeeClass, >> - fid )) != NULL )) { >> + jni->GetStaticObjectField(debugeeClass, fid)) != NULL )) { >> NSK_COMPLAIN0("GetStaticObjectField returned NULL for 'thread' field value\n\n"); >> nsk_jvmti_setFailStatus(); >> break; >> } >> >> Could you, please, remove extra space after NULL. >> >> >> In many-many files (especially, in the foleder: scenarios/capability): >> >> + if >> (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->SuspendThread(thread))) >> ... + if >> (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->ResumeThread(thread))) >> ... + if >> (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->InterruptThread(thread))) >> >> >> There are a lot of cases like above where a space before jvmti-> >> is missed. >> >> >> Otherwise, looks good. >> >> >> Thanks! >> Serguei >> >> >> On 10/5/18 16:50, JC Beyler wrote: >>> Hi all, >>> >>> I continued the NSK_CPP_STUB removal with this next webrev. >>> >>> My apologies, this one is big for 50 files; I can further cut it >>> up if we prefer. It is straight-forward though, since it is just >>> doing the same NSK_CPP_STUB removal. >>> >>> Without further ado: >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211801/webrev.00/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211801 >>> >>> This does another 50 file batch. I did the same for >>> https://bugs.openjdk.java.net/browse/JDK-8211782 so the scripts >>> can be found there (and added a comment in this bug to link to that). >>> >>> I've tested the modified changes on my machine, all modified >>> tests pass. >>> >>> Let me know what you think, >>> Jc >> >> >> >> -- >> >> Thanks, >> Jc > From jcbeyler at google.com Wed Oct 10 18:00:38 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 10 Oct 2018 11:00:38 -0700 Subject: RFR (XL) 8211801: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[A-E] In-Reply-To: References: <13ff4afa-34d9-1168-53d6-666ca9b524db@oracle.com> Message-ID: Thanks both for the reviews :) Jc On Wed, Oct 10, 2018 at 10:21 AM Alex Menkov wrote: > +1 > > --alex > > On 10/08/2018 15:31, serguei.spitsyn at oracle.com wrote: > > Hi Jc, > > > > Thank you for the update! > > It looks good to me. > > > > Thanks, > > Serguei > > > > > > On 10/8/18 14:53, JC Beyler wrote: > >> Hi Serguei, > >> > >> Normally, I try not to fix issues that already exist before the > >> change. For the space after the NULL for example, that would get fixed > >> by https://bugs.openjdk.java.net/browse/JDK-8211335. In this case, > >> these are the only cases where this happens with a NULL so I fixed them. > >> > >> For the space missing before jvmti->X, I fixed my script to handle > >> this correctly and add them automatically. > >> > >> Here is the new webrev: > >> > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211801/webrev.01 > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211801 > >> > >> Thanks for the review! > >> Jc > >> > >> On Mon, Oct 8, 2018 at 12:46 AM serguei.spitsyn at oracle.com > >> >> > wrote: > >> > >> Hi Jc, > >> > >> > >> > http://cr.openjdk.java.net/%7Ejcbeyler/8211801/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP06/ap06t001/ap06t001.cpp.udiff.html > >> > >> if (!NSK_JNI_VERIFY(jni, (fid = > >> - NSK_CPP_STUB4(GetStaticFieldID, jni, > >> - debugeeClass, > >> - "thread", > >> - THREAD_CLS_SIGNATURE)) != NULL )) { > >> + jni->GetStaticFieldID(debugeeClass, "thread", > >> THREAD_CLS_SIGNATURE)) != NULL )) { > >> nsk_jvmti_setFailStatus(); > >> break; > >> } > >> > >> if (!NSK_JNI_VERIFY(jni, (localRefThread = > >> - NSK_CPP_STUB3(GetStaticObjectField, jni, > >> - debugeeClass, > >> - fid )) != NULL )) { > >> + jni->GetStaticObjectField(debugeeClass, fid)) != NULL )) { > >> NSK_COMPLAIN0("GetStaticObjectField returned NULL for > 'thread' field value\n\n"); > >> nsk_jvmti_setFailStatus(); > >> break; > >> } > >> > >> Could you, please, remove extra space after NULL. > >> > >> > >> In many-many files (especially, in the foleder: > scenarios/capability): > >> > >> + if > >> > (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->SuspendThread(thread))) > >> ... + if > >> > (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->ResumeThread(thread))) > >> ... + if > >> > (!NSK_JVMTI_VERIFY_CODE(JVMTI_ERROR_MUST_POSSESS_CAPABILITY,jvmti->InterruptThread(thread))) > >> > >> > >> There are a lot of cases like above where a space before jvmti-> > >> is missed. > >> > >> > >> Otherwise, looks good. > >> > >> > >> Thanks! > >> Serguei > >> > >> > >> On 10/5/18 16:50, JC Beyler wrote: > >>> Hi all, > >>> > >>> I continued the NSK_CPP_STUB removal with this next webrev. > >>> > >>> My apologies, this one is big for 50 files; I can further cut it > >>> up if we prefer. It is straight-forward though, since it is just > >>> doing the same NSK_CPP_STUB removal. > >>> > >>> Without further ado: > >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8211801/webrev.00/ > >>> > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8211801 > >>> > >>> This does another 50 file batch. I did the same for > >>> https://bugs.openjdk.java.net/browse/JDK-8211782 so the scripts > >>> can be found there (and added a comment in this bug to link to > that). > >>> > >>> I've tested the modified changes on my machine, all modified > >>> tests pass. > >>> > >>> Let me know what you think, > >>> Jc > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Oct 10 19:10:55 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 10 Oct 2018 12:10:55 -0700 Subject: RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <36AC2419-0ABA-4012-B9D9-687660053443@amazon.com> Message-ID: Looks good. --alex On 10/09/2018 16:09, JC Beyler wrote: > Hi Paul, > > Yes base_msg can be doubly const so I did that in my local version. I'll > push a new webrev once I get more reviews :) > > Thanks! > Jc > > On Tue, Oct 9, 2018 at 3:54 PM Hohensee, Paul > wrote: > > Is the pointer itself constant? I.e., ?const char* const base_msg??____ > > __ __ > > Paul____ > > __ __ > > *From: *serviceability-dev > > on behalf of > JC Beyler > > *Date: *Tuesday, October 9, 2018 at 5:23 PM > *To: *"serviceability-dev at openjdk.java.net > " > > > *Subject: *RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp____ > > __ __ > > Hi all, ____ > > __ __ > > When I pushed the fix for JDK-8210842 > , I failed to > realize there was seemingly an issue when using std::string. This > provoked a failure for Windows and Solaris builds described in the > bug for this fix.____ > > __ __ > > Therefore I offer a solution using const char* instead to not have > any issues: > ____ > > __ __ > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.00/ > ____ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211432____ > > __ __ > > The incremental between the previous fix and this one is here so > that it helps see the differences:____ > > http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.inc/ > ____ > > __ __ > > Finally, this has passed the submit-repo smoke-screen.____ > > __ __ > > Thanks,____ > > Jc____ > > > > -- > > Thanks, > Jc From serguei.spitsyn at oracle.com Wed Oct 10 19:27:32 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 10 Oct 2018 12:27:32 -0700 Subject: RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp In-Reply-To: References: <36AC2419-0ABA-4012-B9D9-687660053443@amazon.com> Message-ID: Hi Jc, +1 Thanks, Serguei On 10/10/18 12:10, Alex Menkov wrote: > Looks good. > > --alex > > On 10/09/2018 16:09, JC Beyler wrote: >> Hi Paul, >> >> Yes base_msg can be doubly const so I did that in my local version. >> I'll push a new webrev once I get more reviews :) >> >> Thanks! >> Jc >> >> On Tue, Oct 9, 2018 at 3:54 PM Hohensee, Paul > > wrote: >> >> ??? Is the pointer itself constant? I.e., ?const char* const >> base_msg??____ >> >> ??? __ __ >> >> ??? Paul____ >> >> ??? __ __ >> >> ??? *From: *serviceability-dev >> ??? > > on behalf of >> ??? JC Beyler > >> ??? *Date: *Tuesday, October 9, 2018 at 5:23 PM >> ??? *To: *"serviceability-dev at openjdk.java.net >> ??? " >> ??? > ??? > >> ??? *Subject: *RFR (S) 8211432: [REDO] Handle JNIGlobalRefLocker.cpp____ >> >> ??? __ __ >> >> ??? Hi all, ____ >> >> ??? __ __ >> >> ??? When I pushed the fix for JDK-8210842 >> ??? , I failed to >> ??? realize there was seemingly an issue when using std::string. This >> ??? provoked a failure for Windows and Solaris builds described in the >> ??? bug for this fix.____ >> >> ??? __ __ >> >> ??? Therefore I offer a solution using const char* instead to not have >> ??? any issues: >> ??? ____ >> >> ??? __ __ >> >> ??? Webrev: http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.00/ >> ____ >> >> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8211432____ >> >> ??? __ __ >> >> ??? The incremental between the previous fix and this one is here so >> ??? that it helps see the differences:____ >> >> ??? http://cr.openjdk.java.net/~jcbeyler/8211432/webrev.inc/ >> ____ >> >> ??? __ __ >> >> ??? Finally, this has passed the submit-repo smoke-screen.____ >> >> ??? __ __ >> >> ??? Thanks,____ >> >> ??? Jc____ >> >> >> >> -- >> >> Thanks, >> Jc From jcbeyler at google.com Wed Oct 10 20:19:34 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 10 Oct 2018 13:19:34 -0700 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> Message-ID: Hi Paul, Thanks for the detailed answer. I also moved everything into the class now to not have anything static outside anymore as you requested. Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 Just a few more notes on the webrev: - I need to get that table initialized and I don't want to check if it is initialized during runtime, I want to "assume" it is in the normal code path; previously this was easy since I piggy-backed in the enable method to do it there - With what you are saying in the ordering you are right but the only way I can do an initialization of an array via a method seems to be to at least set one static member of the class, I've put a boolean instead to be set to true However, for the OrderAccess conversation, the conversation I had when I did this was that if you know it thread A can set a variable and thread B can get a variable, we should be using an OrderAccess and not assume that it "does not matter" that a thread gets a stale value. Because of that, I added them for ThreadHeapSampler but it seems that the JVMTI code I showed above does not do this. However, I can very well imagine a case where one thread calls SetEventNotification while another thread is doing some sort of work and trying to do get a value from one of those flags. Or perhaps there is an implicit ordering being done somewhere that I'm not aware of. Am I missing something? Thanks, Jc On Wed, Oct 10, 2018 at 10:10 AM Hohensee, Paul wrote: > There used to be a rule against using ?namespace?. Don?t know if that?s > still true or not: I believe it is. Hence the ?static const ?. > > > > You only need OrderAccess if there could be a race on accesses to whatever > you?re guarding. Looks like the old code wanted to make sure that log_table > was initialized and its content available to other threads before the > _enabled flag was set. I.e., the _enabled flag acted as a store visibility > barrier for log_table, and possibly other ThreadHeapSampler data > structures. If no thread can ever see a partially initialized log_table, > then no need for ordering. The old code used a MutexLocker in > init_log_table(), which former has a fence in its destructor and probably > (haven?t dived into the code) guards all accesses to log_table, so the > release_store() on _enabled in enable() was redundant. Same with the > release_store() in disable(), unless there was some reason to make sure all > threads saw previous stores to ThreadHeapSampler related memory before > _enabled was set to zero. The load_acquire in enabled() may not have been > needed either, because it only prevents subsequent loads from being > executed before the load from _enabled, so if _enabled was being used to > guard access only to ThreadHeapSampler data such as log_table, the > release_store() on _enabled would guarantee that all necessary stores would > be done before _enabled was set to one and seen by enabled(). > > > > Yeah, that?s hard to follow, and I wrote it. :) It comes down to what > you?re guarding with OrderAccess. If it?s only ThreadHeapSampler data, and > since only a Thread has one, and since ThreadHeapSampler statics are > initialized before construction of the first _heap_sampler, and since the > construction of a Thread is guarded by multiple mutexes which will force > visibility of any ThreadHeapSampler statics before a Thread is used, you > don?t need OrderAccess. > > > > I?d put anything to do with ThreadHeapSampler into its class definition > rather than define them at file scope in threadHeapSampler.cpp. I.e., all > of FastLogNumBits, FastLogMask, and internal_log_table (and name it back to > that log_table). File scope data is a no-no. > > > > Hope this helps, > > > > Paul > > > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Tuesday, October 9, 2018 at 11:58 PM > *To: *"serviceability-dev at openjdk.java.net" < > serviceability-dev at openjdk.java.net> > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > enable/disable/enabled methods > > > > Hi all, > > > > When talking with Serguei about JDK-8201655 > , we talked about why > ThreadHeapSampler has an enabled/disabled when we could have just used the > should_post_sampled_object_alloc to begin with. > > > > Could I get a review for this: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > > > This passed my testing on my dev machine in release and fastdebug. > > > > The question I would like to raise here at the same time (in order to > reduce email spam and because it should be included in the review I > believe) is: > > - When I did the enable/disable, I used OrderAccess to do so after a > reviewer asked for it > > > > - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and does > instead: > > > > #define JVMTI_SUPPORT_FLAG(key) \ > > private: \ > > static bool _##key; \ > > public: \ > > inline static void set_##key(bool on) { \ > > JVMTI_ONLY(_##key = (on != 0)); \ > > NOT_JVMTI(report_unsupported(on)); \ > > } \ > > inline static bool key() { \ > > JVMTI_ONLY(return _##key); \ > > NOT_JVMTI(return false); \ > > } > > > > Should it (ie in a future bug/webrev)? > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Oct 10 23:22:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Oct 2018 09:22:07 +1000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> Message-ID: <9da04935-5c78-1db7-34fe-255cd342963e@oracle.com> On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > There used to be a rule against using ?namespace?. Don?t know if that?s > still true or not: I believe it is. Hence the ?static const ?. Namespaces are used in a number of places now. There is still a prohibition on "using namespace ...". David > You only need OrderAccess if there could be a race on accesses to > whatever you?re guarding. Looks like the old code wanted to make sure > that log_table was initialized and its content available to other > threads before the _enabled flag was set. I.e., the _enabled flag acted > as a store visibility barrier for log_table, and possibly other > ThreadHeapSampler data structures. If no thread can ever see a partially > initialized log_table, then no need for ordering. The old code used a > MutexLocker in init_log_table(), which former has a fence in its > destructor and probably (haven?t dived into the code) guards all > accesses to log_table, so the release_store() on _enabled in enable() > was redundant. Same with the release_store() in disable(), unless there > was some reason to make sure all threads saw previous stores to > ThreadHeapSampler related memory before _enabled was set to zero. The > load_acquire in enabled() may not have been needed either, because it > only prevents subsequent loads from being executed before the load from > _enabled, so if _enabled was being used to guard access only to > ThreadHeapSampler data such as log_table, the release_store() on > _enabled would guarantee that all necessary stores would be done before > _enabled was set to one and seen by enabled(). > > Yeah, that?s hard to follow, and I wrote it. :) It comes down to what > you?re guarding with OrderAccess. If it?s only ThreadHeapSampler data, > and since only a Thread has one, and since ThreadHeapSampler statics are > initialized before construction of the first _heap_sampler, and since > the construction of a Thread is guarded by multiple mutexes which will > force visibility of any ThreadHeapSampler statics before a Thread is > used, you don?t need OrderAccess. > > I?d put anything to do with ThreadHeapSampler into its class definition > rather than define them at file scope in threadHeapSampler.cpp. I.e., > all of FastLogNumBits, FastLogMask, and internal_log_table (and name it > back to that log_table). File scope data is a no-no. > > Hope this helps, > > Paul > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Tuesday, October 9, 2018 at 11:58 PM > *To: *"serviceability-dev at openjdk.java.net" > > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > enable/disable/enabled methods > > Hi all, > > When talking with Serguei about JDK-8201655 > , we talked about why > ThreadHeapSampler has an enabled/disabled when we could have just used > the should_post_sampled_object_alloc to begin with. > > Could I get a review for this: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > This passed my testing on my dev machine in release and fastdebug. > > The question I would like to raise here at the same time (in order to > reduce email spam and because it should be included in the review I > believe) is: > > ? - When I did the enable/disable, I used OrderAccess to do so after a > reviewer asked for it > > ? - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and does > instead: > > #define JVMTI_SUPPORT_FLAG(key)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? private:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? static bool? _##key;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? public:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? inline static void set_##key(bool on) {? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? ? JVMTI_ONLY(_##key = (on != 0));? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? ? NOT_JVMTI(report_unsupported(on));? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? }? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? inline static bool key() {? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? ? JVMTI_ONLY(return _##key);? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? ? NOT_JVMTI(return false);? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? } > > Should it (ie in a future bug/webrev)? > > Thanks, > > Jc > From alexey.menkov at oracle.com Wed Oct 10 23:25:26 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 10 Oct 2018 16:25:26 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' Message-ID: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> Hi all, please review a fix for https://bugs.openjdk.java.net/browse/JDK-8195703 webrev: http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ I was not able to reproduce the issue, but accordingly the logs in jira root cause is a transport initialization error "Address already in use". The test uses Utils.getFreePort() to select some free port, but it can be race condition when some other app (or other test) uses the port selected before debuggee application starts to listen on it. The fix uses dynamic port allocation and then parses it from the debuggee output. Other changes: - dropped catching exceptions and calling System.exit() - this causes SecurityException in JTReg harness which makes error analysis much harder; - dropped using of Utils.getFreePort() from jdi/DoubleAgentTest.java test; jdi/BadHandshakeTest.java also uses Utils.getFreePort(), but it handles "Already in use" error re-peeking other free port and restarting debuggee, so I keep it as is. --alex From serguei.spitsyn at oracle.com Thu Oct 11 00:17:56 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 10 Oct 2018 17:17:56 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> Message-ID: <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> Hi Alex, It looks good to me. How did you test it? Thanks, Serguei On 10/10/18 16:25, Alex Menkov wrote: > Hi all, > > please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8195703 > webrev: > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ > > I was not able to reproduce the issue, but accordingly the logs in > jira root cause is a transport initialization error "Address already > in use". > The test uses Utils.getFreePort() to select some free port, but it can > be race condition when some other app (or other test) uses the port > selected before debuggee application starts to listen on it. > The fix uses dynamic port allocation and then parses it from the > debuggee output. > Other changes: > - dropped catching exceptions and calling System.exit() - this causes > SecurityException in JTReg harness which makes error analysis much > harder; > - dropped using of Utils.getFreePort() from jdi/DoubleAgentTest.java > test; > ? jdi/BadHandshakeTest.java also uses Utils.getFreePort(), but it > handles "Already in use" error re-peeking other free port and > restarting debuggee, so I keep it as is. > > --alex > From alexey.menkov at oracle.com Thu Oct 11 00:40:03 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 10 Oct 2018 17:40:03 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: References: Message-ID: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> Hi Jc, Overall looks good. one minor note: test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: - jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) NSK_CPP_STUB3(CallObjectMethod, jni_env, klass, - methodID); + jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) (jstring) jni_env->CallObjectMethod(klass, methodID); Please drop multi "(jstring)" --alex On 10/08/2018 21:21, JC Beyler wrote: > Hi all, > > I am continuing the NSK_CPP_STUB removal with this next webrev. > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 > > The change is still straight-forward though, since it is just doing the > same NSK_CPP_STUB removal. However when I was looking at the changes, a > lot of these changes are touching lines with spaces before/after > parenthesis. I've almost never touched the spaces except if I was > refactoring by hand the line at the same time. The rationale being that > the lines will get fixed a few more times and are, at worse, covered by > the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which I've > commited to doing. > > Two exceptions are here where I pushed out the code into assignments due > to really long lines and complex if structures: > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp > > - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp > > > And one exception here where a commented line was doing the out-of-if > assignment so I just uncommented it and used the variable: > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp > > > I've tested the modified changes on my machine, all modified tests pass. > > Let me know what you think, > Jc > > Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* > From jcbeyler at google.com Thu Oct 11 02:03:50 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 10 Oct 2018 19:03:50 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> Message-ID: Hi Alex, Thanks for the review! Yes I had seen that too before sending this review out and forked that fix into this: https://bugs.openjdk.java.net/browse/JDK-8211905 Which now is merged and I've updated my webrev to reflect this of course. My rationale for not doing it here directly is always the same: keeping the changes to the "spirit" of what the change is trying to do. Those extra casts were a bit out-of-scope and so I just forked the fix in 8211905. Thanks! Jc On Wed, Oct 10, 2018 at 5:40 PM Alex Menkov wrote: > Hi Jc, > > Overall looks good. > > one minor note: > > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: > - jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > (jstring) (jstring) (jstring) (jstring) NSK_CPP_STUB3(CallObjectMethod, > jni_env, klass, > - methodID); > + jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > (jstring) (jstring) (jstring) (jstring) jni_env->CallObjectMethod(klass, > methodID); > > Please drop multi "(jstring)" > > --alex > > On 10/08/2018 21:21, JC Beyler wrote: > > Hi all, > > > > I am continuing the NSK_CPP_STUB removal with this next webrev. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 > > > > The change is still straight-forward though, since it is just doing the > > same NSK_CPP_STUB removal. However when I was looking at the changes, a > > lot of these changes are touching lines with spaces before/after > > parenthesis. I've almost never touched the spaces except if I was > > refactoring by hand the line at the same time. The rationale being that > > the lines will get fixed a few more times and are, at worse, covered by > > the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which I've > > commited to doing. > > > > Two exceptions are here where I pushed out the code into assignments due > > to really long lines and complex if structures: > > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp.udiff.html > > > > - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp.udiff.html > > > > > > And one exception here where a commented line was doing the out-of-if > > assignment so I just uncommented it and used the variable: > > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp.udiff.html > > > > > > I've tested the modified changes on my machine, all modified tests pass. > > > > Let me know what you think, > > Jc > > > > Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Oct 11 02:19:26 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 10 Oct 2018 19:19:26 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> Message-ID: Hi Alex, - http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html -> Why not make it javadoc like the other methods of the same file (so @return instead of returns and a second * at the start of the comment)? - http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html a) I'm surprised by this: + int res;+ try {+ res = handshake(detectPort(a.getProcessStdout()));+ } finally { a.stopApp();+ } if (res < 0) { I would have thought that this makes javac return a "res might not be initialized" error. b) Nit: Is there a reason we are complicating the code here: try { LingeredApp a = LingeredApp.startApp(cmd);++ // startApp is expected to fail, but if not, terminate the app+ try {+ a.stopApp();+ } catch (IOException e) {+ // print and let the test fail+ System.err.println("LingeredApp.stopApp failed");+ e.printStackTrace();+ } } catch (IOException ex) { System.err.println(testName + ": caught expected IOException"); System.err.println(testName + " PASSED"); return; } Why not just put it below? We could either put a outside the try and then move that code out; or perhaps move it into a separate method to let the reader concentrate on the test at hand and let the "stopping of the app" happen somewhere else? Thanks, Jc On Wed, Oct 10, 2018 at 5:18 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Alex, > > It looks good to me. > How did you test it? > > Thanks, > Serguei > > > On 10/10/18 16:25, Alex Menkov wrote: > > Hi all, > > > > please review a fix for > > https://bugs.openjdk.java.net/browse/JDK-8195703 > > webrev: > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ > > > > I was not able to reproduce the issue, but accordingly the logs in > > jira root cause is a transport initialization error "Address already > > in use". > > The test uses Utils.getFreePort() to select some free port, but it can > > be race condition when some other app (or other test) uses the port > > selected before debuggee application starts to listen on it. > > The fix uses dynamic port allocation and then parses it from the > > debuggee output. > > Other changes: > > - dropped catching exceptions and calling System.exit() - this causes > > SecurityException in JTReg harness which makes error analysis much > > harder; > > - dropped using of Utils.getFreePort() from jdi/DoubleAgentTest.java > > test; > > jdi/BadHandshakeTest.java also uses Utils.getFreePort(), but it > > handles "Already in use" error re-peeking other free port and > > restarting debuggee, so I keep it as is. > > > > --alex > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Oct 11 02:36:44 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Oct 2018 12:36:44 +1000 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> Message-ID: On 11/10/2018 12:19 PM, JC Beyler wrote: > Hi Alex, > > - > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html > > ? -> Why not make it javadoc like the other methods of the same file > (so?@return instead of returns and a second * at the start of the comment)? > > - > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html > > a)? ?I'm surprised by this: > > + int res; > + try { > + res = handshake(detectPort(a.getProcessStdout())); > + } finally { > a.stopApp(); > + } > if (res < 0) { > > > I would have thought that this makes javac return a "res might not be initialized" error. res can only be uninitialized if an exception occurs, in which case you won't reach the "if (res , 0)" statement. David ----- > > b) Nit: Is there a reason we are complicating the code here: > > try { > LingeredApp a = LingeredApp.startApp(cmd); > + > + // startApp is expected to fail, but if not, terminate the app > + try { > + a.stopApp(); > + } catch (IOException e) { > + // print and let the test fail > + System.err.println("LingeredApp.stopApp failed"); > + e.printStackTrace(); > + } > } catch (IOException ex) { > System.err.println(testName + ": caught expected IOException"); > System.err.println(testName + " PASSED"); > return; > } > > Why not just put it below? We could either put a outside the try and then move that code out; or perhaps move it into a separate method to let > > the reader concentrate on the test at hand and let the "stopping of the app" happen somewhere else? > > > Thanks, > Jc > > On Wed, Oct 10, 2018 at 5:18 PM serguei.spitsyn at oracle.com > > wrote: > > Hi Alex, > > It looks good to me. > How did you test it? > > Thanks, > Serguei > > > On 10/10/18 16:25, Alex Menkov wrote: > > Hi all, > > > > please review a fix for > > https://bugs.openjdk.java.net/browse/JDK-8195703 > > webrev: > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ > > > > > I was not able to reproduce the issue, but accordingly the logs in > > jira root cause is a transport initialization error "Address already > > in use". > > The test uses Utils.getFreePort() to select some free port, but > it can > > be race condition when some other app (or other test) uses the port > > selected before debuggee application starts to listen on it. > > The fix uses dynamic port allocation and then parses it from the > > debuggee output. > > Other changes: > > - dropped catching exceptions and calling System.exit() - this > causes > > SecurityException in JTReg harness which makes error analysis much > > harder; > > - dropped using of Utils.getFreePort() from jdi/DoubleAgentTest.java > > test; > > ? jdi/BadHandshakeTest.java also uses Utils.getFreePort(), but it > > handles "Already in use" error re-peeking other free port and > > restarting debuggee, so I keep it as is. > > > > --alex > > > > > > -- > > Thanks, > Jc From serguei.spitsyn at oracle.com Thu Oct 11 02:39:56 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 10 Oct 2018 19:39:56 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> Message-ID: <9d831ec8-9b7c-8db0-4759-d3c0bbf67465@oracle.com> On 10/10/18 19:36, David Holmes wrote: > On 11/10/2018 12:19 PM, JC Beyler wrote: >> Hi Alex, >> >> - >> http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html >> >> >> ?? -> Why not make it javadoc like the other methods of the same file >> (so?@return instead of returns and a second * at the start of the >> comment)? >> >> - >> http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html >> >> >> a)? ?I'm surprised by this: >> >> + int res; >> + try { >> + res = handshake(detectPort(a.getProcessStdout())); >> + } finally { >> ????????? a.stopApp(); >> + } >> ????????? if (res < 0) { >> >> >> I would have thought that this makes javac return a "res might not be >> initialized" error. > > res can only be uninitialized if an exception occurs, in which case > you won't reach the "if (res , 0)" statement. It is better to have res initialized: ? int res = -1; Thanks, Serguei > David > ----- > >> >> b) Nit: Is there a reason we are complicating the code here: >> >> ????????? try { >> ????????????? LingeredApp a = LingeredApp.startApp(cmd); >> + >> + // startApp is expected to fail, but if not, terminate the app >> + try { >> + a.stopApp(); >> + } catch (IOException e) { >> + // print and let the test fail >> + System.err.println("LingeredApp.stopApp failed"); >> + e.printStackTrace(); >> + } >> ????????? } catch (IOException ex) { >> ????????????? System.err.println(testName + ": caught expected >> IOException"); >> ????????????? System.err.println(testName + " PASSED"); >> ????????????? return; >> ????????? } >> >> Why not just put it below? We could either put a outside the try and >> then move that code out; or perhaps move it into a separate method to >> let >> >> the reader concentrate on the test at hand and let the "stopping of >> the app"? happen somewhere else? >> >> >> Thanks, >> Jc >> >> On Wed, Oct 10, 2018 at 5:18 PM serguei.spitsyn at oracle.com >> > > wrote: >> >> ??? Hi Alex, >> >> ??? It looks good to me. >> ??? How did you test it? >> >> ??? Thanks, >> ??? Serguei >> >> >> ??? On 10/10/18 16:25, Alex Menkov wrote: >> ???? > Hi all, >> ???? > >> ???? > please review a fix for >> ???? > https://bugs.openjdk.java.net/browse/JDK-8195703 >> ???? > webrev: >> ???? > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ >> >> ???? > >> ???? > I was not able to reproduce the issue, but accordingly the >> logs in >> ???? > jira root cause is a transport initialization error "Address >> already >> ???? > in use". >> ???? > The test uses Utils.getFreePort() to select some free port, but >> ??? it can >> ???? > be race condition when some other app (or other test) uses the >> port >> ???? > selected before debuggee application starts to listen on it. >> ???? > The fix uses dynamic port allocation and then parses it from the >> ???? > debuggee output. >> ???? > Other changes: >> ???? > - dropped catching exceptions and calling System.exit() - this >> ??? causes >> ???? > SecurityException in JTReg harness which makes error analysis >> much >> ???? > harder; >> ???? > - dropped using of Utils.getFreePort() from >> jdi/DoubleAgentTest.java >> ???? > test; >> ???? > ? jdi/BadHandshakeTest.java also uses Utils.getFreePort(), but it >> ???? > handles "Already in use" error re-peeking other free port and >> ???? > restarting debuggee, so I keep it as is. >> ???? > >> ???? > --alex >> ???? > >> >> >> >> -- >> >> Thanks, >> Jc From jcbeyler at google.com Thu Oct 11 03:09:11 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 10 Oct 2018 20:09:11 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> Message-ID: So that's what I thought too but I did this: $ cat Test.java public class Test { public static void main(String[] args) { int res; try { res = 5; } catch (Exception e) { } if (res > 0) { } } } That fails to compile with JDK8 and JDK11 it seems. Perhaps I'm doing something wrong? $ javac Test.java Test.java:10: error: variable res might not have been initialized if (res > 0) { ^ 1 error Sorry if I'm derailing the review :) Jc On Wed, Oct 10, 2018 at 7:36 PM David Holmes wrote: > On 11/10/2018 12:19 PM, JC Beyler wrote: > > Hi Alex, > > > > - > > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html > > < > http://cr.openjdk.java.net/%7Eamenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html > > > > -> Why not make it javadoc like the other methods of the same file > > (so @return instead of returns and a second * at the start of the > comment)? > > > > - > > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html > > < > http://cr.openjdk.java.net/%7Eamenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html > > > > a) I'm surprised by this: > > > > + int res; > > + try { > > + res = handshake(detectPort(a.getProcessStdout())); > > + } finally { > > a.stopApp(); > > + } > > if (res < 0) { > > > > > > I would have thought that this makes javac return a "res might not be > initialized" error. > > res can only be uninitialized if an exception occurs, in which case you > won't reach the "if (res , 0)" statement. > > David > ----- > > > > > b) Nit: Is there a reason we are complicating the code here: > > > > try { > > LingeredApp a = LingeredApp.startApp(cmd); > > + > > + // startApp is expected to fail, but if not, terminate the app > > + try { > > + a.stopApp(); > > + } catch (IOException e) { > > + // print and let the test fail > > + System.err.println("LingeredApp.stopApp failed"); > > + e.printStackTrace(); > > + } > > } catch (IOException ex) { > > System.err.println(testName + ": caught expected > IOException"); > > System.err.println(testName + " PASSED"); > > return; > > } > > > > Why not just put it below? We could either put a outside the try and > then move that code out; or perhaps move it into a separate method to let > > > > the reader concentrate on the test at hand and let the "stopping of the > app" happen somewhere else? > > > > > > Thanks, > > Jc > > > > On Wed, Oct 10, 2018 at 5:18 PM serguei.spitsyn at oracle.com > > > > wrote: > > > > Hi Alex, > > > > It looks good to me. > > How did you test it? > > > > Thanks, > > Serguei > > > > > > On 10/10/18 16:25, Alex Menkov wrote: > > > Hi all, > > > > > > please review a fix for > > > https://bugs.openjdk.java.net/browse/JDK-8195703 > > > webrev: > > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ > > > > > > > > I was not able to reproduce the issue, but accordingly the logs in > > > jira root cause is a transport initialization error "Address > already > > > in use". > > > The test uses Utils.getFreePort() to select some free port, but > > it can > > > be race condition when some other app (or other test) uses the > port > > > selected before debuggee application starts to listen on it. > > > The fix uses dynamic port allocation and then parses it from the > > > debuggee output. > > > Other changes: > > > - dropped catching exceptions and calling System.exit() - this > > causes > > > SecurityException in JTReg harness which makes error analysis much > > > harder; > > > - dropped using of Utils.getFreePort() from > jdi/DoubleAgentTest.java > > > test; > > > jdi/BadHandshakeTest.java also uses Utils.getFreePort(), but it > > > handles "Already in use" error re-peeking other free port and > > > restarting debuggee, so I keep it as is. > > > > > > --alex > > > > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Oct 11 03:12:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Oct 2018 13:12:31 +1000 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> Message-ID: <81b74f08-79ca-3f9f-e2f4-f5084d061a86@oracle.com> On 11/10/2018 1:09 PM, JC Beyler wrote: > So that's what I thought too but I did this: > > $ cat Test.java > public class Test { > public static void main(String[] args) { > int res; > > try { > res = 5; > } catch (Exception e) { > } > > if (res > 0) { > } > } > } > > That fails to compile with JDK8 and JDK11 it seems. Perhaps I'm doing something wrong? Yes. :) You are catching the theoretical exception from the assignment and so allowing control to reach the if statement - at which point res may not be initialized. David ----- > $ javac Test.java > Test.java:10: error: variable res might not have been initialized > if (res > 0) { > ^ > 1 error > > > Sorry if I'm derailing the review :) > > Jc > > > On Wed, Oct 10, 2018 at 7:36 PM David Holmes > wrote: > > On 11/10/2018 12:19 PM, JC Beyler wrote: > > Hi Alex, > > > > - > > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html > > > > > > >? ? -> Why not make it javadoc like the other methods of the same > file > > (so?@return instead of returns and a second * at the start of the > comment)? > > > > - > > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html > > > > > > > a)? ?I'm surprised by this: > > > > + int res; > > + try { > > + res = handshake(detectPort(a.getProcessStdout())); > > + } finally { > >? ? ? ? ? ?a.stopApp(); > > + } > >? ? ? ? ? ?if (res < 0) { > > > > > > I would have thought that this makes javac return a "res might > not be initialized" error. > > res can only be uninitialized if an exception occurs, in which case you > won't reach the "if (res , 0)" statement. > > David > ----- > > > > > b) Nit: Is there a reason we are complicating the code here: > > > >? ? ? ? ? ?try { > >? ? ? ? ? ? ? ?LingeredApp a = LingeredApp.startApp(cmd); > > + > > + // startApp is expected to fail, but if not, terminate the app > > + try { > > + a.stopApp(); > > + } catch (IOException e) { > > + // print and let the test fail > > + System.err.println("LingeredApp.stopApp failed"); > > + e.printStackTrace(); > > + } > >? ? ? ? ? ?} catch (IOException ex) { > >? ? ? ? ? ? ? ?System.err.println(testName + ": caught expected > IOException"); > >? ? ? ? ? ? ? ?System.err.println(testName + " PASSED"); > >? ? ? ? ? ? ? ?return; > >? ? ? ? ? ?} > > > > Why not just put it below? We could either put a outside the try > and then move that code out; or perhaps move it into a separate > method to let > > > > the reader concentrate on the test at hand and let the "stopping > of the app"? happen somewhere else? > > > > > > Thanks, > > Jc > > > > On Wed, Oct 10, 2018 at 5:18 PM serguei.spitsyn at oracle.com > > > > > > >> wrote: > > > >? ? ?Hi Alex, > > > >? ? ?It looks good to me. > >? ? ?How did you test it? > > > >? ? ?Thanks, > >? ? ?Serguei > > > > > >? ? ?On 10/10/18 16:25, Alex Menkov wrote: > >? ? ? > Hi all, > >? ? ? > > >? ? ? > please review a fix for > >? ? ? > https://bugs.openjdk.java.net/browse/JDK-8195703 > >? ? ? > webrev: > >? ? ? > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ > > >? ? ? > >? ? ? > > >? ? ? > I was not able to reproduce the issue, but accordingly the > logs in > >? ? ? > jira root cause is a transport initialization error > "Address already > >? ? ? > in use". > >? ? ? > The test uses Utils.getFreePort() to select some free > port, but > >? ? ?it can > >? ? ? > be race condition when some other app (or other test) uses > the port > >? ? ? > selected before debuggee application starts to listen on it. > >? ? ? > The fix uses dynamic port allocation and then parses it > from the > >? ? ? > debuggee output. > >? ? ? > Other changes: > >? ? ? > - dropped catching exceptions and calling System.exit() - this > >? ? ?causes > >? ? ? > SecurityException in JTReg harness which makes error > analysis much > >? ? ? > harder; > >? ? ? > - dropped using of Utils.getFreePort() from > jdi/DoubleAgentTest.java > >? ? ? > test; > >? ? ? > ? jdi/BadHandshakeTest.java also uses Utils.getFreePort(), > but it > >? ? ? > handles "Already in use" error re-peeking other free port and > >? ? ? > restarting debuggee, so I keep it as is. > >? ? ? > > >? ? ? > --alex > >? ? ? > > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From jcbeyler at google.com Thu Oct 11 03:28:45 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 10 Oct 2018 20:28:45 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: <81b74f08-79ca-3f9f-e2f4-f5084d061a86@oracle.com> References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> <81b74f08-79ca-3f9f-e2f4-f5084d061a86@oracle.com> Message-ID: Whomp whomp :) Ok, then my review becomes: apart from my nit, looks good to me :-) Jc On Wed, Oct 10, 2018 at 8:12 PM David Holmes wrote: > On 11/10/2018 1:09 PM, JC Beyler wrote: > > So that's what I thought too but I did this: > > > > $ cat Test.java > > public class Test { > > public static void main(String[] args) { > > int res; > > > > try { > > res = 5; > > } catch (Exception e) { > > } > > > > if (res > 0) { > > } > > } > > } > > > > That fails to compile with JDK8 and JDK11 it seems. Perhaps I'm doing > something wrong? > > Yes. :) You are catching the theoretical exception from the assignment > and so allowing control to reach the if statement - at which point res > may not be initialized. > > David > ----- > > > $ javac Test.java > > Test.java:10: error: variable res might not have been initialized > > if (res > 0) { > > ^ > > 1 error > > > > > > Sorry if I'm derailing the review :) > > > > Jc > > > > > > On Wed, Oct 10, 2018 at 7:36 PM David Holmes > > wrote: > > > > On 11/10/2018 12:19 PM, JC Beyler wrote: > > > Hi Alex, > > > > > > - > > > > > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html > > < > http://cr.openjdk.java.net/%7Eamenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html > > > > > > > > > < > http://cr.openjdk.java.net/%7Eamenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html > > > > > -> Why not make it javadoc like the other methods of the same > > file > > > (so @return instead of returns and a second * at the start of the > > comment)? > > > > > > - > > > > > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html > > < > http://cr.openjdk.java.net/%7Eamenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html > > > > > > > > > < > http://cr.openjdk.java.net/%7Eamenkov/BasicJDWPConn/webrev.01/test/jdk/com/sun/jdi/BasicJDWPConnectionTest.java.udiff.html > > > > > a) I'm surprised by this: > > > > > > + int res; > > > + try { > > > + res = handshake(detectPort(a.getProcessStdout())); > > > + } finally { > > > a.stopApp(); > > > + } > > > if (res < 0) { > > > > > > > > > I would have thought that this makes javac return a "res might > > not be initialized" error. > > > > res can only be uninitialized if an exception occurs, in which case > you > > won't reach the "if (res , 0)" statement. > > > > David > > ----- > > > > > > > > b) Nit: Is there a reason we are complicating the code here: > > > > > > try { > > > LingeredApp a = LingeredApp.startApp(cmd); > > > + > > > + // startApp is expected to fail, but if not, terminate the app > > > + try { > > > + a.stopApp(); > > > + } catch (IOException e) { > > > + // print and let the test fail > > > + System.err.println("LingeredApp.stopApp failed"); > > > + e.printStackTrace(); > > > + } > > > } catch (IOException ex) { > > > System.err.println(testName + ": caught expected > > IOException"); > > > System.err.println(testName + " PASSED"); > > > return; > > > } > > > > > > Why not just put it below? We could either put a outside the try > > and then move that code out; or perhaps move it into a separate > > method to let > > > > > > the reader concentrate on the test at hand and let the "stopping > > of the app" happen somewhere else? > > > > > > > > > Thanks, > > > Jc > > > > > > On Wed, Oct 10, 2018 at 5:18 PM serguei.spitsyn at oracle.com > > > > > > > > > > > > >> wrote: > > > > > > Hi Alex, > > > > > > It looks good to me. > > > How did you test it? > > > > > > Thanks, > > > Serguei > > > > > > > > > On 10/10/18 16:25, Alex Menkov wrote: > > > > Hi all, > > > > > > > > please review a fix for > > > > https://bugs.openjdk.java.net/browse/JDK-8195703 > > > > webrev: > > > > > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ > > > > > < > http://cr.openjdk.java.net/%7Eamenkov/BasicJDWPConn/webrev.01/> > > > > > > > > I was not able to reproduce the issue, but accordingly the > > logs in > > > > jira root cause is a transport initialization error > > "Address already > > > > in use". > > > > The test uses Utils.getFreePort() to select some free > > port, but > > > it can > > > > be race condition when some other app (or other test) uses > > the port > > > > selected before debuggee application starts to listen on > it. > > > > The fix uses dynamic port allocation and then parses it > > from the > > > > debuggee output. > > > > Other changes: > > > > - dropped catching exceptions and calling System.exit() - > this > > > causes > > > > SecurityException in JTReg harness which makes error > > analysis much > > > > harder; > > > > - dropped using of Utils.getFreePort() from > > jdi/DoubleAgentTest.java > > > > test; > > > > jdi/BadHandshakeTest.java also uses Utils.getFreePort(), > > but it > > > > handles "Already in use" error re-peeking other free port > and > > > > restarting debuggee, so I keep it as is. > > > > > > > > --alex > > > > > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Oct 11 08:10:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Oct 2018 18:10:20 +1000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> Message-ID: On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > There used to be a rule against using ?namespace?. Don?t know if that?s > still true or not: I believe it is. Hence the ?static const ?. > > You only need OrderAccess if there could be a race on accesses to > whatever you?re guarding. Looks like the old code wanted to make sure > that log_table was initialized and its content available to other > threads before the _enabled flag was set. I.e., the _enabled flag acted > as a store visibility barrier for log_table, and possibly other > ThreadHeapSampler data structures. If no thread can ever see a partially > initialized log_table, then no need for ordering. The old code used a > MutexLocker in init_log_table(), which former has a fence in its > destructor and probably (haven?t dived into the code) guards all > accesses to log_table, so the release_store() on _enabled in enable() > was redundant. The release_store and load_acquire were necessary to ensure the lock-free enabled() check ensured visibility of the initialization of the data structures in the ensuing code. Otherwise you'd need to grab the lock on the enabled() checks, which is too heavy-weight. The lock is only used to ensure single-threaded initialization of the log_table, actual accesses are again lock-free. David Same with the release_store() in disable(), unless there > was some reason to make sure all threads saw previous stores to > ThreadHeapSampler related memory before _enabled was set to zero. The > load_acquire in enabled() may not have been needed either, because it > only prevents subsequent loads from being executed before the load from > _enabled, so if _enabled was being used to guard access only to > ThreadHeapSampler data such as log_table, the release_store() on > _enabled would guarantee that all necessary stores would be done before > _enabled was set to one and seen by enabled(). > > Yeah, that?s hard to follow, and I wrote it. :) It comes down to what > you?re guarding with OrderAccess. If it?s only ThreadHeapSampler data, > and since only a Thread has one, and since ThreadHeapSampler statics are > initialized before construction of the first _heap_sampler, and since > the construction of a Thread is guarded by multiple mutexes which will > force visibility of any ThreadHeapSampler statics before a Thread is > used, you don?t need OrderAccess. > > I?d put anything to do with ThreadHeapSampler into its class definition > rather than define them at file scope in threadHeapSampler.cpp. I.e., > all of FastLogNumBits, FastLogMask, and internal_log_table (and name it > back to that log_table). File scope data is a no-no. > > Hope this helps, > > Paul > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Tuesday, October 9, 2018 at 11:58 PM > *To: *"serviceability-dev at openjdk.java.net" > > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > enable/disable/enabled methods > > Hi all, > > When talking with Serguei about JDK-8201655 > , we talked about why > ThreadHeapSampler has an enabled/disabled when we could have just used > the should_post_sampled_object_alloc to begin with. > > Could I get a review for this: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > This passed my testing on my dev machine in release and fastdebug. > > The question I would like to raise here at the same time (in order to > reduce email spam and because it should be included in the review I > believe) is: > > ? - When I did the enable/disable, I used OrderAccess to do so after a > reviewer asked for it > > ? - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and does > instead: > > #define JVMTI_SUPPORT_FLAG(key)? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? private:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? static bool? _##key;? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? public:? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? inline static void set_##key(bool on) {? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? ? JVMTI_ONLY(_##key = (on != 0));? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? ? NOT_JVMTI(report_unsupported(on));? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? }? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?\ > > ? inline static bool key() {? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? ? JVMTI_ONLY(return _##key);? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? ? NOT_JVMTI(return false);? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? \ > > ? } > > Should it (ie in a future bug/webrev)? > > Thanks, > > Jc > From fairoz.matte at oracle.com Thu Oct 11 13:22:42 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Thu, 11 Oct 2018 13:22:42 +0000 (UTC) Subject: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation Message-ID: <6845e4a5-d103-4f8f-9a34-390d83f75014@default> Hi, Kindly review the backport of "JDK-8193879: Java debugger hangs on method invocation" to 8u Code is almost cleanly applied, test case has been modified to fit into the JDK8 test framework. Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8193879 JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/218b5b64f102 Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025365.html Thanks, Fairoz From jcbeyler at google.com Thu Oct 11 15:53:29 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 11 Oct 2018 08:53:29 -0700 Subject: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation In-Reply-To: <6845e4a5-d103-4f8f-9a34-390d83f75014@default> References: <6845e4a5-d103-4f8f-9a34-390d83f75014@default> Message-ID: Hi Fairoz, The backport looks good to me (not a reviewer though) but I was wondering why you are porting the two methods (getTestSourcePath and parseBreakpoints) into this test? If we port other tests that would require it, would we be doing the same or factorizing the methods into a helper class ? Last nit, those methods could be private no? Thanks, Jc On Thu, Oct 11, 2018 at 6:22 AM Fairoz Matte wrote: > Hi, > > Kindly review the backport of "JDK-8193879: Java debugger hangs on method > invocation" to 8u > Code is almost cleanly applied, test case has been modified to fit into > the JDK8 test framework. > > Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.00/ > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8193879 > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/218b5b64f102 > > Review thread - > http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025365.html > > > Thanks, > Fairoz > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Thu Oct 11 17:00:06 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 11 Oct 2018 10:00:06 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> Message-ID: <2abe9e76-1fec-52aa-0d91-5b47fe0dd01f@oracle.com> Hi Serguei, I run the test itself and jdk/com/sun/jdi multiple times. --alex On 10/10/2018 17:17, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > It looks good to me. > How did you test it? > > Thanks, > Serguei > > > On 10/10/18 16:25, Alex Menkov wrote: >> Hi all, >> >> please review a fix for >> https://bugs.openjdk.java.net/browse/JDK-8195703 >> webrev: >> http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.01/ >> >> I was not able to reproduce the issue, but accordingly the logs in >> jira root cause is a transport initialization error "Address already >> in use". >> The test uses Utils.getFreePort() to select some free port, but it can >> be race condition when some other app (or other test) uses the port >> selected before debuggee application starts to listen on it. >> The fix uses dynamic port allocation and then parses it from the >> debuggee output. >> Other changes: >> - dropped catching exceptions and calling System.exit() - this causes >> SecurityException in JTReg harness which makes error analysis much >> harder; >> - dropped using of Utils.getFreePort() from jdi/DoubleAgentTest.java >> test; >> ? jdi/BadHandshakeTest.java also uses Utils.getFreePort(), but it >> handles "Already in use" error re-peeking other free port and >> restarting debuggee, so I keep it as is. >> >> --alex >> > From serguei.spitsyn at oracle.com Thu Oct 11 17:11:13 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 11 Oct 2018 10:11:13 -0700 Subject: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation In-Reply-To: <6845e4a5-d103-4f8f-9a34-390d83f75014@default> References: <6845e4a5-d103-4f8f-9a34-390d83f75014@default> Message-ID: Hi Fairoz, It looks good to me. Thanks, Serguei On 10/11/18 6:22 AM, Fairoz Matte wrote: > Hi, > > Kindly review the backport of "JDK-8193879: Java debugger hangs on method invocation" to 8u > Code is almost cleanly applied, test case has been modified to fit into the JDK8 test framework. > > Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.00/ > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8193879 > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/218b5b64f102 > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025365.html > > > Thanks, > Fairoz From hohensee at amazon.com Thu Oct 11 17:44:30 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Oct 2018 17:44:30 +0000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> Message-ID: <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> So, given that the lock was only used to protect log_table initialization, and that the patch moves that into the C++ "class initializer" which is run when the first Thread object is constructed, we don't need any locking/memory ordering anymore, right? Paul ?On 10/11/18, 4:11 AM, "David Holmes" wrote: On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > There used to be a rule against using ?namespace?. Don?t know if that?s > still true or not: I believe it is. Hence the ?static const ?. > > You only need OrderAccess if there could be a race on accesses to > whatever you?re guarding. Looks like the old code wanted to make sure > that log_table was initialized and its content available to other > threads before the _enabled flag was set. I.e., the _enabled flag acted > as a store visibility barrier for log_table, and possibly other > ThreadHeapSampler data structures. If no thread can ever see a partially > initialized log_table, then no need for ordering. The old code used a > MutexLocker in init_log_table(), which former has a fence in its > destructor and probably (haven?t dived into the code) guards all > accesses to log_table, so the release_store() on _enabled in enable() > was redundant. The release_store and load_acquire were necessary to ensure the lock-free enabled() check ensured visibility of the initialization of the data structures in the ensuing code. Otherwise you'd need to grab the lock on the enabled() checks, which is too heavy-weight. The lock is only used to ensure single-threaded initialization of the log_table, actual accesses are again lock-free. David Same with the release_store() in disable(), unless there > was some reason to make sure all threads saw previous stores to > ThreadHeapSampler related memory before _enabled was set to zero. The > load_acquire in enabled() may not have been needed either, because it > only prevents subsequent loads from being executed before the load from > _enabled, so if _enabled was being used to guard access only to > ThreadHeapSampler data such as log_table, the release_store() on > _enabled would guarantee that all necessary stores would be done before > _enabled was set to one and seen by enabled(). > > Yeah, that?s hard to follow, and I wrote it. :) It comes down to what > you?re guarding with OrderAccess. If it?s only ThreadHeapSampler data, > and since only a Thread has one, and since ThreadHeapSampler statics are > initialized before construction of the first _heap_sampler, and since > the construction of a Thread is guarded by multiple mutexes which will > force visibility of any ThreadHeapSampler statics before a Thread is > used, you don?t need OrderAccess. > > I?d put anything to do with ThreadHeapSampler into its class definition > rather than define them at file scope in threadHeapSampler.cpp. I.e., > all of FastLogNumBits, FastLogMask, and internal_log_table (and name it > back to that log_table). File scope data is a no-no. > > Hope this helps, > > Paul > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Tuesday, October 9, 2018 at 11:58 PM > *To: *"serviceability-dev at openjdk.java.net" > > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > enable/disable/enabled methods > > Hi all, > > When talking with Serguei about JDK-8201655 > , we talked about why > ThreadHeapSampler has an enabled/disabled when we could have just used > the should_post_sampled_object_alloc to begin with. > > Could I get a review for this: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > This passed my testing on my dev machine in release and fastdebug. > > The question I would like to raise here at the same time (in order to > reduce email spam and because it should be included in the review I > believe) is: > > - When I did the enable/disable, I used OrderAccess to do so after a > reviewer asked for it > > - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and does > instead: > > #define JVMTI_SUPPORT_FLAG(key) \ > > private: \ > > static bool _##key; \ > > public: \ > > inline static void set_##key(bool on) { \ > > JVMTI_ONLY(_##key = (on != 0)); \ > > NOT_JVMTI(report_unsupported(on)); \ > > } \ > > inline static bool key() { \ > > JVMTI_ONLY(return _##key); \ > > NOT_JVMTI(return false); \ > > } > > Should it (ie in a future bug/webrev)? > > Thanks, > > Jc > From alexey.menkov at oracle.com Thu Oct 11 18:02:27 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 11 Oct 2018 11:02:27 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> <81b74f08-79ca-3f9f-e2f4-f5084d061a86@oracle.com> Message-ID: <2f045621-d319-66af-0e90-04a2322b3728@oracle.com> Hi Jc, updated webrev: http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.02/ > >>> -> Why not make it javadoc like the other methods of the same file >>> (so?@return instead of returns and a second * at the start of the >>? ? ?comment)? done. >>> b) Nit: Is there a reason we are complicating the code here: >>> >>>? ? ? ? ? ?try { >>>? ? ? ? ? ? ? ?LingeredApp a = LingeredApp.startApp(cmd); >>> + >>> + // startApp is expected to fail, but if not, terminate the app >>> + try { >>> + a.stopApp(); >>> + } catch (IOException e) { >>> + // print and let the test fail >>> + System.err.println("LingeredApp.stopApp failed"); >>> + e.printStackTrace(); >>> + } >>>? ? ? ? ? ?} catch (IOException ex) { >>>? ? ? ? ? ? ? ?System.err.println(testName + ": caught expected >>? ? ?IOException"); >>>? ? ? ? ? ? ? ?System.err.println(testName + " PASSED"); >>>? ? ? ? ? ? ? ?return; >>>? ? ? ? ? ?} >>> >>> Why not just put it below? We could either put a outside the try >> and then move that code out; or perhaps move it into a separate >> method to let >>> >>> the reader concentrate on the test at hand and let the "stopping >>? ? ?of the app"? happen somewhere else? This is to improve code cleanup on error (the test expects that LingeredApp.startApp(cmd) fails, but if the test fails, the app remains running). I moved cleanup outside of the try (and removed try/catch around a.stopApp() - the test throws Exception anyway) --alex From alexey.menkov at oracle.com Thu Oct 11 18:03:51 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 11 Oct 2018 11:03:51 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> Message-ID: got it. LGTM. --alex On 10/10/2018 19:03, JC Beyler wrote: > Hi Alex, > > Thanks for the review! Yes I had seen that too before sending this > review out and forked that fix into this: > https://bugs.openjdk.java.net/browse/JDK-8211905 > > Which now is merged and I've updated my webrev to reflect this of course. > > My rationale for not doing it here directly is always the same: keeping > the changes to the "spirit" of what the change is trying to do. Those > extra casts were a bit out-of-scope and so I just forked the fix in 8211905. > > Thanks! > Jc > > On Wed, Oct 10, 2018 at 5:40 PM Alex Menkov > wrote: > > Hi Jc, > > Overall looks good. > > one minor note: > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: > -? ? jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > (jstring) (jstring) (jstring) (jstring) NSK_CPP_STUB3(CallObjectMethod, > jni_env, klass, > -? ? ? ? ? ? ? ? ? ? ? ? methodID); > +? ? jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > (jstring) (jstring) (jstring) (jstring) > jni_env->CallObjectMethod(klass, > methodID); > > Please drop multi "(jstring)" > > --alex > > On 10/08/2018 21:21, JC Beyler wrote: > > Hi all, > > > > I am continuing the NSK_CPP_STUB removal with this next webrev. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 > > > > The change is still straight-forward though, since it is just > doing the > > same NSK_CPP_STUB removal. However when I was looking at the > changes, a > > lot of these changes are touching lines with spaces before/after > > parenthesis. I've almost never touched the spaces except if I was > > refactoring by hand the line at the same time. The rationale > being that > > the lines will get fixed a few more times and are, at worse, > covered by > > the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which > I've > > commited to doing. > > > > Two exceptions are here where I pushed out the code into > assignments due > > to really long lines and complex if structures: > > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp > > > > > - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp > > > > > > > And one exception here where a commented line was doing the > out-of-if > > assignment so I just uncommented it and used the variable: > > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp > > > > > > > I've tested the modified changes on my machine, all modified > tests pass. > > > > Let me know what you think, > > Jc > > > > Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* > > > > > > -- > > Thanks, > Jc From jcbeyler at google.com Thu Oct 11 19:48:06 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 11 Oct 2018 12:48:06 -0700 Subject: RFR JDK-8195703: BasicJDWPConnectionTest.java: 'App exited unexpectedly with 2' In-Reply-To: <2f045621-d319-66af-0e90-04a2322b3728@oracle.com> References: <3037ccbc-b6f2-66ab-384b-4b853641dab9@oracle.com> <8e23c3be-52b1-4179-ef61-7b438747a623@oracle.com> <81b74f08-79ca-3f9f-e2f4-f5084d061a86@oracle.com> <2f045621-d319-66af-0e90-04a2322b3728@oracle.com> Message-ID: Hi Alex, Looks great to me, thanks for cleaning it up! Jc On Thu, Oct 11, 2018 at 11:02 AM Alex Menkov wrote: > Hi Jc, > > updated webrev: > http://cr.openjdk.java.net/~amenkov/BasicJDWPConn/webrev.02/ > > > < > http://cr.openjdk.java.net/%7Eamenkov/BasicJDWPConn/webrev.01/test/lib/jdk/test/lib/apps/LingeredApp.java.udiff.html > > > >>> -> Why not make it javadoc like the other methods of the same file > >>> (so @return instead of returns and a second * at the start of the > >> comment)? > > done. > > > >>> b) Nit: Is there a reason we are complicating the code here: > >>> > >>> try { > >>> LingeredApp a = LingeredApp.startApp(cmd); > >>> + > >>> + // startApp is expected to fail, but if not, terminate the app > >>> + try { > >>> + a.stopApp(); > >>> + } catch (IOException e) { > >>> + // print and let the test fail > >>> + System.err.println("LingeredApp.stopApp failed"); > >>> + e.printStackTrace(); > >>> + } > >>> } catch (IOException ex) { > >>> System.err.println(testName + ": caught expected > >> IOException"); > >>> System.err.println(testName + " PASSED"); > >>> return; > >>> } > >>> > >>> Why not just put it below? We could either put a outside the try > >> and then move that code out; or perhaps move it into a separate > >> method to let > >>> > >>> the reader concentrate on the test at hand and let the "stopping > >> of the app" happen somewhere else? > > This is to improve code cleanup on error (the test expects that > LingeredApp.startApp(cmd) fails, but if the test fails, the app remains > running). > I moved cleanup outside of the try (and removed try/catch around > a.stopApp() - the test throws Exception anyway) > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Oct 11 19:49:43 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 11 Oct 2018 12:49:43 -0700 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> Message-ID: That is my current belief and understanding. So looks like we are good to go from a semantic point of view. Does anyone want to venture on a review of the webrev? Thanks! Jc On Thu, Oct 11, 2018 at 10:44 AM Hohensee, Paul wrote: > So, given that the lock was only used to protect log_table initialization, > and that the patch moves that into the C++ "class initializer" which is run > when the first Thread object is constructed, we don't need any > locking/memory ordering anymore, right? > > Paul > > ?On 10/11/18, 4:11 AM, "David Holmes" wrote: > > On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > > There used to be a rule against using ?namespace?. Don?t know if > that?s > > still true or not: I believe it is. Hence the ?static const > ?. > > > > You only need OrderAccess if there could be a race on accesses to > > whatever you?re guarding. Looks like the old code wanted to make > sure > > that log_table was initialized and its content available to other > > threads before the _enabled flag was set. I.e., the _enabled flag > acted > > as a store visibility barrier for log_table, and possibly other > > ThreadHeapSampler data structures. If no thread can ever see a > partially > > initialized log_table, then no need for ordering. The old code used > a > > MutexLocker in init_log_table(), which former has a fence in its > > destructor and probably (haven?t dived into the code) guards all > > accesses to log_table, so the release_store() on _enabled in > enable() > > was redundant. > > The release_store and load_acquire were necessary to ensure the > lock-free enabled() check ensured visibility of the initialization of > the data structures in the ensuing code. Otherwise you'd need to grab > the lock on the enabled() checks, which is too heavy-weight. The lock > is > only used to ensure single-threaded initialization of the log_table, > actual accesses are again lock-free. > > David > > Same with the release_store() in disable(), unless there > > was some reason to make sure all threads saw previous stores to > > ThreadHeapSampler related memory before _enabled was set to zero. > The > > load_acquire in enabled() may not have been needed either, because > it > > only prevents subsequent loads from being executed before the load > from > > _enabled, so if _enabled was being used to guard access only to > > ThreadHeapSampler data such as log_table, the release_store() on > > _enabled would guarantee that all necessary stores would be done > before > > _enabled was set to one and seen by enabled(). > > > > Yeah, that?s hard to follow, and I wrote it. :) It comes down to > what > > you?re guarding with OrderAccess. If it?s only ThreadHeapSampler > data, > > and since only a Thread has one, and since ThreadHeapSampler statics > are > > initialized before construction of the first _heap_sampler, and > since > > the construction of a Thread is guarded by multiple mutexes which > will > > force visibility of any ThreadHeapSampler statics before a Thread is > > used, you don?t need OrderAccess. > > > > I?d put anything to do with ThreadHeapSampler into its class > definition > > rather than define them at file scope in threadHeapSampler.cpp. > I.e., > > all of FastLogNumBits, FastLogMask, and internal_log_table (and name > it > > back to that log_table). File scope data is a no-no. > > > > Hope this helps, > > > > Paul > > > > *From: *serviceability-dev < > serviceability-dev-bounces at openjdk.java.net> > > on behalf of JC Beyler > > *Date: *Tuesday, October 9, 2018 at 11:58 PM > > *To: *"serviceability-dev at openjdk.java.net" > > > > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > > enable/disable/enabled methods > > > > Hi all, > > > > When talking with Serguei about JDK-8201655 > > , we talked about > why > > ThreadHeapSampler has an enabled/disabled when we could have just > used > > the should_post_sampled_object_alloc to begin with. > > > > Could I get a review for this: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > > > This passed my testing on my dev machine in release and fastdebug. > > > > The question I would like to raise here at the same time (in order > to > > reduce email spam and because it should be included in the review I > > believe) is: > > > > - When I did the enable/disable, I used OrderAccess to do so > after a > > reviewer asked for it > > > > - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and > does > > instead: > > > > #define JVMTI_SUPPORT_FLAG(key) > \ > > > > private: > \ > > > > static bool _##key; > \ > > > > public: > \ > > > > inline static void set_##key(bool on) { > \ > > > > JVMTI_ONLY(_##key = (on != 0)); > \ > > > > NOT_JVMTI(report_unsupported(on)); > \ > > > > } > \ > > > > inline static bool key() { > \ > > > > JVMTI_ONLY(return _##key); > \ > > > > NOT_JVMTI(return false); > \ > > > > } > > > > Should it (ie in a future bug/webrev)? > > > > Thanks, > > > > Jc > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Thu Oct 11 20:00:40 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Oct 2018 20:00:40 +0000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> Message-ID: I don?t think you?re missing anything, see my response to David. I don?t think you need _log_table_initialized, but I?ll defer to David. Paul From: JC Beyler Date: Wednesday, October 10, 2018 at 4:20 PM To: "Hohensee, Paul" Cc: "serviceability-dev at openjdk.java.net" Subject: Re: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods Hi Paul, Thanks for the detailed answer. I also moved everything into the class now to not have anything static outside anymore as you requested. Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 Just a few more notes on the webrev: - I need to get that table initialized and I don't want to check if it is initialized during runtime, I want to "assume" it is in the normal code path; previously this was easy since I piggy-backed in the enable method to do it there - With what you are saying in the ordering you are right but the only way I can do an initialization of an array via a method seems to be to at least set one static member of the class, I've put a boolean instead to be set to true However, for the OrderAccess conversation, the conversation I had when I did this was that if you know it thread A can set a variable and thread B can get a variable, we should be using an OrderAccess and not assume that it "does not matter" that a thread gets a stale value. Because of that, I added them for ThreadHeapSampler but it seems that the JVMTI code I showed above does not do this. However, I can very well imagine a case where one thread calls SetEventNotification while another thread is doing some sort of work and trying to do get a value from one of those flags. Or perhaps there is an implicit ordering being done somewhere that I'm not aware of. Am I missing something? Thanks, Jc On Wed, Oct 10, 2018 at 10:10 AM Hohensee, Paul > wrote: There used to be a rule against using ?namespace?. Don?t know if that?s still true or not: I believe it is. Hence the ?static const ?. You only need OrderAccess if there could be a race on accesses to whatever you?re guarding. Looks like the old code wanted to make sure that log_table was initialized and its content available to other threads before the _enabled flag was set. I.e., the _enabled flag acted as a store visibility barrier for log_table, and possibly other ThreadHeapSampler data structures. If no thread can ever see a partially initialized log_table, then no need for ordering. The old code used a MutexLocker in init_log_table(), which former has a fence in its destructor and probably (haven?t dived into the code) guards all accesses to log_table, so the release_store() on _enabled in enable() was redundant. Same with the release_store() in disable(), unless there was some reason to make sure all threads saw previous stores to ThreadHeapSampler related memory before _enabled was set to zero. The load_acquire in enabled() may not have been needed either, because it only prevents subsequent loads from being executed before the load from _enabled, so if _enabled was being used to guard access only to ThreadHeapSampler data such as log_table, the release_store() on _enabled would guarantee that all necessary stores would be done before _enabled was set to one and seen by enabled(). Yeah, that?s hard to follow, and I wrote it. :) It comes down to what you?re guarding with OrderAccess. If it?s only ThreadHeapSampler data, and since only a Thread has one, and since ThreadHeapSampler statics are initialized before construction of the first _heap_sampler, and since the construction of a Thread is guarded by multiple mutexes which will force visibility of any ThreadHeapSampler statics before a Thread is used, you don?t need OrderAccess. I?d put anything to do with ThreadHeapSampler into its class definition rather than define them at file scope in threadHeapSampler.cpp. I.e., all of FastLogNumBits, FastLogMask, and internal_log_table (and name it back to that log_table). File scope data is a no-no. Hope this helps, Paul From: serviceability-dev > on behalf of JC Beyler > Date: Tuesday, October 9, 2018 at 11:58 PM To: "serviceability-dev at openjdk.java.net" > Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods Hi all, When talking with Serguei about JDK-8201655, we talked about why ThreadHeapSampler has an enabled/disabled when we could have just used the should_post_sampled_object_alloc to begin with. Could I get a review for this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 This passed my testing on my dev machine in release and fastdebug. The question I would like to raise here at the same time (in order to reduce email spam and because it should be included in the review I believe) is: - When I did the enable/disable, I used OrderAccess to do so after a reviewer asked for it - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and does instead: #define JVMTI_SUPPORT_FLAG(key) \ private: \ static bool _##key; \ public: \ inline static void set_##key(bool on) { \ JVMTI_ONLY(_##key = (on != 0)); \ NOT_JVMTI(report_unsupported(on)); \ } \ inline static bool key() { \ JVMTI_ONLY(return _##key); \ NOT_JVMTI(return false); \ } Should it (ie in a future bug/webrev)? Thanks, Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Oct 11 22:13:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Oct 2018 08:13:45 +1000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> Message-ID: <889efd38-ffea-96be-a767-a14b10412e76@oracle.com> On 12/10/2018 3:44 AM, Hohensee, Paul wrote: > So, given that the lock was only used to protect log_table initialization, and that the patch moves that into the C++ "class initializer" which is run when the first Thread object is constructed, we don't need any locking/memory ordering anymore, right? Right so: - ThreadHeapSampler_lock can be removed - The load-acquire/release-store of _sampling_interval seem to serve no purpose, but _sampling_interval should at least be marked volatile (from a documentation perspective if nothing else). If the intent was for a change in sampling_interval to be immediately visible then a fence() would be needed. The _log_table_initialized flag is not needed from the perspective of an initialization check - you can't run code until after the static initializers have run (though I'm unclear how C++ manages this from a concurrency perspective). But the flag may be needed just as a means to separate the allocation of the table from the initialization of it - again I'm unclear how C++ static initialization works in detail (you have to be very careful with such initialization to ensure there are zero dependencies on anything done as part of VM initialization). David > Paul > > ?On 10/11/18, 4:11 AM, "David Holmes" wrote: > > On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > > There used to be a rule against using ?namespace?. Don?t know if that?s > > still true or not: I believe it is. Hence the ?static const ?. > > > > You only need OrderAccess if there could be a race on accesses to > > whatever you?re guarding. Looks like the old code wanted to make sure > > that log_table was initialized and its content available to other > > threads before the _enabled flag was set. I.e., the _enabled flag acted > > as a store visibility barrier for log_table, and possibly other > > ThreadHeapSampler data structures. If no thread can ever see a partially > > initialized log_table, then no need for ordering. The old code used a > > MutexLocker in init_log_table(), which former has a fence in its > > destructor and probably (haven?t dived into the code) guards all > > accesses to log_table, so the release_store() on _enabled in enable() > > was redundant. > > The release_store and load_acquire were necessary to ensure the > lock-free enabled() check ensured visibility of the initialization of > the data structures in the ensuing code. Otherwise you'd need to grab > the lock on the enabled() checks, which is too heavy-weight. The lock is > only used to ensure single-threaded initialization of the log_table, > actual accesses are again lock-free. > > David > > Same with the release_store() in disable(), unless there > > was some reason to make sure all threads saw previous stores to > > ThreadHeapSampler related memory before _enabled was set to zero. The > > load_acquire in enabled() may not have been needed either, because it > > only prevents subsequent loads from being executed before the load from > > _enabled, so if _enabled was being used to guard access only to > > ThreadHeapSampler data such as log_table, the release_store() on > > _enabled would guarantee that all necessary stores would be done before > > _enabled was set to one and seen by enabled(). > > > > Yeah, that?s hard to follow, and I wrote it. :) It comes down to what > > you?re guarding with OrderAccess. If it?s only ThreadHeapSampler data, > > and since only a Thread has one, and since ThreadHeapSampler statics are > > initialized before construction of the first _heap_sampler, and since > > the construction of a Thread is guarded by multiple mutexes which will > > force visibility of any ThreadHeapSampler statics before a Thread is > > used, you don?t need OrderAccess. > > > > I?d put anything to do with ThreadHeapSampler into its class definition > > rather than define them at file scope in threadHeapSampler.cpp. I.e., > > all of FastLogNumBits, FastLogMask, and internal_log_table (and name it > > back to that log_table). File scope data is a no-no. > > > > Hope this helps, > > > > Paul > > > > *From: *serviceability-dev > > on behalf of JC Beyler > > *Date: *Tuesday, October 9, 2018 at 11:58 PM > > *To: *"serviceability-dev at openjdk.java.net" > > > > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > > enable/disable/enabled methods > > > > Hi all, > > > > When talking with Serguei about JDK-8201655 > > , we talked about why > > ThreadHeapSampler has an enabled/disabled when we could have just used > > the should_post_sampled_object_alloc to begin with. > > > > Could I get a review for this: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > > > This passed my testing on my dev machine in release and fastdebug. > > > > The question I would like to raise here at the same time (in order to > > reduce email spam and because it should be included in the review I > > believe) is: > > > > - When I did the enable/disable, I used OrderAccess to do so after a > > reviewer asked for it > > > > - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and does > > instead: > > > > #define JVMTI_SUPPORT_FLAG(key) \ > > > > private: \ > > > > static bool _##key; \ > > > > public: \ > > > > inline static void set_##key(bool on) { \ > > > > JVMTI_ONLY(_##key = (on != 0)); \ > > > > NOT_JVMTI(report_unsupported(on)); \ > > > > } \ > > > > inline static bool key() { \ > > > > JVMTI_ONLY(return _##key); \ > > > > NOT_JVMTI(return false); \ > > > > } > > > > Should it (ie in a future bug/webrev)? > > > > Thanks, > > > > Jc > > > > From jcbeyler at google.com Thu Oct 11 22:20:17 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 11 Oct 2018 15:20:17 -0700 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: <889efd38-ffea-96be-a767-a14b10412e76@oracle.com> References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> <889efd38-ffea-96be-a767-a14b10412e76@oracle.com> Message-ID: I'm 100% in agreement with David :) Inlined are my comments: On Thu, Oct 11, 2018 at 3:13 PM David Holmes wrote: > On 12/10/2018 3:44 AM, Hohensee, Paul wrote: > > So, given that the lock was only used to protect log_table > initialization, and that the patch moves that into the C++ "class > initializer" which is run when the first Thread object is constructed, we > don't need any locking/memory ordering anymore, right? > > Right so: > > - ThreadHeapSampler_lock can be removed > - The load-acquire/release-store of _sampling_interval seem to serve no > purpose, but _sampling_interval should at least be marked volatile (from > a documentation perspective if nothing else). If the intent was for a > change in sampling_interval to be immediately visible then a fence() > would be needed. > Right, I would leave them in place (or at least postpone the conversation about them to a later webrev if someone feels really strongly about them; I believe it does not hurt, this will never be critical code but at least is semantically safe). > > The _log_table_initialized flag is not needed from the perspective of an > initialization check - you can't run code until after the static > initializers have run (though I'm unclear how C++ manages this from a > concurrency perspective). But the flag may be needed just as a means to > separate the allocation of the table from the initialization of it - > again I'm unclear how C++ static initialization works in detail (you > have to be very careful with such initialization to ensure there are > zero dependencies on anything done as part of VM initialization). > > Exactly. I cannot force the initialization of a static array via a method without initialization *something*. It can be to initialize a pointer to the array and I just use the pointer in the class; that was what the first webrev one was doing. Using a boolean such as here seems to be the lesser evil and allows us to add an assert that all is well in the world at the only usage point of the array in assert mode. So I'm happy with the current form (I'm biased since I sent the webrev for review :-)), any LGTM or other comments? Jc David > > > Paul > > > > ?On 10/11/18, 4:11 AM, "David Holmes" wrote: > > > > On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > > > There used to be a rule against using ?namespace?. Don?t know if > that?s > > > still true or not: I believe it is. Hence the ?static const > ?. > > > > > > You only need OrderAccess if there could be a race on accesses to > > > whatever you?re guarding. Looks like the old code wanted to make > sure > > > that log_table was initialized and its content available to other > > > threads before the _enabled flag was set. I.e., the _enabled flag > acted > > > as a store visibility barrier for log_table, and possibly other > > > ThreadHeapSampler data structures. If no thread can ever see a > partially > > > initialized log_table, then no need for ordering. The old code > used a > > > MutexLocker in init_log_table(), which former has a fence in its > > > destructor and probably (haven?t dived into the code) guards all > > > accesses to log_table, so the release_store() on _enabled in > enable() > > > was redundant. > > > > The release_store and load_acquire were necessary to ensure the > > lock-free enabled() check ensured visibility of the initialization > of > > the data structures in the ensuing code. Otherwise you'd need to > grab > > the lock on the enabled() checks, which is too heavy-weight. The > lock is > > only used to ensure single-threaded initialization of the log_table, > > actual accesses are again lock-free. > > > > David > > > > Same with the release_store() in disable(), unless there > > > was some reason to make sure all threads saw previous stores to > > > ThreadHeapSampler related memory before _enabled was set to zero. > The > > > load_acquire in enabled() may not have been needed either, > because it > > > only prevents subsequent loads from being executed before the > load from > > > _enabled, so if _enabled was being used to guard access only to > > > ThreadHeapSampler data such as log_table, the release_store() on > > > _enabled would guarantee that all necessary stores would be done > before > > > _enabled was set to one and seen by enabled(). > > > > > > Yeah, that?s hard to follow, and I wrote it. :) It comes down to > what > > > you?re guarding with OrderAccess. If it?s only ThreadHeapSampler > data, > > > and since only a Thread has one, and since ThreadHeapSampler > statics are > > > initialized before construction of the first _heap_sampler, and > since > > > the construction of a Thread is guarded by multiple mutexes which > will > > > force visibility of any ThreadHeapSampler statics before a Thread > is > > > used, you don?t need OrderAccess. > > > > > > I?d put anything to do with ThreadHeapSampler into its class > definition > > > rather than define them at file scope in threadHeapSampler.cpp. > I.e., > > > all of FastLogNumBits, FastLogMask, and internal_log_table (and > name it > > > back to that log_table). File scope data is a no-no. > > > > > > Hope this helps, > > > > > > Paul > > > > > > *From: *serviceability-dev < > serviceability-dev-bounces at openjdk.java.net> > > > on behalf of JC Beyler > > > *Date: *Tuesday, October 9, 2018 at 11:58 PM > > > *To: *"serviceability-dev at openjdk.java.net" > > > > > > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > > > enable/disable/enabled methods > > > > > > Hi all, > > > > > > When talking with Serguei about JDK-8201655 > > > , we talked > about why > > > ThreadHeapSampler has an enabled/disabled when we could have just > used > > > the should_post_sampled_object_alloc to begin with. > > > > > > Could I get a review for this: > > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > > > > > This passed my testing on my dev machine in release and fastdebug. > > > > > > The question I would like to raise here at the same time (in > order to > > > reduce email spam and because it should be included in the review > I > > > believe) is: > > > > > > - When I did the enable/disable, I used OrderAccess to do so > after a > > > reviewer asked for it > > > > > > - From what I can tell, JVMTI_SUPPORT_FLAG does not use it and > does > > > instead: > > > > > > #define JVMTI_SUPPORT_FLAG(key) > \ > > > > > > private: > \ > > > > > > static bool _##key; > \ > > > > > > public: > \ > > > > > > inline static void set_##key(bool on) { > \ > > > > > > JVMTI_ONLY(_##key = (on != 0)); > \ > > > > > > NOT_JVMTI(report_unsupported(on)); > \ > > > > > > } > \ > > > > > > inline static bool key() { > \ > > > > > > JVMTI_ONLY(return _##key); > \ > > > > > > NOT_JVMTI(return false); > \ > > > > > > } > > > > > > Should it (ie in a future bug/webrev)? > > > > > > Thanks, > > > > > > Jc > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Oct 11 22:24:41 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Oct 2018 08:24:41 +1000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> <889efd38-ffea-96be-a767-a14b10412e76@oracle.com> Message-ID: On 12/10/2018 8:20 AM, JC Beyler wrote: > I'm 100% in agreement with David :) > > Inlined are my comments: > > On Thu, Oct 11, 2018 at 3:13 PM David Holmes > wrote: > > On 12/10/2018 3:44 AM, Hohensee, Paul wrote: > > So, given that the lock was only used to protect log_table > initialization, and that the patch moves that into the C++ "class > initializer" which is run when the first Thread object is > constructed, we don't need any locking/memory ordering anymore, right? > > Right so: > > - ThreadHeapSampler_lock can be removed > - The load-acquire/release-store of _sampling_interval seem to serve no > purpose, but _sampling_interval should at least be marked volatile > (from > a documentation perspective if nothing else). If the intent was for a > change in sampling_interval to be immediately visible then a fence() > would be needed. > > > Right, I would leave them in place (or at least postpone the > conversation about them to a later webrev if someone feels really > strongly about them; I believe it does not hurt, this will never be > critical code but at least is semantically safe). Please deleted the unused ThreadHeapSampler_lock. Please mark _sampling_interval as volatile. > > The _log_table_initialized flag is not needed from the perspective > of an > initialization check - you can't run code until after the static > initializers have run (though I'm unclear how C++ manages this from a > concurrency perspective). But the flag may be needed just as a means to > separate the allocation of the table from the initialization of it - > again I'm unclear how C++ static initialization works in detail (you > have to be very careful with such initialization to ensure there are > zero dependencies on anything done as part of VM initialization). > > > Exactly. I cannot force the initialization of a static array via a > method without initialization *something*. It can be to initialize a > pointer to the array and I just use the pointer in the class; that was > what the first webrev one was doing. Using a boolean such as here seems > to be the lesser evil and allows us to add an assert that all is well in > the world at the only usage point of the array in assert mode. > > So I'm happy with the current form (I'm biased since I sent the webrev > for review :-)), any LGTM or other comments? I can't comment on the details of the code just the general structural changes, and they seem okay to me. Thanks, David > Jc > > David > > > Paul > > > > ?On 10/11/18, 4:11 AM, "David Holmes" > wrote: > > > >? ? ? On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > >? ? ? > There used to be a rule against using ?namespace?. Don?t > know if that?s > >? ? ? > still true or not: I believe it is. Hence the ?static > const ?. > >? ? ? > > >? ? ? > You only need OrderAccess if there could be a race on > accesses to > >? ? ? > whatever you?re guarding. Looks like the old code wanted > to make sure > >? ? ? > that log_table was initialized and its content available > to other > >? ? ? > threads before the _enabled flag was set. I.e., the > _enabled flag acted > >? ? ? > as a store visibility barrier for log_table, and possibly > other > >? ? ? > ThreadHeapSampler data structures. If no thread can ever > see a partially > >? ? ? > initialized log_table, then no need for ordering. The old > code used a > >? ? ? > MutexLocker in init_log_table(), which former has a fence > in its > >? ? ? > destructor and probably (haven?t dived into the code) > guards all > >? ? ? > accesses to log_table, so the release_store() on _enabled > in enable() > >? ? ? > was redundant. > > > >? ? ? The release_store and load_acquire were necessary to ensure the > >? ? ? lock-free enabled() check ensured visibility of the > initialization of > >? ? ? the data structures in the ensuing code. Otherwise you'd > need to grab > >? ? ? the lock on the enabled() checks, which is too heavy-weight. > The lock is > >? ? ? only used to ensure single-threaded initialization of the > log_table, > >? ? ? actual accesses are again lock-free. > > > >? ? ? David > > > >? ? ? ? Same with the release_store() in disable(), unless there > >? ? ? > was some reason to make sure all threads saw previous > stores to > >? ? ? > ThreadHeapSampler related memory before _enabled was set > to zero. The > >? ? ? > load_acquire in enabled() may not have been needed either, > because it > >? ? ? > only prevents subsequent loads from being executed before > the load from > >? ? ? > _enabled, so if _enabled was being used to guard access > only to > >? ? ? > ThreadHeapSampler data such as log_table, the > release_store() on > >? ? ? > _enabled would guarantee that all necessary stores would > be done before > >? ? ? > _enabled was set to one and seen by enabled(). > >? ? ? > > >? ? ? > Yeah, that?s hard to follow, and I wrote it. :) It comes > down to what > >? ? ? > you?re guarding with OrderAccess. If it?s only > ThreadHeapSampler data, > >? ? ? > and since only a Thread has one, and since > ThreadHeapSampler statics are > >? ? ? > initialized before construction of the first > _heap_sampler, and since > >? ? ? > the construction of a Thread is guarded by multiple > mutexes which will > >? ? ? > force visibility of any ThreadHeapSampler statics before a > Thread is > >? ? ? > used, you don?t need OrderAccess. > >? ? ? > > >? ? ? > I?d put anything to do with ThreadHeapSampler into its > class definition > >? ? ? > rather than define them at file scope in > threadHeapSampler.cpp. I.e., > >? ? ? > all of FastLogNumBits, FastLogMask, and internal_log_table > (and name it > >? ? ? > back to that log_table). File scope data is a no-no. > >? ? ? > > >? ? ? > Hope this helps, > >? ? ? > > >? ? ? > Paul > >? ? ? > > >? ? ? > *From: *serviceability-dev > > > >? ? ? > on behalf of JC Beyler > > >? ? ? > *Date: *Tuesday, October 9, 2018 at 11:58 PM > >? ? ? > *To: *"serviceability-dev at openjdk.java.net > " > >? ? ? > > > >? ? ? > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > >? ? ? > enable/disable/enabled methods > >? ? ? > > >? ? ? > Hi all, > >? ? ? > > >? ? ? > When talking with Serguei about JDK-8201655 > >? ? ? > , we > talked about why > >? ? ? > ThreadHeapSampler has an enabled/disabled when we could > have just used > >? ? ? > the should_post_sampled_object_alloc to begin with. > >? ? ? > > >? ? ? > Could I get a review for this: > >? ? ? > > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > >? ? ? > > >? ? ? > > >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > >? ? ? > > >? ? ? > This passed my testing on my dev machine in release and > fastdebug. > >? ? ? > > >? ? ? > The question I would like to raise here at the same time > (in order to > >? ? ? > reduce email spam and because it should be included in the > review I > >? ? ? > believe) is: > >? ? ? > > >? ? ? >? ? - When I did the enable/disable, I used OrderAccess to > do so after a > >? ? ? > reviewer asked for it > >? ? ? > > >? ? ? >? ? - From what I can tell, JVMTI_SUPPORT_FLAG does not use > it and does > >? ? ? > instead: > >? ? ? > > >? ? ? > #define JVMTI_SUPPORT_FLAG(key) > ? ? ? ? ? ? ? ?\ > >? ? ? > > >? ? ? >? ? private: > ? ? ? ? ? ? ? ? \ > >? ? ? > > >? ? ? >? ? static bool? _##key; > ? ? ? ? ? ? ? ? \ > >? ? ? > > >? ? ? >? ? public: > ? ? ? ? ? ? ? ? ?\ > >? ? ? > > >? ? ? >? ? inline static void set_##key(bool on) { > ? ? ? ? ? ? ? ? ?\ > >? ? ? > > >? ? ? >? ? ? JVMTI_ONLY(_##key = (on != 0)); > ? ? ? ? ? ? ? ? ?\ > >? ? ? > > >? ? ? >? ? ? NOT_JVMTI(report_unsupported(on)); > ? ? ? ? ? ? ? ? \ > >? ? ? > > >? ? ? >? ? } > ? ? ? ? ? ? ? ? ?\ > >? ? ? > > >? ? ? >? ? inline static bool key() { > ? ? ? ? ? ? ? ? \ > >? ? ? > > >? ? ? >? ? ? JVMTI_ONLY(return _##key); > ? ? ? ? ? ? ? ? \ > >? ? ? > > >? ? ? >? ? ? NOT_JVMTI(return false); > ? ? ? ? ? ? ? ? \ > >? ? ? > > >? ? ? >? ? } > >? ? ? > > >? ? ? > Should it (ie in a future bug/webrev)? > >? ? ? > > >? ? ? > Thanks, > >? ? ? > > >? ? ? > Jc > >? ? ? > > > > > > > > > -- > > Thanks, > Jc From erik.joelsson at oracle.com Thu Oct 11 22:29:38 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Oct 2018 15:29:38 -0700 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 Message-ID: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> Hello, (adding serviceability-dev and hotspot-dev for test changes) Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From ihse-runtestprebuilt-branch in jdk-sandbox) In order to fully adopt the new run-test framework, we need to switch over the automated and distributed testing system at Oracle to the new framework. To get this to work, there are number of issues that needed to be fixed. Here follows a brief explanation, see bug for more details. For RunTest.gmk and related makefiles there are a number of minor tweaks to support all the necessary control variables that are currently used for the old test makefiles, as well as correcting some test setup settings. In addition to that, some tests also needed to be modified: Timeouts The current default timeoutFactor in the makefiles is 4. However, the old Mach5 executor overrides that to 10. I don't think it should dabble with such things and leave it to the makefiles, the user, or a specific job definition, so with the new run-test executor, it no longer does. This means many tests now have a much shorter effective timeout. Because of this, we need to increase the timeout on some that are now prone to timing out. I have run tier1-5 a few times to try and find these and added /timeout=300 (which will result in the same effective timeout as before) when specific tests seemed problematic. test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java This test spawns a child process and tries to locate it using the attach api, by looking for a unique token in the command line string of the spawned JVM. The problem is that the command line string it gets from the attach api is truncated and the token is last on the command line. This normally works well, but the arguments before it are 3 files, with full absolute paths inside the jtreg work directory. With Mach5 we have pretty deep work directories, and with run-test, we make them even deeper. This unfortunately trips the limit and the test fails. I have fixed this by reordering the arguments to the child process. /Erik From jcbeyler at google.com Thu Oct 11 22:37:18 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 11 Oct 2018 15:37:18 -0700 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> <889efd38-ffea-96be-a767-a14b10412e76@oracle.com> Message-ID: Hi all, @David: I did your two requests for volatile and removing the lock The latest webrev is now: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.02 Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 Thanks, Jc On Thu, Oct 11, 2018 at 3:24 PM David Holmes wrote: > On 12/10/2018 8:20 AM, JC Beyler wrote: > > I'm 100% in agreement with David :) > > > > Inlined are my comments: > > > > On Thu, Oct 11, 2018 at 3:13 PM David Holmes > > wrote: > > > > On 12/10/2018 3:44 AM, Hohensee, Paul wrote: > > > So, given that the lock was only used to protect log_table > > initialization, and that the patch moves that into the C++ "class > > initializer" which is run when the first Thread object is > > constructed, we don't need any locking/memory ordering anymore, > right? > > > > Right so: > > > > - ThreadHeapSampler_lock can be removed > > - The load-acquire/release-store of _sampling_interval seem to serve > no > > purpose, but _sampling_interval should at least be marked volatile > > (from > > a documentation perspective if nothing else). If the intent was for a > > change in sampling_interval to be immediately visible then a fence() > > would be needed. > > > > > > Right, I would leave them in place (or at least postpone the > > conversation about them to a later webrev if someone feels really > > strongly about them; I believe it does not hurt, this will never be > > critical code but at least is semantically safe). > > Please deleted the unused ThreadHeapSampler_lock. > > Please mark _sampling_interval as volatile. > > > > > The _log_table_initialized flag is not needed from the perspective > > of an > > initialization check - you can't run code until after the static > > initializers have run (though I'm unclear how C++ manages this from a > > concurrency perspective). But the flag may be needed just as a means > to > > separate the allocation of the table from the initialization of it - > > again I'm unclear how C++ static initialization works in detail (you > > have to be very careful with such initialization to ensure there are > > zero dependencies on anything done as part of VM initialization). > > > > > > Exactly. I cannot force the initialization of a static array via a > > method without initialization *something*. It can be to initialize a > > pointer to the array and I just use the pointer in the class; that was > > what the first webrev one was doing. Using a boolean such as here seems > > to be the lesser evil and allows us to add an assert that all is well in > > the world at the only usage point of the array in assert mode. > > > > So I'm happy with the current form (I'm biased since I sent the webrev > > for review :-)), any LGTM or other comments? > > I can't comment on the details of the code just the general structural > changes, and they seem okay to me. > > Thanks, > David > > > Jc > > > > David > > > > > Paul > > > > > > ?On 10/11/18, 4:11 AM, "David Holmes" > > wrote: > > > > > > On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > > > > There used to be a rule against using ?namespace?. Don?t > > know if that?s > > > > still true or not: I believe it is. Hence the ?static > > const ?. > > > > > > > > You only need OrderAccess if there could be a race on > > accesses to > > > > whatever you?re guarding. Looks like the old code wanted > > to make sure > > > > that log_table was initialized and its content available > > to other > > > > threads before the _enabled flag was set. I.e., the > > _enabled flag acted > > > > as a store visibility barrier for log_table, and possibly > > other > > > > ThreadHeapSampler data structures. If no thread can ever > > see a partially > > > > initialized log_table, then no need for ordering. The old > > code used a > > > > MutexLocker in init_log_table(), which former has a fence > > in its > > > > destructor and probably (haven?t dived into the code) > > guards all > > > > accesses to log_table, so the release_store() on _enabled > > in enable() > > > > was redundant. > > > > > > The release_store and load_acquire were necessary to ensure > the > > > lock-free enabled() check ensured visibility of the > > initialization of > > > the data structures in the ensuing code. Otherwise you'd > > need to grab > > > the lock on the enabled() checks, which is too heavy-weight. > > The lock is > > > only used to ensure single-threaded initialization of the > > log_table, > > > actual accesses are again lock-free. > > > > > > David > > > > > > Same with the release_store() in disable(), unless there > > > > was some reason to make sure all threads saw previous > > stores to > > > > ThreadHeapSampler related memory before _enabled was set > > to zero. The > > > > load_acquire in enabled() may not have been needed either, > > because it > > > > only prevents subsequent loads from being executed before > > the load from > > > > _enabled, so if _enabled was being used to guard access > > only to > > > > ThreadHeapSampler data such as log_table, the > > release_store() on > > > > _enabled would guarantee that all necessary stores would > > be done before > > > > _enabled was set to one and seen by enabled(). > > > > > > > > Yeah, that?s hard to follow, and I wrote it. :) It comes > > down to what > > > > you?re guarding with OrderAccess. If it?s only > > ThreadHeapSampler data, > > > > and since only a Thread has one, and since > > ThreadHeapSampler statics are > > > > initialized before construction of the first > > _heap_sampler, and since > > > > the construction of a Thread is guarded by multiple > > mutexes which will > > > > force visibility of any ThreadHeapSampler statics before a > > Thread is > > > > used, you don?t need OrderAccess. > > > > > > > > I?d put anything to do with ThreadHeapSampler into its > > class definition > > > > rather than define them at file scope in > > threadHeapSampler.cpp. I.e., > > > > all of FastLogNumBits, FastLogMask, and internal_log_table > > (and name it > > > > back to that log_table). File scope data is a no-no. > > > > > > > > Hope this helps, > > > > > > > > Paul > > > > > > > > *From: *serviceability-dev > > > > > > > > on behalf of JC Beyler > > > > > > *Date: *Tuesday, October 9, 2018 at 11:58 PM > > > > *To: *"serviceability-dev at openjdk.java.net > > " > > > > > > > > > > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > > > > enable/disable/enabled methods > > > > > > > > Hi all, > > > > > > > > When talking with Serguei about JDK-8201655 > > > > , we > > talked about why > > > > ThreadHeapSampler has an enabled/disabled when we could > > have just used > > > > the should_post_sampled_object_alloc to begin with. > > > > > > > > Could I get a review for this: > > > > > > > > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > > > > > > > This passed my testing on my dev machine in release and > > fastdebug. > > > > > > > > The question I would like to raise here at the same time > > (in order to > > > > reduce email spam and because it should be included in the > > review I > > > > believe) is: > > > > > > > > - When I did the enable/disable, I used OrderAccess to > > do so after a > > > > reviewer asked for it > > > > > > > > - From what I can tell, JVMTI_SUPPORT_FLAG does not use > > it and does > > > > instead: > > > > > > > > #define JVMTI_SUPPORT_FLAG(key) > > \ > > > > > > > > private: > > \ > > > > > > > > static bool _##key; > > \ > > > > > > > > public: > > \ > > > > > > > > inline static void set_##key(bool on) { > > \ > > > > > > > > JVMTI_ONLY(_##key = (on != 0)); > > \ > > > > > > > > NOT_JVMTI(report_unsupported(on)); > > \ > > > > > > > > } > > \ > > > > > > > > inline static bool key() { > > \ > > > > > > > > JVMTI_ONLY(return _##key); > > \ > > > > > > > > NOT_JVMTI(return false); > > \ > > > > > > > > } > > > > > > > > Should it (ie in a future bug/webrev)? > > > > > > > > Thanks, > > > > > > > > Jc > > > > > > > > > > > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Oct 11 22:40:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Oct 2018 08:40:34 +1000 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> Message-ID: Hi Erik, On 12/10/2018 8:29 AM, Erik Joelsson wrote: > Hello, > > (adding serviceability-dev and hotspot-dev for test changes) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 > > Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html > (From ihse-runtestprebuilt-branch in jdk-sandbox) > > In order to fully adopt the new run-test framework, we need to switch > over the automated and distributed testing system at Oracle to the new > framework. To get this to work, there are number of issues that needed > to be fixed. Here follows a brief explanation, see bug for more details. > > For RunTest.gmk and related makefiles there are a number of minor tweaks > to support all the necessary control variables that are currently used > for the old test makefiles, as well as correcting some test setup settings. > > In addition to that, some tests also needed to be modified: > > Timeouts > The current default timeoutFactor in the makefiles is 4. However, the > old Mach5 executor overrides that to 10. I don't think it should dabble > with such things and leave it to the makefiles, the user, or a specific > job definition, so with the new run-test executor, it no longer does. > This means many tests now have a much shorter effective timeout. Because > of this, we need to increase the timeout on some that are now prone to > timing out. I have run tier1-5 a few times to try and find these and > added /timeout=300 (which will result in the same effective timeout as > before) when specific tests seemed problematic. This should be fixed in the tier job definitions not the individual tests. We have moved away from putting explicit timeouts on individual tests and instead rely on the framework timeout being set appropriately. David ----- > test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java > This test spawns a child process and tries to locate it using the attach > api, by looking for a unique token in the command line string of the > spawned JVM. The problem is that the command line string it gets from > the attach api is truncated and the token is last on the command line. > This normally works well, but the arguments before it are 3 files, with > full absolute paths inside the jtreg work directory. With Mach5 we have > pretty deep work directories, and with run-test, we make them even > deeper. This unfortunately trips the limit and the test fails. I have > fixed this by reordering the arguments to the child process. > > /Erik > From david.holmes at oracle.com Thu Oct 11 22:42:23 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Oct 2018 08:42:23 +1000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> <889efd38-ffea-96be-a767-a14b10412e76@oracle.com> Message-ID: <6a705566-da97-dacb-4d1f-97d55a47a86a@oracle.com> Thanks those updates look fine. David On 12/10/2018 8:37 AM, JC Beyler wrote: > Hi all, > > @David: I did your two requests for volatile and removing the lock > > The latest webrev is now: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.02 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > Thanks, > Jc > > On Thu, Oct 11, 2018 at 3:24 PM David Holmes > wrote: > > On 12/10/2018 8:20 AM, JC Beyler wrote: > > I'm 100% in agreement with David :) > > > > Inlined are my comments: > > > > On Thu, Oct 11, 2018 at 3:13 PM David Holmes > > > >> wrote: > > > >? ? ?On 12/10/2018 3:44 AM, Hohensee, Paul wrote: > >? ? ? > So, given that the lock was only used to protect log_table > >? ? ?initialization, and that the patch moves that into the C++ "class > >? ? ?initializer" which is run when the first Thread object is > >? ? ?constructed, we don't need any locking/memory ordering > anymore, right? > > > >? ? ?Right so: > > > >? ? ?- ThreadHeapSampler_lock can be removed > >? ? ?- The load-acquire/release-store of _sampling_interval seem > to serve no > >? ? ?purpose, but _sampling_interval should at least be marked > volatile > >? ? ?(from > >? ? ?a documentation perspective if nothing else). If the intent > was for a > >? ? ?change in sampling_interval to be immediately visible then a > fence() > >? ? ?would be needed. > > > > > > Right, I would leave them in place (or at least postpone the > > conversation about them to a later webrev if someone feels really > > strongly about them; I believe it does not hurt, this will never be > > critical code but at least is semantically safe). > > Please deleted the unused ThreadHeapSampler_lock. > > Please mark _sampling_interval as volatile. > > > > > >? ? ?The _log_table_initialized flag is not needed from the > perspective > >? ? ?of an > >? ? ?initialization check - you can't run code until after the static > >? ? ?initializers have run (though I'm unclear how C++ manages > this from a > >? ? ?concurrency perspective). But the flag may be needed just as > a means to > >? ? ?separate the allocation of the table from the initialization > of it - > >? ? ?again I'm unclear how C++ static initialization works in > detail (you > >? ? ?have to be very careful with such initialization to ensure > there are > >? ? ?zero dependencies on anything done as part of VM initialization). > > > > > > Exactly. I cannot force the initialization of a static array via a > > method without initialization *something*. It can be to initialize a > > pointer to the array and I just use the pointer in the class; > that was > > what the first webrev one was doing. Using a boolean such as here > seems > > to be the lesser evil and allows us to add an assert that all is > well in > > the world at the only usage point of the array in assert mode. > > > > So I'm happy with the current form (I'm biased since I sent the > webrev > > for review :-)), any LGTM or other comments? > > I can't comment on the details of the code just the general structural > changes, and they seem okay to me. > > Thanks, > David > > > Jc > > > >? ? ?David > > > >? ? ? > Paul > >? ? ? > > >? ? ? > ?On 10/11/18, 4:11 AM, "David Holmes" > > >? ? ? >> wrote: > >? ? ? > > >? ? ? >? ? ? On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > >? ? ? >? ? ? > There used to be a rule against using ?namespace?. > Don?t > >? ? ?know if that?s > >? ? ? >? ? ? > still true or not: I believe it is. Hence the ?static > >? ? ?const ?. > >? ? ? >? ? ? > > >? ? ? >? ? ? > You only need OrderAccess if there could be a race on > >? ? ?accesses to > >? ? ? >? ? ? > whatever you?re guarding. Looks like the old code > wanted > >? ? ?to make sure > >? ? ? >? ? ? > that log_table was initialized and its content > available > >? ? ?to other > >? ? ? >? ? ? > threads before the _enabled flag was set. I.e., the > >? ? ?_enabled flag acted > >? ? ? >? ? ? > as a store visibility barrier for log_table, and > possibly > >? ? ?other > >? ? ? >? ? ? > ThreadHeapSampler data structures. If no thread can > ever > >? ? ?see a partially > >? ? ? >? ? ? > initialized log_table, then no need for ordering. > The old > >? ? ?code used a > >? ? ? >? ? ? > MutexLocker in init_log_table(), which former has a > fence > >? ? ?in its > >? ? ? >? ? ? > destructor and probably (haven?t dived into the code) > >? ? ?guards all > >? ? ? >? ? ? > accesses to log_table, so the release_store() on > _enabled > >? ? ?in enable() > >? ? ? >? ? ? > was redundant. > >? ? ? > > >? ? ? >? ? ? The release_store and load_acquire were necessary to > ensure the > >? ? ? >? ? ? lock-free enabled() check ensured visibility of the > >? ? ?initialization of > >? ? ? >? ? ? the data structures in the ensuing code. Otherwise you'd > >? ? ?need to grab > >? ? ? >? ? ? the lock on the enabled() checks, which is too > heavy-weight. > >? ? ?The lock is > >? ? ? >? ? ? only used to ensure single-threaded initialization of the > >? ? ?log_table, > >? ? ? >? ? ? actual accesses are again lock-free. > >? ? ? > > >? ? ? >? ? ? David > >? ? ? > > >? ? ? >? ? ? ? Same with the release_store() in disable(), unless > there > >? ? ? >? ? ? > was some reason to make sure all threads saw previous > >? ? ?stores to > >? ? ? >? ? ? > ThreadHeapSampler related memory before _enabled > was set > >? ? ?to zero. The > >? ? ? >? ? ? > load_acquire in enabled() may not have been needed > either, > >? ? ?because it > >? ? ? >? ? ? > only prevents subsequent loads from being executed > before > >? ? ?the load from > >? ? ? >? ? ? > _enabled, so if _enabled was being used to guard access > >? ? ?only to > >? ? ? >? ? ? > ThreadHeapSampler data such as log_table, the > >? ? ?release_store() on > >? ? ? >? ? ? > _enabled would guarantee that all necessary stores > would > >? ? ?be done before > >? ? ? >? ? ? > _enabled was set to one and seen by enabled(). > >? ? ? >? ? ? > > >? ? ? >? ? ? > Yeah, that?s hard to follow, and I wrote it. :) It > comes > >? ? ?down to what > >? ? ? >? ? ? > you?re guarding with OrderAccess. If it?s only > >? ? ?ThreadHeapSampler data, > >? ? ? >? ? ? > and since only a Thread has one, and since > >? ? ?ThreadHeapSampler statics are > >? ? ? >? ? ? > initialized before construction of the first > >? ? ?_heap_sampler, and since > >? ? ? >? ? ? > the construction of a Thread is guarded by multiple > >? ? ?mutexes which will > >? ? ? >? ? ? > force visibility of any ThreadHeapSampler statics > before a > >? ? ?Thread is > >? ? ? >? ? ? > used, you don?t need OrderAccess. > >? ? ? >? ? ? > > >? ? ? >? ? ? > I?d put anything to do with ThreadHeapSampler into its > >? ? ?class definition > >? ? ? >? ? ? > rather than define them at file scope in > >? ? ?threadHeapSampler.cpp. I.e., > >? ? ? >? ? ? > all of FastLogNumBits, FastLogMask, and > internal_log_table > >? ? ?(and name it > >? ? ? >? ? ? > back to that log_table). File scope data is a no-no. > >? ? ? >? ? ? > > >? ? ? >? ? ? > Hope this helps, > >? ? ? >? ? ? > > >? ? ? >? ? ? > Paul > >? ? ? >? ? ? > > >? ? ? >? ? ? > *From: *serviceability-dev > >? ? ? > >? ? ? >> > >? ? ? >? ? ? > on behalf of JC Beyler > >? ? ?>> > >? ? ? >? ? ? > *Date: *Tuesday, October 9, 2018 at 11:58 PM > >? ? ? >? ? ? > *To: *"serviceability-dev at openjdk.java.net > > >? ? ? >" > >? ? ? >? ? ? > > >? ? ? >> > >? ? ? >? ? ? > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > >? ? ? >? ? ? > enable/disable/enabled methods > >? ? ? >? ? ? > > >? ? ? >? ? ? > Hi all, > >? ? ? >? ? ? > > >? ? ? >? ? ? > When talking with Serguei about JDK-8201655 > >? ? ? >? ? ? > , we > >? ? ?talked about why > >? ? ? >? ? ? > ThreadHeapSampler has an enabled/disabled when we could > >? ? ?have just used > >? ? ? >? ? ? > the should_post_sampled_object_alloc to begin with. > >? ? ? >? ? ? > > >? ? ? >? ? ? > Could I get a review for this: > >? ? ? >? ? ? > > >? ? ? >? ? ? > Webrev: > > http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > >? ? ? > >? ? ? >? ? ? > > > >? ? ? >? ? ? > > >? ? ? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > >? ? ? >? ? ? > > >? ? ? >? ? ? > This passed my testing on my dev machine in release and > >? ? ?fastdebug. > >? ? ? >? ? ? > > >? ? ? >? ? ? > The question I would like to raise here at the same > time > >? ? ?(in order to > >? ? ? >? ? ? > reduce email spam and because it should be included > in the > >? ? ?review I > >? ? ? >? ? ? > believe) is: > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? - When I did the enable/disable, I used > OrderAccess to > >? ? ?do so after a > >? ? ? >? ? ? > reviewer asked for it > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? - From what I can tell, JVMTI_SUPPORT_FLAG does > not use > >? ? ?it and does > >? ? ? >? ? ? > instead: > >? ? ? >? ? ? > > >? ? ? >? ? ? > #define JVMTI_SUPPORT_FLAG(key) > >? ? ? ? ? ? ? ? ? ? ?\ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? private: > >? ? ? ? ? ? ? ? ? ? ? \ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? static bool? _##key; > >? ? ? ? ? ? ? ? ? ? ? \ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? public: > >? ? ? ? ? ? ? ? ? ? ? ?\ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? inline static void set_##key(bool on) { > >? ? ? ? ? ? ? ? ? ? ? ?\ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? JVMTI_ONLY(_##key = (on != 0)); > >? ? ? ? ? ? ? ? ? ? ? ?\ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? NOT_JVMTI(report_unsupported(on)); > >? ? ? ? ? ? ? ? ? ? ? \ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? } > >? ? ? ? ? ? ? ? ? ? ? ?\ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? inline static bool key() { > >? ? ? ? ? ? ? ? ? ? ? \ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? JVMTI_ONLY(return _##key); > >? ? ? ? ? ? ? ? ? ? ? \ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? ? NOT_JVMTI(return false); > >? ? ? ? ? ? ? ? ? ? ? \ > >? ? ? >? ? ? > > >? ? ? >? ? ? >? ? } > >? ? ? >? ? ? > > >? ? ? >? ? ? > Should it (ie in a future bug/webrev)? > >? ? ? >? ? ? > > >? ? ? >? ? ? > Thanks, > >? ? ? >? ? ? > > >? ? ? >? ? ? > Jc > >? ? ? >? ? ? > > >? ? ? > > >? ? ? > > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From hohensee at amazon.com Thu Oct 11 22:44:11 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Oct 2018 22:44:11 +0000 Subject: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods In-Reply-To: References: <76782C66-2F32-4BAC-8F01-C0105274EB40@amazon.com> <2F4FFA07-272E-4FFF-8C05-041E9F3B9FB5@amazon.com> <889efd38-ffea-96be-a767-a14b10412e76@oracle.com> Message-ID: Looks good to me. Paul From: JC Beyler Date: Thursday, October 11, 2018 at 6:38 PM To: David Holmes Cc: "Hohensee, Paul" , "serviceability-dev at openjdk.java.net" Subject: Re: RFR (S) 8211980: Remove ThreadHeapSampler enable/disable/enabled methods Hi all, @David: I did your two requests for volatile and removing the lock The latest webrev is now: Webrev: http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.02 Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 Thanks, Jc On Thu, Oct 11, 2018 at 3:24 PM David Holmes > wrote: On 12/10/2018 8:20 AM, JC Beyler wrote: > I'm 100% in agreement with David :) > > Inlined are my comments: > > On Thu, Oct 11, 2018 at 3:13 PM David Holmes > >> wrote: > > On 12/10/2018 3:44 AM, Hohensee, Paul wrote: > > So, given that the lock was only used to protect log_table > initialization, and that the patch moves that into the C++ "class > initializer" which is run when the first Thread object is > constructed, we don't need any locking/memory ordering anymore, right? > > Right so: > > - ThreadHeapSampler_lock can be removed > - The load-acquire/release-store of _sampling_interval seem to serve no > purpose, but _sampling_interval should at least be marked volatile > (from > a documentation perspective if nothing else). If the intent was for a > change in sampling_interval to be immediately visible then a fence() > would be needed. > > > Right, I would leave them in place (or at least postpone the > conversation about them to a later webrev if someone feels really > strongly about them; I believe it does not hurt, this will never be > critical code but at least is semantically safe). Please deleted the unused ThreadHeapSampler_lock. Please mark _sampling_interval as volatile. > > The _log_table_initialized flag is not needed from the perspective > of an > initialization check - you can't run code until after the static > initializers have run (though I'm unclear how C++ manages this from a > concurrency perspective). But the flag may be needed just as a means to > separate the allocation of the table from the initialization of it - > again I'm unclear how C++ static initialization works in detail (you > have to be very careful with such initialization to ensure there are > zero dependencies on anything done as part of VM initialization). > > > Exactly. I cannot force the initialization of a static array via a > method without initialization *something*. It can be to initialize a > pointer to the array and I just use the pointer in the class; that was > what the first webrev one was doing. Using a boolean such as here seems > to be the lesser evil and allows us to add an assert that all is well in > the world at the only usage point of the array in assert mode. > > So I'm happy with the current form (I'm biased since I sent the webrev > for review :-)), any LGTM or other comments? I can't comment on the details of the code just the general structural changes, and they seem okay to me. Thanks, David > Jc > > David > > > Paul > > > > On 10/11/18, 4:11 AM, "David Holmes" > >> wrote: > > > > On 11/10/2018 3:10 AM, Hohensee, Paul wrote: > > > There used to be a rule against using ?namespace?. Don?t > know if that?s > > > still true or not: I believe it is. Hence the ?static > const ?. > > > > > > You only need OrderAccess if there could be a race on > accesses to > > > whatever you?re guarding. Looks like the old code wanted > to make sure > > > that log_table was initialized and its content available > to other > > > threads before the _enabled flag was set. I.e., the > _enabled flag acted > > > as a store visibility barrier for log_table, and possibly > other > > > ThreadHeapSampler data structures. If no thread can ever > see a partially > > > initialized log_table, then no need for ordering. The old > code used a > > > MutexLocker in init_log_table(), which former has a fence > in its > > > destructor and probably (haven?t dived into the code) > guards all > > > accesses to log_table, so the release_store() on _enabled > in enable() > > > was redundant. > > > > The release_store and load_acquire were necessary to ensure the > > lock-free enabled() check ensured visibility of the > initialization of > > the data structures in the ensuing code. Otherwise you'd > need to grab > > the lock on the enabled() checks, which is too heavy-weight. > The lock is > > only used to ensure single-threaded initialization of the > log_table, > > actual accesses are again lock-free. > > > > David > > > > Same with the release_store() in disable(), unless there > > > was some reason to make sure all threads saw previous > stores to > > > ThreadHeapSampler related memory before _enabled was set > to zero. The > > > load_acquire in enabled() may not have been needed either, > because it > > > only prevents subsequent loads from being executed before > the load from > > > _enabled, so if _enabled was being used to guard access > only to > > > ThreadHeapSampler data such as log_table, the > release_store() on > > > _enabled would guarantee that all necessary stores would > be done before > > > _enabled was set to one and seen by enabled(). > > > > > > Yeah, that?s hard to follow, and I wrote it. :) It comes > down to what > > > you?re guarding with OrderAccess. If it?s only > ThreadHeapSampler data, > > > and since only a Thread has one, and since > ThreadHeapSampler statics are > > > initialized before construction of the first > _heap_sampler, and since > > > the construction of a Thread is guarded by multiple > mutexes which will > > > force visibility of any ThreadHeapSampler statics before a > Thread is > > > used, you don?t need OrderAccess. > > > > > > I?d put anything to do with ThreadHeapSampler into its > class definition > > > rather than define them at file scope in > threadHeapSampler.cpp. I.e., > > > all of FastLogNumBits, FastLogMask, and internal_log_table > (and name it > > > back to that log_table). File scope data is a no-no. > > > > > > Hope this helps, > > > > > > Paul > > > > > > *From: *serviceability-dev > > >> > > > on behalf of JC Beyler > >> > > > *Date: *Tuesday, October 9, 2018 at 11:58 PM > > > *To: *"serviceability-dev at openjdk.java.net > >" > > > > >> > > > *Subject: *RFR (S) 8211980: Remove ThreadHeapSampler > > > enable/disable/enabled methods > > > > > > Hi all, > > > > > > When talking with Serguei about JDK-8201655 > > > , we > talked about why > > > ThreadHeapSampler has an enabled/disabled when we could > have just used > > > the should_post_sampled_object_alloc to begin with. > > > > > > Could I get a review for this: > > > > > > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8211980/webrev.00/ > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211980 > > > > > > This passed my testing on my dev machine in release and > fastdebug. > > > > > > The question I would like to raise here at the same time > (in order to > > > reduce email spam and because it should be included in the > review I > > > believe) is: > > > > > > - When I did the enable/disable, I used OrderAccess to > do so after a > > > reviewer asked for it > > > > > > - From what I can tell, JVMTI_SUPPORT_FLAG does not use > it and does > > > instead: > > > > > > #define JVMTI_SUPPORT_FLAG(key) > \ > > > > > > private: > \ > > > > > > static bool _##key; > \ > > > > > > public: > \ > > > > > > inline static void set_##key(bool on) { > \ > > > > > > JVMTI_ONLY(_##key = (on != 0)); > \ > > > > > > NOT_JVMTI(report_unsupported(on)); > \ > > > > > > } > \ > > > > > > inline static bool key() { > \ > > > > > > JVMTI_ONLY(return _##key); > \ > > > > > > NOT_JVMTI(return false); > \ > > > > > > } > > > > > > Should it (ie in a future bug/webrev)? > > > > > > Thanks, > > > > > > Jc > > > > > > > > > > > -- > > Thanks, > Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Thu Oct 11 22:45:16 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 11 Oct 2018 22:45:16 +0000 Subject: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> Message-ID: Any takers? :) From: serviceability-dev on behalf of "Hohensee, Paul" Date: Monday, October 8, 2018 at 7:50 PM To: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" Subject: RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions Bug: https://bugs.openjdk.java.net/browse/JDK-8196989 CSR: https://bugs.openjdk.java.net/browse/JDK-8196991 Webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.02/ As requested, I split the jstat counter update off from the MXBean update. This is the MXBean update. The jstat counter RFE is https://bugs.openjdk.java.net/browse/JDK-8210965 and its CSR is https://bugs.openjdk.java.net/browse/JDK-8210966. The MXBean CSR is in draft state, I?d greatly appreciate review and sign-off. It?s been suggested that we add another pool to represent the free region set, but doing so would be incompatible with existing MXBean use invariants for all GCs. These are: 1. The sum of the pools? MemoryUsage.max properties is the total reserved heap size. 2. The sum of the pools? MemoryUsage.committed properties is the total committed size. 3. The sum of the pools? MemoryUsage.used properties is the total size of the memory containing objects, live and dead-and-yet-to-be-collected, as the case might be, plus intentional gaps between them. 4. The total free space is (sum of the max properties ? sum of the used properties). 5. The total uncommitted space is (sum of the max properties ? sum of the committed properties). 6. The total committed free space is (2) ? (3). To keep invariants 1, 2 and 3, the free region pool?s ?max? property should be ?undefined? (i.e., -1). The intuitive, to me, ?used? property value would be the total free space, but that would violate invariant 4 above. Defining the ?committed? property as the total committed free space would violate invariants 2 and 6. The patch passes the submit repo, hotspot tier1, and, separately, the serviceability, jfr, and gc jtreg tests. I?m uncertain how to construct a test that checks for valid MXBean content: the existing tests don?t. Any such test will be fragile due to possible future Hotspot changes that affect the values, and to run-to-run variability. I?ve done by-hand comparisons between the old and new MXBean content using the SwingSet2 demo, including using App CDS, and the numbers look reasonable. The guts of the change are in G1MonitoringSupport::recalculate_sizes, initialize_serviceability, memory_managers, memory_pools, and G1MonitoringScope. I also defined TraceConcMemoryManagerStats to track the concurrent cycle in a way analogous to TraceCMSMemoryManagerStats. The changes to the includes in g1FullGCOopClosures.inline.hpp and g1HeapVerifier.cpp are to satisfy compiler complaints. I changed the 3rd argument to the G1MonitoringScope constructor to a mixed_gc flag, and use accessor methods instead of direct field accesses when accessor methods exist. I believe I?ve minimized the latter. I updated the copyright date to 2018 in memoryService.hpp because I neglected to do so in my previous G1 MXBean patch. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Fri Oct 12 00:03:54 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Oct 2018 00:03:54 +0000 Subject: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Message-ID: <9D007BB7-F6FE-4A24-81BC-6629B68DEF70@amazon.com> Please review a backport to jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 The backport is slightly different from the JDK11 patch due to G1 refactoring, hence my request for new review. I?ll ask for jdk8u approval once the backport is reviewed. I backported two jtreg tests from JDK11, which pass. Also, all the hotspot gc jtreg tests pass as well as they do for jdk8u-dev. There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to be re-approved for jdk8u as well, and if so, what?s the process? Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Oct 12 00:07:11 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 11 Oct 2018 17:07:11 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD Message-ID: Please review the change that fixes the issue with missing prompt in jdb when a breakpoint is hit and the suspend policy is set to stop the thread only. Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 Thanks! --Daniil From jcbeyler at google.com Fri Oct 12 02:17:02 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 11 Oct 2018 19:17:02 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: References: Message-ID: Hi Daniil, Looks good to me. I saw a really small nit: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine)); There is a space after the '('. No need to send a new webrev for that evidently :), Jc On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov wrote: > Please review the change that fixes the issue with missing prompt in jdb > when a breakpoint is hit and the suspend policy is set to stop the thread > only. > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Thanks! > --Daniil > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 12 02:35:52 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 11 Oct 2018 19:35:52 -0700 Subject: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <9D007BB7-F6FE-4A24-81BC-6629B68DEF70@amazon.com> References: <9D007BB7-F6FE-4A24-81BC-6629B68DEF70@amazon.com> Message-ID: Hi Paul, The biggest thing I saw in this RFR was that the flags for the test: http://cr.openjdk.java.net/~phh/8195115/webrev.05/test/gc/g1/mixedgc/TestOldGenCollectionUsage.java.html were changed it seems: - the @requires are different for the backport (you accept null for JDK8 for GC and also removed the @requires vm.opt.MaxGCPauseMillis == "null") - the @run flags are different (-Xms/Xmx are 14m for the backport; they were 12 originally; there is a comment below in the backport saying this requires normally 12m though you ask for 14 in the @run) What are the reasons for these differences? Apart from that, the backport seemed ok but I'm not that well versed in the GC changes :) Jc On Thu, Oct 11, 2018 at 5:04 PM Hohensee, Paul wrote: > Please review a backport to jdk8u. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 > > Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ > > JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 > > > > The backport is slightly different from the JDK11 patch due to G1 > refactoring, hence my request for new review. I?ll ask for jdk8u approval > once the backport is reviewed. > > > > I backported two jtreg tests from JDK11, which pass. Also, all the hotspot > gc jtreg tests pass as well as they do for jdk8u-dev. > > > > There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. > Does that have to be re-approved for jdk8u as well, and if so, what?s the > process? > > > > Thanks, > > > > Paul > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Oct 12 03:02:26 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 11 Oct 2018 20:02:26 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: References: Message-ID: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> Thank you, ?JC! Please review an updated version of the patch that fixes newly added test for Windows platform ?(now it uses system dependent line separator string). Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 Best regards, --Daniil From: JC Beyler Date: Thursday, October 11, 2018 at 7:17 PM To: Cc: Subject: Re: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD Hi Daniil, Looks good to me. I saw a really small nit: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine)); There is a space after the '('. No need to send a new webrev for that evidently :), Jc On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov wrote: Please review the change that fixes the issue with missing prompt in jdb when a breakpoint is hit and the suspend policy is set to stop the thread only. Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 Thanks! --Daniil -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From fairoz.matte at oracle.com Fri Oct 12 04:37:21 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Fri, 12 Oct 2018 04:37:21 +0000 (UTC) Subject: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation In-Reply-To: References: <6845e4a5-d103-4f8f-9a34-390d83f75014@default> Message-ID: Hi JC, Thanks for looking into it. I have moved two methods (getTestSourcePath and parseBreakpoints) into Utils (existing helper class) class as part of testlibrary framework. Now it makes sense to have both the methods as public. Updated webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.01/ Thanks, Fairoz From: JC Beyler Sent: Thursday, October 11, 2018 9:23 PM To: Fairoz Matte Cc: serviceability-dev at openjdk.java.net Subject: Re: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation Hi Fairoz, The backport looks good to me (not a reviewer though) but I was wondering why you are porting the two methods (getTestSourcePath and parseBreakpoints) into this test? If we port other tests that would require it, would we be doing the same or factorizing the methods into a helper class ? Last nit, those methods could be private no? Thanks, Jc On Thu, Oct 11, 2018 at 6:22 AM Fairoz Matte wrote: Hi, Kindly review the backport of "JDK-8193879: Java debugger hangs on method invocation" to 8u Code is almost cleanly applied, test case has been modified to fit into the JDK8 test framework. Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8193879 JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/218b5b64f102 Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025365.html Thanks, Fairoz -- Thanks, Jc From fairoz.matte at oracle.com Fri Oct 12 04:38:04 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Fri, 12 Oct 2018 04:38:04 +0000 (UTC) Subject: [8u-backport] RFR: JDK-8193879: Java debugger hangs on method invocation In-Reply-To: References: <6845e4a5-d103-4f8f-9a34-390d83f75014@default> Message-ID: <91e40c47-ad70-469e-a989-514a9f0f4d78@default> Thanks Serguei for the review... > -----Original Message----- > From: Serguei Spitsyn > Sent: Thursday, October 11, 2018 10:41 PM > To: Fairoz Matte ; serviceability- > dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: JDK-8193879: Java debugger hangs on > method invocation > > Hi Fairoz, > > It looks good to me. > > Thanks, > Serguei > > > On 10/11/18 6:22 AM, Fairoz Matte wrote: > > Hi, > > > > Kindly review the backport of "JDK-8193879: Java debugger hangs on > > method invocation" to 8u Code is almost cleanly applied, test case has been > modified to fit into the JDK8 test framework. > > > > Webrev - http://cr.openjdk.java.net/~fmatte/8193879/webrev.00/ > > > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8193879 > > > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/218b5b64f102 > > > > Review thread - > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October > > /025365.html > > > > > > Thanks, > > Fairoz > From chris.plummer at oracle.com Fri Oct 12 05:00:16 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 11 Oct 2018 22:00:16 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> Message-ID: <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Fri Oct 12 08:37:07 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Oct 2018 10:37:07 +0200 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> Message-ID: <965e23c7-531d-2f9e-3c66-1d8c5a7bcdd0@oracle.com> Hi Erik, Thank you for preserving through this, so we finally can move to 100% run-test! On 2018-10-12 00:29, Erik Joelsson wrote: > Hello, > > (adding serviceability-dev and hotspot-dev for test changes) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 > > Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html > (From ihse-runtestprebuilt-branch in jdk-sandbox) Build changes look good. And I agree with the solution to add longer timeout to individual tests. > > In order to fully adopt the new run-test framework, we need to switch > over the automated and distributed testing system at Oracle to the new > framework. To get this to work, there are number of issues that needed > to be fixed. Here follows a brief explanation, see bug for more details. > > For RunTest.gmk and related makefiles there are a number of minor > tweaks to support all the necessary control variables that are > currently used for the old test makefiles, as well as correcting some > test setup settings. > > In addition to that, some tests also needed to be modified: > > Timeouts > The current default timeoutFactor in the makefiles is 4. However, the > old Mach5 executor overrides that to 10. I don't think it should > dabble with such things and leave it to the makefiles, the user, or a > specific job definition, so with the new run-test executor, it no > longer does. This means many tests now have a much shorter effective > timeout. Because of this, we need to increase the timeout on some that > are now prone to timing out. I have run tier1-5 a few times to try and > find these and added /timeout=300 (which will result in the same > effective timeout as before) when specific tests seemed problematic. > > test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java > This test spawns a child process and tries to locate it using the > attach api, by looking for a unique token in the command line string > of the spawned JVM. The problem is that the command line string it > gets from the attach api is truncated and the token is last on the > command line. This normally works well, but the arguments before it > are 3 files, with full absolute paths inside the jtreg work directory. > With Mach5 we have pretty deep work directories, and with run-test, we > make them even deeper. This unfortunately trips the limit and the test > fails. I have fixed this by reordering the arguments to the child > process. ... but I'm not sure I understand this. Is it a command-line length we're hitting? If so, how can reordering the arguments solve anything? I understand why this can preserve the token, but will not one of the paths be cut of instead? /Magnus > > /Erik > From hohensee at amazon.com Fri Oct 12 14:13:48 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Oct 2018 14:13:48 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Message-ID: <7565CED8-5174-4CB2-8AC1-F2544BD3B316@amazon.com> Thanks for the review, new webrev at http://cr.openjdk.java.net/~phh/8195115/webrev.06/. The different requires were an artifact of me trying to get TestOldGenCollectionUsage.java to run. Good catch. Jiangli changed the heap size to 14m to get it to work with CDS, see https://bugs.openjdk.java.net/browse/JDK-8210193. Paul From: JC Beyler Date: Thursday, October 11, 2018 at 10:37 PM To: "Hohensee, Paul" Cc: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" , "jdk8u-dev at openjdk.java.net" Subject: Re: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Hi Paul, The biggest thing I saw in this RFR was that the flags for the test: http://cr.openjdk.java.net/~phh/8195115/webrev.05/test/gc/g1/mixedgc/TestOldGenCollectionUsage.java.html were changed it seems: - the @requires are different for the backport (you accept null for JDK8 for GC and also removed the @requires vm.opt.MaxGCPauseMillis == "null") - the @run flags are different (-Xms/Xmx are 14m for the backport; they were 12 originally; there is a comment below in the backport saying this requires normally 12m though you ask for 14 in the @run) What are the reasons for these differences? Apart from that, the backport seemed ok but I'm not that well versed in the GC changes :) Jc On Thu, Oct 11, 2018 at 5:04 PM Hohensee, Paul > wrote: Please review a backport to jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 The backport is slightly different from the JDK11 patch due to G1 refactoring, hence my request for new review. I?ll ask for jdk8u approval once the backport is reviewed. I backported two jtreg tests from JDK11, which pass. Also, all the hotspot gc jtreg tests pass as well as they do for jdk8u-dev. There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to be re-approved for jdk8u as well, and if so, what?s the process? Thanks, Paul -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Oct 12 16:16:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Oct 2018 09:16:43 -0700 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <965e23c7-531d-2f9e-3c66-1d8c5a7bcdd0@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> <965e23c7-531d-2f9e-3c66-1d8c5a7bcdd0@oracle.com> Message-ID: <02afe047-2c6d-e902-68b4-595ca85cbad4@oracle.com> On 2018-10-12 01:37, Magnus Ihse Bursie wrote: > Hi Erik, > > Thank you for preserving through this, so we finally can move to 100% > run-test! > > On 2018-10-12 00:29, Erik Joelsson wrote: > >> Hello, >> >> (adding serviceability-dev and hotspot-dev for test changes) >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 >> >> Webrev: >> http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From >> ihse-runtestprebuilt-branch in jdk-sandbox) > Build changes look good. And I agree with the solution to add longer > timeout to individual tests. Thanks! >> >> test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java >> This test spawns a child process and tries to locate it using the >> attach api, by looking for a unique token in the command line string >> of the spawned JVM. The problem is that the command line string it >> gets from the attach api is truncated and the token is last on the >> command line. This normally works well, but the arguments before it >> are 3 files, with full absolute paths inside the jtreg work >> directory. With Mach5 we have pretty deep work directories, and with >> run-test, we make them even deeper. This unfortunately trips the >> limit and the test fails. I have fixed this by reordering the >> arguments to the child process. > ... but I'm not sure I understand this. Is it a command-line length > we're hitting? If so, how can reordering the arguments solve anything? > I understand why this can preserve the token, but will not one of the > paths be cut of instead? > I will try to be clearer. The command line is fine for running the child process. The truncation happens when the attach api is used to try to find the child process. It basically calls something that lists all JVMs on system, iterates through them and looks at the "description" field. This field happens to contain the first X characters of the command line so the test looks for the unique token it knows it put there. (I don't know the exact value of X, but could find out). Until now, X was big enough to fit the whole command line, but with the 3 absolute path files in there now growing long enough, the last argument is pushed out of the description field. This means the test process is unable to locate the child process in the list of JVMs. What then happens is the test keeps on looking, taking new snapshots of all JVMs on the system until the test finally times out. By reordering the arguments, the token is less likely to be cut out of the description field. /Erik From alexey.menkov at oracle.com Fri Oct 12 16:52:25 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 12 Oct 2018 09:52:25 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> Message-ID: <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> Hi Daniil, 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL 2) wrong indent in JdbStopThreadTest.java: 36 import lib.jdb.JdbCommand; 37 import lib.jdb.JdbTest; 3) I think it would be better to make waitForSimplePrompt property of JdbCommand (like JdbCommand.allowExit) jdb.command(JdbCommand.run().replyIsSimplePrompt()); looks much clearer than jdb.command(JdbCommand.run(), true); 4) (TTY.java) MessageOutput.lnprint("Breakpoint hit:"); + // Print current location and prompt if suspend policy is SUSPEND_EVENT_THREAD. + // In case of SUSPEND_ALL policy this is handled by vmInterrupted() method. + if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) { + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); + MessageOutput.printPrompt(); + } We have 3 separate outputs. If we have several concurrent threads, we can easy get mess of outputs from different threads. I think it would be better to print everything in a single chunk. I suppose TTY has other places with similar "non-atomic" output, so maybe revising TTY output should be handled by separate issue. --alex On 10/11/2018 22:00, Chris Plummer wrote: > Hi Daniil, > > Can you send output from an example jdb session? > > Do you think maybe we should also call printCurrentLocation() when the > suspend policy is NONE? > > There's a typo in the following line. The space is on the wrong side of > the comma. > > ? 72???????? jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine)); > > thanks, > > Chris > > On 10/11/18 8:02 PM, Daniil Titov wrote: >> >> Thank you, ?JC! >> >> Please review an updated version of the patch that fixes newly added >> test for Windows platform ?(now it uses system dependent line >> separator string). >> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >> >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Best regards, >> >> --Daniil >> >> *From: *JC Beyler >> *Date: *Thursday, October 11, 2018 at 7:17 PM >> *To: * >> *Cc: * >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint >> is hit and suspend policy is STOP_EVENT_THREAD >> >> Hi Daniil, >> >> Looks good to me. I saw a really small nit: >> >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >> >> >> 70 ?jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine)); >> >> There is a space after the '('. >> >> No need to send a new webrev for that evidently :), >> >> Jc >> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >> > wrote: >> >> Please review the change that fixes the issue with missing prompt >> in jdb when a breakpoint is hit and the suspend policy is set to >> stop the thread only. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Thanks! >> --Daniil >> >> >> >> -- >> >> Thanks, >> >> Jc >> > From magnus.ihse.bursie at oracle.com Fri Oct 12 17:07:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Oct 2018 19:07:08 +0200 Subject: RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5 In-Reply-To: <02afe047-2c6d-e902-68b4-595ca85cbad4@oracle.com> References: <457fabb0-5f30-b4dc-4e98-0853f209f3c3@oracle.com> <965e23c7-531d-2f9e-3c66-1d8c5a7bcdd0@oracle.com> <02afe047-2c6d-e902-68b4-595ca85cbad4@oracle.com> Message-ID: <84B6AC75-0A3E-489B-B7AF-D60C285AA408@oracle.com> > 12 okt. 2018 kl. 18:16 skrev Erik Joelsson : > > >> On 2018-10-12 01:37, Magnus Ihse Bursie wrote: >> Hi Erik, >> >> Thank you for preserving through this, so we finally can move to 100% run-test! >> >>> On 2018-10-12 00:29, Erik Joelsson wrote: >>> >>> Hello, >>> >>> (adding serviceability-dev and hotspot-dev for test changes) >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212028 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From ihse-runtestprebuilt-branch in jdk-sandbox) >> Build changes look good. And I agree with the solution to add longer timeout to individual tests. > Thanks! >>> >>> test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java >>> This test spawns a child process and tries to locate it using the attach api, by looking for a unique token in the command line string of the spawned JVM. The problem is that the command line string it gets from the attach api is truncated and the token is last on the command line. This normally works well, but the arguments before it are 3 files, with full absolute paths inside the jtreg work directory. With Mach5 we have pretty deep work directories, and with run-test, we make them even deeper. This unfortunately trips the limit and the test fails. I have fixed this by reordering the arguments to the child process. >> ... but I'm not sure I understand this. Is it a command-line length we're hitting? If so, how can reordering the arguments solve anything? I understand why this can preserve the token, but will not one of the paths be cut of instead? > I will try to be clearer. The command line is fine for running the child process. The truncation happens when the attach api is used to try to find the child process. It basically calls something that lists all JVMs on system, iterates through them and looks at the "description" field. This field happens to contain the first X characters of the command line so the test looks for the unique token it knows it put there. (I don't know the exact value of X, but could find out). Until now, X was big enough to fit the whole command line, but with the 3 absolute path files in there now growing long enough, the last argument is pushed out of the description field. This means the test process is unable to locate the child process in the list of JVMs. What then happens is the test keeps on looking, taking new snapshots of all JVMs on the system until the test finally times out. By reordering the arguments, the token is less likely to be cut out of the description field. > I see. Then your fix makes totally sense. /Magnus > /Erik > From daniil.x.titov at oracle.com Fri Oct 12 17:30:46 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 12 Oct 2018 10:30:46 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> Message-ID: <3EBBD8A5-B37A-4A88-AC18-DF54D7614E34@oracle.com> Hi Chris and Alex, Please find below the output of the debug session: ===BEGIN=== jdb ThreadObj Initializing jdb ... > stop thread at ThreadObj:4 Deferring breakpoint ThreadObj:4. It will be set after the class is loaded. > run run ThreadObj Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint ThreadObj:4 Breakpoint hit: "thread=main", ThreadObj.main(), line=4 bci=4 4 print(thread); > thread 1 main[1] cont > Thread[main,5,main] The application exited ===END=== The following commands were entered: 1) stop thread at ThreadObj:4 2) run 3) thread 1 4) cont We cannot call printCurrentLocation() for the case when the suspend policy is set to SUSPEND_NONE, since in this case threadInfo.getCurrentFrame() does not return the correct frame. Instead, for this case (when the suspend policy is set to SUSPEND_NONE) I plan to print the breakpoint location using the location returned by BreakPointEvent.location() method. I will also add the new test for SUSPEND_NONE suspend policy case and address Alex's suggestions in the new webrev I will send later. Thanks, Daniil ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: Hi Daniil, 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL 2) wrong indent in JdbStopThreadTest.java: 36 import lib.jdb.JdbCommand; 37 import lib.jdb.JdbTest; 3) I think it would be better to make waitForSimplePrompt property of JdbCommand (like JdbCommand.allowExit) jdb.command(JdbCommand.run().replyIsSimplePrompt()); looks much clearer than jdb.command(JdbCommand.run(), true); 4) (TTY.java) MessageOutput.lnprint("Breakpoint hit:"); + // Print current location and prompt if suspend policy is SUSPEND_EVENT_THREAD. + // In case of SUSPEND_ALL policy this is handled by vmInterrupted() method. + if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) { + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); + MessageOutput.printPrompt(); + } We have 3 separate outputs. If we have several concurrent threads, we can easy get mess of outputs from different threads. I think it would be better to print everything in a single chunk. I suppose TTY has other places with similar "non-atomic" output, so maybe revising TTY output should be handled by separate issue. --alex On 10/11/2018 22:00, Chris Plummer wrote: > Hi Daniil, > > Can you send output from an example jdb session? > > Do you think maybe we should also call printCurrentLocation() when the > suspend policy is NONE? > > There's a typo in the following line. The space is on the wrong side of > the comma. > > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine)); > > thanks, > > Chris > > On 10/11/18 8:02 PM, Daniil Titov wrote: >> >> Thank you, JC! >> >> Please review an updated version of the patch that fixes newly added >> test for Windows platform (now it uses system dependent line >> separator string). >> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >> >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Best regards, >> >> --Daniil >> >> *From: *JC Beyler >> *Date: *Thursday, October 11, 2018 at 7:17 PM >> *To: * >> *Cc: * >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint >> is hit and suspend policy is STOP_EVENT_THREAD >> >> Hi Daniil, >> >> Looks good to me. I saw a really small nit: >> >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >> >> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine)); >> >> There is a space after the '('. >> >> No need to send a new webrev for that evidently :), >> >> Jc >> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >> > wrote: >> >> Please review the change that fixes the issue with missing prompt >> in jdb when a breakpoint is hit and the suspend policy is set to >> stop the thread only. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Thanks! >> --Daniil >> >> >> >> -- >> >> Thanks, >> >> Jc >> > From chris.plummer at oracle.com Fri Oct 12 19:32:57 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 12 Oct 2018 12:32:57 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <3EBBD8A5-B37A-4A88-AC18-DF54D7614E34@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <3EBBD8A5-B37A-4A88-AC18-DF54D7614E34@oracle.com> Message-ID: Hi Daniil, Thanks for the debug session. I did make me realize one flaw. The "thread" command requires a thread number, but the breakpoint output only includes the thread name. I wonder if we could also include the thread number, although we'd have to be careful not to break any existing tests that are parsing the output. I guess the other option for the user is to use the "threads" command to map the thread name to a thread number. thanks, Chris On 10/12/18 10:30 AM, Daniil Titov wrote: > Hi Chris and Alex, > > Please find below the output of the debug session: > ===BEGIN=== > jdb ThreadObj > Initializing jdb ... >> stop thread at ThreadObj:4 > Deferring breakpoint ThreadObj:4. > It will be set after the class is loaded. >> run > run ThreadObj > Set uncaught java.lang.Throwable > Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint ThreadObj:4 > > Breakpoint hit: "thread=main", ThreadObj.main(), line=4 bci=4 > 4 print(thread); > >> thread 1 > main[1] cont >> Thread[main,5,main] > The application exited > ===END=== > > The following commands were entered: > 1) stop thread at ThreadObj:4 > 2) run > 3) thread 1 > 4) cont > > We cannot call printCurrentLocation() for the case when the suspend policy is set to SUSPEND_NONE, since in this case threadInfo.getCurrentFrame() does not return the correct frame. Instead, for this case (when the suspend policy is set to SUSPEND_NONE) I plan to print the breakpoint location using the location returned by BreakPointEvent.location() method. I will also add the new test for SUSPEND_NONE suspend policy case and address Alex's suggestions in the new webrev I will send later. > > Thanks, > Daniil > > ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: > > Hi Daniil, > > 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL > > 2) wrong indent in JdbStopThreadTest.java: > 36 import lib.jdb.JdbCommand; > 37 import lib.jdb.JdbTest; > > 3) I think it would be better to make waitForSimplePrompt property of > JdbCommand (like JdbCommand.allowExit) > > jdb.command(JdbCommand.run().replyIsSimplePrompt()); > looks much clearer than > jdb.command(JdbCommand.run(), true); > > 4) (TTY.java) > MessageOutput.lnprint("Breakpoint hit:"); > + // Print current location and prompt if suspend policy is > SUSPEND_EVENT_THREAD. > + // In case of SUSPEND_ALL policy this is handled by vmInterrupted() > method. > + if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) { > + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); > + MessageOutput.printPrompt(); > + } > We have 3 separate outputs. > If we have several concurrent threads, we can easy get mess of outputs > from different threads. > I think it would be better to print everything in a single chunk. > I suppose TTY has other places with similar "non-atomic" output, so > maybe revising TTY output should be handled by separate issue. > > --alex > > On 10/11/2018 22:00, Chris Plummer wrote: > > Hi Daniil, > > > > Can you send output from an example jdb session? > > > > Do you think maybe we should also call printCurrentLocation() when the > > suspend policy is NONE? > > > > There's a typo in the following line. The space is on the wrong side of > > the comma. > > > > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine)); > > > > thanks, > > > > Chris > > > > On 10/11/18 8:02 PM, Daniil Titov wrote: > >> > >> Thank you, JC! > >> > >> Please review an updated version of the patch that fixes newly added > >> test for Windows platform (now it uses system dependent line > >> separator string). > >> > >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ > >> > >> > >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > >> > >> Best regards, > >> > >> --Daniil > >> > >> *From: *JC Beyler > >> *Date: *Thursday, October 11, 2018 at 7:17 PM > >> *To: * > >> *Cc: * > >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint > >> is hit and suspend policy is STOP_EVENT_THREAD > >> > >> Hi Daniil, > >> > >> Looks good to me. I saw a really small nit: > >> > >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html > >> > >> > >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine)); > >> > >> There is a space after the '('. > >> > >> No need to send a new webrev for that evidently :), > >> > >> Jc > >> > >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov > >> > wrote: > >> > >> Please review the change that fixes the issue with missing prompt > >> in jdb when a breakpoint is hit and the suspend policy is set to > >> stop the thread only. > >> > >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 > >> > >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > >> > >> Thanks! > >> --Daniil > >> > >> > >> > >> -- > >> > >> Thanks, > >> > >> Jc > >> > > > > > From jcbeyler at google.com Fri Oct 12 20:40:33 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 12 Oct 2018 13:40:33 -0700 Subject: RFR (L) 8212082: Remove the NSK_CPP_STUB macros from remaining vmTestbase/jvmti/[sS]* Message-ID: Hi all, I am continuing the NSK_CPP_STUB removal with this next webrev (before last one, the next one I'll send out will be removing NSK_CPP_STUB entirely). Webrev: http://cr.openjdk.java.net/~jcbeyler/8212082/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212082 The change is still straight-forward though, since it is just doing the same NSK_CPP_STUB removal as others. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Fri Oct 12 21:16:32 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 12 Oct 2018 21:16:32 +0000 Subject: RFR (L) 8212082: Remove the NSK_CPP_STUB macros from remaining vmTestbase/jvmti/[sS]* In-Reply-To: References: Message-ID: This looks fine. Do the tests run correctly after the transform? paul From: serviceability-dev on behalf of JC Beyler Date: Friday, October 12, 2018 at 4:41 PM To: "serviceability-dev at openjdk.java.net" Subject: RFR (L) 8212082: Remove the NSK_CPP_STUB macros from remaining vmTestbase/jvmti/[sS]* Hi all, I am continuing the NSK_CPP_STUB removal with this next webrev (before last one, the next one I'll send out will be removing NSK_CPP_STUB entirely). Webrev: http://cr.openjdk.java.net/~jcbeyler/8212082/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212082 The change is still straight-forward though, since it is just doing the same NSK_CPP_STUB removal as others. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 12 21:25:22 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 12 Oct 2018 14:25:22 -0700 Subject: RFR (L) 8212082: Remove the NSK_CPP_STUB macros from remaining vmTestbase/jvmti/[sS]* In-Reply-To: References: Message-ID: Yes they do, they have run on my dev machine and I'm submitting it on the submit repo (though that will test build and not the tests from what I understood) :) Jc On Fri, Oct 12, 2018 at 2:16 PM Hohensee, Paul wrote: > This looks fine. Do the tests run correctly after the transform? > > > > paul > > > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Friday, October 12, 2018 at 4:41 PM > *To: *"serviceability-dev at openjdk.java.net" < > serviceability-dev at openjdk.java.net> > *Subject: *RFR (L) 8212082: Remove the NSK_CPP_STUB macros from remaining > vmTestbase/jvmti/[sS]* > > > > Hi all, > > > I am continuing the NSK_CPP_STUB removal with this next webrev (before > last one, the next one I'll send out will be removing NSK_CPP_STUB > entirely). > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212082/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212082 > > > > The change is still straight-forward though, since it is just doing the > same NSK_CPP_STUB removal as others. > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From nezihyigitbasi at gmail.com Fri Oct 12 22:28:27 2018 From: nezihyigitbasi at gmail.com (nezih yigitbasi) Date: Fri, 12 Oct 2018 15:28:27 -0700 Subject: crash in JvmtiExport::post_compiled_method_load In-Reply-To: References: <5f503288-7e2a-2f0b-5bfe-b8c8c6222d18@oracle.com> <60e56552-8e4b-ca9d-0c1e-8281b11b3f1d@oracle.com> Message-ID: Hi, We have observed the same issue again on Java 10.0+46. I just wanted to share the new error file and the jvm args in case these provide additional information. hs_err file: https://gist.github.com/nezihyigitbasi/912fc3e7f2aff933f5828f5e913dae64 jvm args: https://gist.github.com/nezihyigitbasi/301716e9bbcb272d0c2cbadc45938a68 Thanks! Nezih On Wed, May 9, 2018 at 5:45 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > I've added the JVM args list to the bug report description. > > Thanks, > Serguei > > > On 5/9/18 17:21, nezih yigitbasi wrote: > > Thanks everyone for their input. Here is the full list of JVM args that > were used: > https://gist.github.com/nezihyigitbasi/2cc666dff55c663dbfc157e789a3a6f7 > > Nezih > > 2018-05-09 16:52 GMT-07:00 serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com>: > >> Hi Nezih, >> >> I've filed this bug: >> https://bugs.openjdk.java.net/browse/JDK-8202883 >> crash in the JvmtiExport::post_compiled_method_load >> >> Please, feel free to add any details when you have them. >> They are very important to reproduce the crash. >> For instance, what GC was used in scenario with this crash? >> >> Thank you for reporting the issue! >> Serguei >> >> >> >> On 5/8/18 16:51, serguei.spitsyn at oracle.com wrote: >> >> Hi Nezih, >> >> Crashing in the JvmtiExport::post_compiled_method_load function >> does not prove itself that it is a VM issue. >> And there are mo specific details in the log that help to understand this. >> Filing a bug with this log is almost useless as it would not help to get >> to the root cause. >> Also, there is still a pretty big chance the real problem is in the agent. >> >> My advice is to get as more details about this crash as possible. >> The best you can do is to provide a stand alone test case. >> Even if the issue is in the agent it will help to figure it out. >> >> Thanks, >> Serguei >> >> >> On 5/8/18 16:38, nezih yigitbasi wrote: >> >> Hi Serguei, >> We don't have a repro unfortunately. We have seen this only once so far >> in our production environment. >> >> Do you think this can be an agent issue? I thought like if it was an >> agent issue the stack trace would show it. The stack trace, however, ends >> in the VM code -- the crash happens in the >> "JvmtiExport::post_compiled_method_load" method. >> >> Thanks, >> Nezih >> >> 2018-05-08 16:34 GMT-07:00 serguei.spitsyn at oracle.com < >> serguei.spitsyn at oracle.com>: >> >>> Hi Nezih, >>> >>> You error file with log does not help much. >>> Could you, please, reproduce this issue with the debug or fastdebug >>> build? >>> Also, a standalone test case is better to provide to >>> increase chances the issue to be investigated and fixed. >>> >>> In general, a JVMTI agent has to be written very carefully as it can >>> easily cause the VM to crash. >>> So, it makes sense to look at the agent implementation first to make >>> sure it does not do anything wrong. >>> It is what we normally do first and why a test case that demonstrates >>> the problem is needed. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 5/8/18 16:00, nezih yigitbasi wrote: >>> >>> Hi, >>> >>> First of all, sorry for bringing up a crash issue in this dev mailing >>> list, but the crash report submission page ( >>> https://bugreport.java.com/bugreport/crash.jsp) doesn't list Java 9 in >>> the release drop down, so I couldn't report it there. >>> >>> We recently got a crash with Java 9.0.1+11 with an interesting stack >>> ending at "JvmtiExport::post_compiled_method_load()" (entire error file is >>> here >>> ). >>> A google search didn't end up with much info, so I just wanted to check >>> with this mailing list to see whether anyone has any ideas to investigate >>> this further. >>> >>> Thanks, >>> Nezih >>> >>> >>> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri Oct 12 23:02:18 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 12 Oct 2018 16:02:18 -0700 Subject: crash in JvmtiExport::post_compiled_method_load In-Reply-To: References: <5f503288-7e2a-2f0b-5bfe-b8c8c6222d18@oracle.com> <60e56552-8e4b-ca9d-0c1e-8281b11b3f1d@oracle.com> Message-ID: Hi Nezih, I've added a comment to the bug report with your details. Thanks! Serguei On 10/12/18 3:28 PM, nezih yigitbasi wrote: > Hi, > We have observed the same issue again on Java 10.0+46. I just wanted > to share the new error file and the jvm args in case these provide > additional information. > hs_err file: > https://gist.github.com/nezihyigitbasi/912fc3e7f2aff933f5828f5e913dae64 > jvm args: > https://gist.github.com/nezihyigitbasi/301716e9bbcb272d0c2cbadc45938a68 > > Thanks! > Nezih > > On Wed, May 9, 2018 at 5:45 PM serguei.spitsyn at oracle.com > > wrote: > > I've added the JVM args list to the bug report description. > > Thanks, > Serguei > > > On 5/9/18 17:21, nezih yigitbasi wrote: >> Thanks everyone for their input. Here is the full list of JVM >> args that were used: >> https://gist.github.com/nezihyigitbasi/2cc666dff55c663dbfc157e789a3a6f7 >> >> >> Nezih >> >> 2018-05-09 16:52 GMT-07:00 serguei.spitsyn at oracle.com >> > >: >> >> Hi Nezih, >> >> I've filed this bug: >> https://bugs.openjdk.java.net/browse/JDK-8202883 >> ??? crash in the JvmtiExport::post_compiled_method_load >> >> Please, feel free to add any details when you have them. >> They are very important to reproduce the crash. >> For instance, what GC was used in scenario with this crash? >> >> Thank you for reporting the issue! >> Serguei >> >> >> >> On 5/8/18 16:51, serguei.spitsyn at oracle.com >> wrote: >>> Hi Nezih, >>> >>> Crashing in the JvmtiExport::post_compiled_method_load function >>> does not prove itself that it is a VM issue. >>> And there are mo specific details in the log that help to >>> understand this. >>> Filing a bug with this log is almost useless as it would not >>> help to get to the root cause. >>> Also, there is still a pretty big chance the real problem is >>> in the agent. >>> >>> My advice is to get as more details about this crash as >>> possible. >>> The best you can do is to provide a stand alone test case. >>> Even if the issue is in the agent it will help to figure it out. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/8/18 16:38, nezih yigitbasi wrote: >>>> Hi Serguei, >>>> We don't have a repro unfortunately. We have seen this only >>>> once so far in our production environment. >>>> >>>> Do you think this can be an agent issue? I thought like if >>>> it was an agent issue the stack trace would show it. The >>>> stack trace, however, ends in the VM code -- the crash >>>> happens in the "JvmtiExport::post_compiled_method_load" method. >>>> >>>> Thanks, >>>> Nezih >>>> >>>> 2018-05-08 16:34 GMT-07:00 serguei.spitsyn at oracle.com >>>> >>>> >>> >: >>>> >>>> Hi Nezih, >>>> >>>> You error file with log does not help much. >>>> Could you, please, reproduce this issue with the debug >>>> or fastdebug build? >>>> Also, a standalone test case is better to provide to >>>> increase chances the issue to be investigated and fixed. >>>> >>>> In general, a JVMTI agent has to be written very >>>> carefully as it can easily cause the VM to crash. >>>> So, it makes sense to look at the agent implementation >>>> first to make sure it does not do anything wrong. >>>> It is what we normally do first and why a test case >>>> that demonstrates the problem is needed. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 5/8/18 16:00, nezih yigitbasi wrote: >>>>> Hi, >>>>> >>>>> First of all, sorry for bringing up a crash issue in >>>>> this dev mailing list, but the crash report submission >>>>> page (https://bugreport.java.com/bugreport/crash.jsp) >>>>> doesn't list Java 9 in the release drop down, so I >>>>> couldn't report it there. >>>>> >>>>> We recently got a crash with Java?9.0.1+11 with an >>>>> interesting stack ending at >>>>> "JvmtiExport::post_compiled_method_load()" (entire >>>>> error file is here >>>>> ). >>>>> A google search didn't end up with much info, so I >>>>> just wanted to check with this mailing list to see >>>>> whether anyone has any ideas to investigate this further. >>>>> >>>>> Thanks, >>>>> Nezih >>>>> >>>> >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Sat Oct 13 00:16:50 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 12 Oct 2018 17:16:50 -0700 Subject: RFR (L) 8212082: Remove the NSK_CPP_STUB macros from remaining vmTestbase/jvmti/[sS]* In-Reply-To: References: Message-ID: <0d88384f-03ce-e1ba-47d9-d22cf45cfde2@oracle.com> Looks good to me. --alex On 10/12/2018 14:25, JC Beyler wrote: > Yes they do, they have run on my dev machine and I'm submitting it on > the submit repo (though that will test build and not the tests from what > I understood) :) > Jc > > On Fri, Oct 12, 2018 at 2:16 PM Hohensee, Paul > wrote: > > This looks fine. Do the tests run correctly after the transform?____ > > __ __ > > paul____ > > __ __ > > *From: *serviceability-dev > > on behalf of > JC Beyler > > *Date: *Friday, October 12, 2018 at 4:41 PM > *To: *"serviceability-dev at openjdk.java.net > " > > > *Subject: *RFR (L) 8212082: Remove the NSK_CPP_STUB macros from > remaining vmTestbase/jvmti/[sS]*____ > > __ __ > > Hi all,____ > > > I am continuing the NSK_CPP_STUB removal with this next webrev > (before last one, the next one I'll send out will be removing > NSK_CPP_STUB entirely).____ > > __ __ > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212082/webrev.00/ > ____ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212082____ > > __ __ > > The change is still straight-forward though, since it is just doing > the same NSK_CPP_STUB removal as others. ____ > > __ __ > > Thanks,____ > > Jc____ > > > > -- > > Thanks, > Jc From jcbeyler at google.com Sat Oct 13 00:37:00 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 12 Oct 2018 17:37:00 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> Message-ID: Hi all, Any chance for a second reviewer on a Friday? :) Jc On Thu, Oct 11, 2018 at 11:03 AM Alex Menkov wrote: > got it. > > LGTM. > > --alex > > On 10/10/2018 19:03, JC Beyler wrote: > > Hi Alex, > > > > Thanks for the review! Yes I had seen that too before sending this > > review out and forked that fix into this: > > https://bugs.openjdk.java.net/browse/JDK-8211905 > > > > Which now is merged and I've updated my webrev to reflect this of course. > > > > My rationale for not doing it here directly is always the same: keeping > > the changes to the "spirit" of what the change is trying to do. Those > > extra casts were a bit out-of-scope and so I just forked the fix in > 8211905. > > > > Thanks! > > Jc > > > > On Wed, Oct 10, 2018 at 5:40 PM Alex Menkov > > wrote: > > > > Hi Jc, > > > > Overall looks good. > > > > one minor note: > > > > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: > > - jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > > (jstring) (jstring) (jstring) (jstring) > NSK_CPP_STUB3(CallObjectMethod, > > jni_env, klass, > > - methodID); > > + jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > > (jstring) (jstring) (jstring) (jstring) > > jni_env->CallObjectMethod(klass, > > methodID); > > > > Please drop multi "(jstring)" > > > > --alex > > > > On 10/08/2018 21:21, JC Beyler wrote: > > > Hi all, > > > > > > I am continuing the NSK_CPP_STUB removal with this next webrev. > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 > > > > > > The change is still straight-forward though, since it is just > > doing the > > > same NSK_CPP_STUB removal. However when I was looking at the > > changes, a > > > lot of these changes are touching lines with spaces before/after > > > parenthesis. I've almost never touched the spaces except if I was > > > refactoring by hand the line at the same time. The rationale > > being that > > > the lines will get fixed a few more times and are, at worse, > > covered by > > > the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which > > I've > > > commited to doing. > > > > > > Two exceptions are here where I pushed out the code into > > assignments due > > > to really long lines and complex if structures: > > > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp.udiff.html > > > > > - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp.udiff.html > > > > > > > > And one exception here where a commented line was doing the > > out-of-if > > > assignment so I just uncommented it and used the variable: > > > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp.udiff.html > > > > > > > > I've tested the modified changes on my machine, all modified > > tests pass. > > > > > > Let me know what you think, > > > Jc > > > > > > Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* > > > > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Oct 14 22:52:07 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Oct 2018 08:52:07 +1000 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: Hi Sven, Moving to serviceability-dev mailing list. Please don't reply to jdk-dev. Thanks, David On 15/10/2018 5:42 AM, Sven Reimers wrote: > Hi all, > > I hope this is the correct e-mailing list. During out testing of Apache > NetBeans 10 we discovered a problem with self sampling capability of > NetBeans. Digging further into this problem (NETBEANS-1359 > ) I debugged through > the code and it seems that there is a problem with the order of the values > and the order of the attributes. > > From the code I see the order of the values is > > final Object[] stackTraceElementItemValues = { > ste.getClassLoaderName(), > ste.getModuleName(), > ste.getModuleVersion(), > ste.getClassName(), > ste.getMethodName(), > ste.getFileName(), > ste.getLineNumber(), > ste.isNativeMethod(), > }; > > compared to the order of the attributes > > > private static final String[] V5_ATTRIBUTES = { > CLASS_NAME, > METHOD_NAME, > FILE_NAME, > LINE_NUMBER, > NATIVE_METHOD, > }; > > private static final String[] V9_ATTRIBUTES = { > CLASS_LOADER_NAME, > MODULE_NAME, > MODULE_VERSION, > }; > > private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = > Stream.of(V5_ATTRIBUTES, V9_ATTRIBUTES).flatMap(Arrays::stream) > .toArray(String[]::new); > > which can be expanded to > > CLASS_NAME, > METHOD_NAME, > FILE_NAME, > LINE_NUMBER, > NATIVE_METHOD, > CLASS_LOADER_NAME, > MODULE_NAME, > MODULE_VERSION, > > With the difference in ordering you will get an exception in > CompositeDataSupport, if you try to convert things (lines 228ff) > > // Check each value, if not null, is of the open type defined for > the > // corresponding item > for (String name : namesFromType) { > Object value = items.get(name); > if (value != null) { > OpenType itemType = compositeType.getType(name); > if (!itemType.isValue(value)) { > throw new OpenDataException( > "Argument value of wrong type for item " + name > + > ": value " + value + ", type " + itemType); > } > } > } > > which is hard to compensate from the caller side. > > I think the change, which introduced this was > > https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470 > > The proposed patch seems simple, just change the ordering of the attributes > > private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = > Stream.of(V9_ATTRIBUTES, V5_ATTRIBUTES).flatMap(Arrays::stream) > .toArray(String[]::new); > > or change the value ordering to fit the attributes order. > > Can anyone confirm the analysis? > > Thanks > > -Sven > From jcbeyler at google.com Mon Oct 15 02:08:57 2018 From: jcbeyler at google.com (JC Beyler) Date: Sun, 14 Oct 2018 19:08:57 -0700 Subject: RFR (L) 8212082: Remove the NSK_CPP_STUB macros from remaining vmTestbase/jvmti/[sS]* In-Reply-To: <0d88384f-03ce-e1ba-47d9-d22cf45cfde2@oracle.com> References: <0d88384f-03ce-e1ba-47d9-d22cf45cfde2@oracle.com> Message-ID: Thanks both :) Jc On Fri, Oct 12, 2018 at 5:17 PM Alex Menkov wrote: > Looks good to me. > > --alex > > On 10/12/2018 14:25, JC Beyler wrote: > > Yes they do, they have run on my dev machine and I'm submitting it on > > the submit repo (though that will test build and not the tests from what > > I understood) :) > > Jc > > > > On Fri, Oct 12, 2018 at 2:16 PM Hohensee, Paul > > wrote: > > > > This looks fine. Do the tests run correctly after the transform?____ > > > > __ __ > > > > paul____ > > > > __ __ > > > > *From: *serviceability-dev > > > > on behalf of > > JC Beyler > > > *Date: *Friday, October 12, 2018 at 4:41 PM > > *To: *"serviceability-dev at openjdk.java.net > > " > > > > > > *Subject: *RFR (L) 8212082: Remove the NSK_CPP_STUB macros from > > remaining vmTestbase/jvmti/[sS]*____ > > > > __ __ > > > > Hi all,____ > > > > > > I am continuing the NSK_CPP_STUB removal with this next webrev > > (before last one, the next one I'll send out will be removing > > NSK_CPP_STUB entirely).____ > > > > __ __ > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212082/webrev.00/ > > ____ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212082____ > > > > __ __ > > > > The change is still straight-forward though, since it is just doing > > the same NSK_CPP_STUB removal as others. ____ > > > > __ __ > > > > Thanks,____ > > > > Jc____ > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Oct 15 04:23:50 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Oct 2018 14:23:50 +1000 Subject: RFR (S) 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo Message-ID: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8048215 webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/ Simple race condition in the test. The main thread does checks that are only valid once the target thread has called o.wait() but there's nothing to ensure that point of execution is reached. The failure is easily reprodcued by just putting in a sleep after: Object o = new Object(); Fix is to add a shared 'waiter' Object that the target waits upon and for which the main also synchronizes on such that the main thread can't proceed until wait() has been called and released the monitor. Thanks, David From david.holmes at oracle.com Mon Oct 15 05:12:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Oct 2018 15:12:31 +1000 Subject: RFR (S): 8211909: JDWP Transport Listener: dt_socket thread crash Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8211909 webrev: http://cr.openjdk.java.net/~dholmes/8211909/webrev/ The crash occurs when trying to access a thread that was returned as part of JVM TI GetThreadGroupChildren. The problem is that the JVM TI code tries to use the Threads_lock to ensure atomic access to the ThreadGroup's threads and child groups: { // Cannot allow thread or group counts to change. MutexLocker mu(Threads_lock); but the Threads_lock does not control concurrency in the Java code that can cause threads to be added and removed, so we do not get a stable snapshot of the thread array and its length, and contents. To get a stable snapshot we have to use the same synchronization mechanism as used by the Java code: lock the monitor of the ThreadGroup instance. Two other pointless acquisitions of the Threads_lock, in GetThreadInfo and GetThreadGroupInfo, were also removed. These functions could report an inconsistent snapshot of the Thread or ThreadGroup state, if the mutable state is mutated concurrently. Again we could acquire the object's monitor to prevent this but it is unclear that there is any real benefit in doing so - after all the thread/group information could change immediately after it has been read anyway. So here I just delete the Threads_lock usage. Testing: mach5 tier 1-3 JVM TI tests (serviceability/jvmti vmTestbase/nsk/jvmti/) A regression test may be possible if we call GetThreadGroupChildren in a loop, whilst threads add and remove themselves from the group concurrently. But it is awkward to write. Thanks, David Thanks, David From daniel.fuchs at oracle.com Mon Oct 15 09:47:54 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 15 Oct 2018 10:47:54 +0100 Subject: RFR (S) 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo In-Reply-To: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> References: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> Message-ID: <049bc1c1-6a6d-b8e2-ef71-0200bade49ee@oracle.com> Hi David, Good finding! Looks reasonable to me. best regards, -- daniel On 15/10/2018 05:23, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8048215 > webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/ > > Simple race condition in the test. The main thread does checks that are > only valid once the target thread has called o.wait() but there's > nothing to ensure that point of execution is reached. The failure is > easily reprodcued by just putting in a sleep after: > > Object o = new Object(); > > Fix is to add a shared 'waiter' Object that the target waits upon and > for which the main also synchronizes on such that the main thread can't > proceed until wait() has been called and released the monitor. > > Thanks, > David From david.holmes at oracle.com Mon Oct 15 11:55:11 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 15 Oct 2018 21:55:11 +1000 Subject: RFR (S) 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo In-Reply-To: <049bc1c1-6a6d-b8e2-ef71-0200bade49ee@oracle.com> References: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> <049bc1c1-6a6d-b8e2-ef71-0200bade49ee@oracle.com> Message-ID: <3010bf50-4f65-2d8c-13a9-27494a06bead@oracle.com> Thanks for the review Daniel! David On 15/10/2018 7:47 PM, Daniel Fuchs wrote: > Hi David, > > Good finding! Looks reasonable to me. > > best regards, > > -- daniel > > On 15/10/2018 05:23, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8048215 >> webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/ >> >> Simple race condition in the test. The main thread does checks that >> are only valid once the target thread has called o.wait() but there's >> nothing to ensure that point of execution is reached. The failure is >> easily reprodcued by just putting in a sleep after: >> >> Object o = new Object(); >> >> Fix is to add a shared 'waiter' Object that the target waits upon and >> for which the main also synchronizes on such that the main thread >> can't proceed until wait() has been called and released the monitor. >> >> Thanks, >> David > From daniel.daugherty at oracle.com Mon Oct 15 15:05:19 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 15 Oct 2018 11:05:19 -0400 Subject: RFR (S): 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: References: Message-ID: On 10/15/18 1:12 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8211909 > webrev: http://cr.openjdk.java.net/~dholmes/8211909/webrev/ src/hotspot/share/prims/jvmtiEnv.cpp ??? No comments. Thumbs up on the code changes. > The crash occurs when trying to access a thread that was returned as > part of JVM TI GetThreadGroupChildren. The problem is that the JVM TI > code tries to use the Threads_lock to ensure atomic access to the > ThreadGroup's threads and child groups: > > ??? { // Cannot allow thread or group counts to change. > ????? MutexLocker mu(Threads_lock); > > but the Threads_lock does not control concurrency in the Java code > that can cause threads to be added and removed, so we do not get a > stable snapshot of the thread array and its length, and contents. To > get a stable snapshot we have to use the same synchronization > mechanism as used by the Java code: lock the monitor of the > ThreadGroup instance. Agreed that the wrong locking mechanism was used. Side note: The '// Cannot allow thread or group counts to change.' comment was added sometime after we switched from TeamWare to Mercurial. Looks like all three uses of Threads_lock that you removed date back to the original JVM/TI delta: $ sgv src/share/vm/prims/jvmtiEnv.cpp | grep '{ MutexLocker mu(Threads_lock);' 1.168 1.1 { MutexLocker mu(Threads_lock); 1.1 { MutexLocker mu(Threads_lock); 1.1 { MutexLocker mu(Threads_lock); 3358 lines No id keywords (cm7) $ sp -r1.1 src/share/vm/prims/jvmtiEnv.cpp src/share/vm/prims/SCCS/s.jvmtiEnv.cpp: D 1.1 03/01/28 20:52:06 rfield 1 0 03130/00000/00000 MRs: COMMENTS: date and time created 03/01/28 20:52:06 by rfield > Two other pointless acquisitions of the Threads_lock, in GetThreadInfo > and GetThreadGroupInfo, were also removed. These functions could > report an inconsistent snapshot of the Thread or ThreadGroup state, if > the mutable state is mutated concurrently. Again we could acquire the > object's monitor to prevent this but it is unclear that there is any > real benefit in doing so - after all the thread/group information > could change immediately after it has been read anyway. So here I just > delete the Threads_lock usage. Also agreed. I ran into all three of these in the Thread-SMR project and I couldn't convince myself to remove the use of Threads_lock for these two. I missed that the wrong lock was used for JVM/TI GetThreadGroupChildren(). Very nice catch! Dan > > Testing: mach5 tier 1-3 > ???????? JVM TI tests (serviceability/jvmti vmTestbase/nsk/jvmti/) > > A regression test may be possible if we call GetThreadGroupChildren in > a loop, whilst threads add and remove themselves from the group > concurrently. But it is awkward to write. > > Thanks, > David > > Thanks, > David From jcbeyler at google.com Mon Oct 15 15:10:55 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 15 Oct 2018 08:10:55 -0700 Subject: RFR (S) 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo In-Reply-To: <3010bf50-4f65-2d8c-13a9-27494a06bead@oracle.com> References: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> <049bc1c1-6a6d-b8e2-ef71-0200bade49ee@oracle.com> <3010bf50-4f65-2d8c-13a9-27494a06bead@oracle.com> Message-ID: Hi David, Looks good to me as well, Jc On Mon, Oct 15, 2018 at 4:55 AM David Holmes wrote: > Thanks for the review Daniel! > > David > > On 15/10/2018 7:47 PM, Daniel Fuchs wrote: > > Hi David, > > > > Good finding! Looks reasonable to me. > > > > best regards, > > > > -- daniel > > > > On 15/10/2018 05:23, David Holmes wrote: > >> bug: https://bugs.openjdk.java.net/browse/JDK-8048215 > >> webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/ > >> > >> Simple race condition in the test. The main thread does checks that > >> are only valid once the target thread has called o.wait() but there's > >> nothing to ensure that point of execution is reached. The failure is > >> easily reprodcued by just putting in a sleep after: > >> > >> Object o = new Object(); > >> > >> Fix is to add a shared 'waiter' Object that the target waits upon and > >> for which the main also synchronizes on such that the main thread > >> can't proceed until wait() has been called and released the monitor. > >> > >> Thanks, > >> David > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Oct 15 17:09:31 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Oct 2018 10:09:31 -0700 Subject: RFR (S) 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo In-Reply-To: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> References: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> Message-ID: On 10/14/18 9:23 PM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8048215 > webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/ > > Simple race condition in the test. The main thread does checks that > are only valid once the target thread has called o.wait() but there's > nothing to ensure that point of execution is reached. The failure is > easily reprodcued by just putting in a sleep after: > > Object o = new Object(); > > Fix is to add a shared 'waiter' Object that the target waits upon and > for which the main also synchronizes on such that the main thread > can't proceed until wait() has been called and released the monitor. Thanks for fixing this.? It's good finds.? This looks good. I wonder if some other ThreadMXBean tests have similiar bug. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Mon Oct 15 17:44:10 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 15 Oct 2018 13:44:10 -0400 Subject: RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt Message-ID: <5BC4D1EA.8010008@oracle.com> kill ... killing ... killed This bug was filed to cover the issue with the kill002 test, which sometimes did not consume enough of the reply messages after the wait for the "killed" message is observed. When a "kill" command is issued it is processed as an asynchronous command. The "killing" message is presented before the action is evaluated, and the "killed" message is presented after the evaluation returns. When the asynchronous action is completed a prompt is displayed after restoring the current thread info when the action was requested. Issue: https://bugs.openjdk.java.net/browse/JDK-8211013 Proposed fix: diff --git a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java --- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java +++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java @@ -488,6 +488,7 @@ showPrompt = false; evaluator.commandNext(); } else if (cmd.equals("kill")) { + showPrompt = false; // asynchronous command evaluator.commandKill(t); } else if (cmd.equals("interrupt")) { evaluator.commandInterrupt(t); Sample output: ... main[1] threads Group system: (java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running (java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer cond. waiting (java.lang.Thread)0x174 Signal Dispatcher running Group main: (java.lang.Thread)0x1 main running (at breakpoint) (nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0 cond. waiting (nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1 cond. waiting (nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2 cond. waiting (nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3 cond. waiting (nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4 cond. waiting Group InnocuousThreadGroup: (jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner cond. waiting main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0] killing thread: Thread-0 instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1] killing thread: Thread-1 instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2] killing thread: Thread-2 instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3] killing thread: Thread-3 instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4] killing thread: Thread-4 instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed main[1] threads ... An alternate proposal would include the simple prompt. e.g. ... main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0] > killing thread: Thread-0 instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1] > killing thread: Thread-1 Test in progress. From mandy.chung at oracle.com Mon Oct 15 17:51:10 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Oct 2018 10:51:10 -0700 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: Hi Sven, It's indeed a bug in the order of names and values when constructing CompositeData for StackTraceElement.? I created https://bugs.openjdk.java.net/browse/JDK-8212197 for this issue. Mandy On 10/14/18 3:52 PM, David Holmes wrote: > Hi Sven, > > Moving to serviceability-dev mailing list. Please don't reply to jdk-dev. > > Thanks, > David > > On 15/10/2018 5:42 AM, Sven Reimers wrote: >> Hi all, >> >> I hope this is the correct e-mailing list. During out testing of Apache >> NetBeans 10 we discovered a problem with self sampling capability of >> NetBeans. Digging further into this problem (NETBEANS-1359 >> ) I debugged >> through >> the code and it seems that there is a problem with the order of the >> values >> and the order of the attributes. >> >> ?From the code I see the order of the values is >> >> ???????? final Object[] stackTraceElementItemValues = { >> ???????????? ste.getClassLoaderName(), >> ???????????? ste.getModuleName(), >> ???????????? ste.getModuleVersion(), >> ???????????? ste.getClassName(), >> ???????????? ste.getMethodName(), >> ???????????? ste.getFileName(), >> ???????????? ste.getLineNumber(), >> ???????????? ste.isNativeMethod(), >> ???????? }; >> >> compared to? the order of the attributes >> >> >> ???? private static final String[] V5_ATTRIBUTES = { >> ???????? CLASS_NAME, >> ???????? METHOD_NAME, >> ???????? FILE_NAME, >> ???????? LINE_NUMBER, >> ???????? NATIVE_METHOD, >> ???? }; >> >> ???? private static final String[] V9_ATTRIBUTES = { >> ???????? CLASS_LOADER_NAME, >> ???????? MODULE_NAME, >> ???????? MODULE_VERSION, >> ???? }; >> >> ???? private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = >> ???????? Stream.of(V5_ATTRIBUTES, V9_ATTRIBUTES).flatMap(Arrays::stream) >> ?????????????? .toArray(String[]::new); >> >> which can be expanded to >> >> ???????? CLASS_NAME, >> ???????? METHOD_NAME, >> ???????? FILE_NAME, >> ???????? LINE_NUMBER, >> ???????? NATIVE_METHOD, >> ???????? CLASS_LOADER_NAME, >> ???????? MODULE_NAME, >> ???????? MODULE_VERSION, >> >> With the difference in ordering you will get an exception? in >> CompositeDataSupport, if you try to convert things (lines 228ff) >> >> ???????? // Check each value, if not null, is of the open type >> defined for >> the >> ???????? // corresponding item >> ???????? for (String name : namesFromType) { >> ???????????? Object value = items.get(name); >> ???????????? if (value != null) { >> ???????????????? OpenType itemType = compositeType.getType(name); >> ???????????????? if (!itemType.isValue(value)) { >> ???????????????????? throw new OpenDataException( >> ???????????????????????????? "Argument value of wrong type for item " >> + name >> + >> ???????????????????????????? ": value " + value + ", type " + itemType); >> ???????????????? } >> ???????????? } >> ???????? } >> >> which is hard to compensate from the caller side. >> >> I think the change, which introduced this was >> >> https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470 >> >> >> The proposed patch seems simple, just change the ordering of the >> attributes >> >> ?? private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = >> ???????? Stream.of(V9_ATTRIBUTES, V5_ATTRIBUTES).flatMap(Arrays::stream) >> ?????????????? .toArray(String[]::new); >> >> or change the value ordering to fit the attributes order. >> >> Can anyone confirm the analysis? >> >> Thanks >> >> -Sven >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon Oct 15 19:16:18 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 15 Oct 2018 12:16:18 -0700 Subject: RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt In-Reply-To: <5BC4D1EA.8010008@oracle.com> References: <5BC4D1EA.8010008@oracle.com> Message-ID: <11799558-9036-b15c-f2a2-0430be1642ef@oracle.com> Hi Gary, I think the simple prompt is meant to indicate that execution is suspended, but there is no current thread. I don't think that is the case here, so probably best not to use your alternate suggestion of a simple prompt. There doesn't seem to be much purpose in the first prompt being printed. You also seem to just be handling the situation the same as we do for other async commands, so looks good to me. thanks, Chris On 10/15/18 10:44 AM, Gary Adams wrote: > kill ... killing ... killed > > This bug was filed to cover the issue with the kill002 test, > which sometimes did not consume enough of the reply > messages after the wait for the "killed" message is observed. > > When a "kill" command is issued it is processed as an asynchronous > command. The "killing" message is presented before the action is > evaluated, and the "killed" message is presented after the evaluation > returns. When the asynchronous action is completed a prompt is > displayed after restoring the current thread info when the action > was requested. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8211013 > > Proposed fix: > > diff --git > a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > --- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > +++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > @@ -488,6 +488,7 @@ > ???????????????????????????? showPrompt = false; > ???????????????????????????? evaluator.commandNext(); > ???????????????????????? } else if (cmd.equals("kill")) { > +??????????????????????????? showPrompt = false;??????? // > asynchronous command > ???????????????????????????? evaluator.commandKill(t); > ???????????????????????? } else if (cmd.equals("interrupt")) { > ???????????????????????????? evaluator.commandInterrupt(t); > > Sample output: > ... > main[1] threads > Group system: > ? (java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler > running > ? (java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer???????? > cond. waiting > ? (java.lang.Thread)0x174???????????????????????? Signal Dispatcher > running > Group main: > ? (java.lang.Thread)0x1 main????????????? running (at breakpoint) > ? (nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0????????? cond. waiting > ? (nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1????????? cond. waiting > ? (nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2????????? cond. waiting > ? (nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3????????? cond. waiting > ? (nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4????????? cond. waiting > Group InnocuousThreadGroup: > ? (jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner??? cond. > waiting > main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0] > killing thread: Thread-0 > instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed > main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1] > killing thread: Thread-1 > instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) killed > main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2] > killing thread: Thread-2 > instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) killed > main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3] > killing thread: Thread-3 > instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) killed > main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4] > killing thread: Thread-4 > instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) killed > main[1] threads > ... > > An alternate proposal would include the simple prompt. e.g. > ... > main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0] > > killing thread: Thread-0 > instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) killed > main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1] > > killing thread: Thread-1 > > Test in progress. From david.holmes at oracle.com Mon Oct 15 19:46:40 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Oct 2018 05:46:40 +1000 Subject: RFR (S): 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: References: Message-ID: Thanks for the review Dan! David On 16/10/2018 1:05 AM, Daniel D. Daugherty wrote: > On 10/15/18 1:12 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211909 >> webrev: http://cr.openjdk.java.net/~dholmes/8211909/webrev/ > > src/hotspot/share/prims/jvmtiEnv.cpp > ??? No comments. > > Thumbs up on the code changes. > > >> The crash occurs when trying to access a thread that was returned as >> part of JVM TI GetThreadGroupChildren. The problem is that the JVM TI >> code tries to use the Threads_lock to ensure atomic access to the >> ThreadGroup's threads and child groups: >> >> ??? { // Cannot allow thread or group counts to change. >> ????? MutexLocker mu(Threads_lock); >> >> but the Threads_lock does not control concurrency in the Java code >> that can cause threads to be added and removed, so we do not get a >> stable snapshot of the thread array and its length, and contents. To >> get a stable snapshot we have to use the same synchronization >> mechanism as used by the Java code: lock the monitor of the >> ThreadGroup instance. > > Agreed that the wrong locking mechanism was used. > > Side note: The '// Cannot allow thread or group counts to change.' > comment was added sometime after we switched from TeamWare to > Mercurial. > > Looks like all three uses of Threads_lock that you removed > date back to the original JVM/TI delta: > > $ sgv src/share/vm/prims/jvmtiEnv.cpp | grep '{ MutexLocker > mu(Threads_lock);' > 1.168 > 1.1 { MutexLocker mu(Threads_lock); > 1.1 { MutexLocker mu(Threads_lock); > 1.1 { MutexLocker mu(Threads_lock); > 3358 lines > No id keywords (cm7) > > $ sp -r1.1 src/share/vm/prims/jvmtiEnv.cpp > src/share/vm/prims/SCCS/s.jvmtiEnv.cpp: > > D 1.1 03/01/28 20:52:06 rfield 1 0 03130/00000/00000 > MRs: > COMMENTS: > date and time created 03/01/28 20:52:06 by rfield > > >> Two other pointless acquisitions of the Threads_lock, in GetThreadInfo >> and GetThreadGroupInfo, were also removed. These functions could >> report an inconsistent snapshot of the Thread or ThreadGroup state, if >> the mutable state is mutated concurrently. Again we could acquire the >> object's monitor to prevent this but it is unclear that there is any >> real benefit in doing so - after all the thread/group information >> could change immediately after it has been read anyway. So here I just >> delete the Threads_lock usage. > > Also agreed. I ran into all three of these in the Thread-SMR project > and I couldn't convince myself to remove the use of Threads_lock for > these two. I missed that the wrong lock was used for JVM/TI > GetThreadGroupChildren(). > > Very nice catch! > > Dan > > >> >> Testing: mach5 tier 1-3 >> ???????? JVM TI tests (serviceability/jvmti vmTestbase/nsk/jvmti/) >> >> A regression test may be possible if we call GetThreadGroupChildren in >> a loop, whilst threads add and remove themselves from the group >> concurrently. But it is awkward to write. >> >> Thanks, >> David >> >> Thanks, >> David > From david.holmes at oracle.com Mon Oct 15 19:59:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Oct 2018 05:59:33 +1000 Subject: RFR (S) 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo In-Reply-To: References: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> <049bc1c1-6a6d-b8e2-ef71-0200bade49ee@oracle.com> <3010bf50-4f65-2d8c-13a9-27494a06bead@oracle.com> Message-ID: <3e338dc5-24bc-1feb-a1f4-7c6be783572e@oracle.com> Thanks Jc! David On 16/10/2018 1:10 AM, JC Beyler wrote: > Hi David, > > Looks good to me as well, > Jc > > On Mon, Oct 15, 2018 at 4:55 AM David Holmes > wrote: > > Thanks for the review Daniel! > > David > > On 15/10/2018 7:47 PM, Daniel Fuchs wrote: > > Hi David, > > > > Good finding! Looks reasonable to me. > > > > best regards, > > > > -- daniel > > > > On 15/10/2018 05:23, David Holmes wrote: > >> bug: https://bugs.openjdk.java.net/browse/JDK-8048215 > >> webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/ > > >> > >> Simple race condition in the test. The main thread does checks that > >> are only valid once the target thread has called o.wait() but > there's > >> nothing to ensure that point of execution is reached. The > failure is > >> easily reprodcued by just putting in a sleep after: > >> > >> Object o = new Object(); > >> > >> Fix is to add a shared 'waiter' Object that the target waits > upon and > >> for which the main also synchronizes on such that the main thread > >> can't proceed until wait() has been called and released the monitor. > >> > >> Thanks, > >> David > > > > > > -- > > Thanks, > Jc From david.holmes at oracle.com Mon Oct 15 20:00:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Oct 2018 06:00:02 +1000 Subject: RFR (S) 8048215: [TESTBUG] java/lang/management/ManagementFactory/ThreadMXBeanProxy.java Expected non-null LockInfo In-Reply-To: References: <914c41fd-b494-de8b-45dc-308ca05ca68c@oracle.com> Message-ID: Thanks for the review Mandy! David On 16/10/2018 3:09 AM, Mandy Chung wrote: > > > On 10/14/18 9:23 PM, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8048215 >> webrev: http://cr.openjdk.java.net/~dholmes/8048215/webrev/ >> >> Simple race condition in the test. The main thread does checks that >> are only valid once the target thread has called o.wait() but there's >> nothing to ensure that point of execution is reached. The failure is >> easily reprodcued by just putting in a sleep after: >> >> Object o = new Object(); >> >> Fix is to add a shared 'waiter' Object that the target waits upon and >> for which the main also synchronizes on such that the main thread >> can't proceed until wait() has been called and released the monitor. > > Thanks for fixing this.? It's good finds.? This looks good. > > I wonder if some other ThreadMXBean tests have similiar bug. > > Mandy From mandy.chung at oracle.com Mon Oct 15 22:02:27 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Oct 2018 15:02:27 -0700 Subject: RFR JDK-8212197: OpenDataException thrown when constructing CompositeData for StackTraceElement Message-ID: <217293a2-5399-a1cb-ad5b-ea0463299a8c@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212197/webrev.00/ This simple patch fixes the issue Sven reports [1] where the order of names and values when creating CompositeData for StackTraceElement is mismatched.? I keep names/values in the order of the attributes defined from old to new version. Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From sven.reimers at gmail.com Mon Oct 15 22:05:53 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 16 Oct 2018 00:05:53 +0200 Subject: RFR JDK-8212197: OpenDataException thrown when constructing CompositeData for StackTraceElement In-Reply-To: <217293a2-5399-a1cb-ad5b-ea0463299a8c@oracle.com> References: <217293a2-5399-a1cb-ad5b-ea0463299a8c@oracle.com> Message-ID: Looks good to me. Thanks. Sven On Tue, Oct 16, 2018 at 12:02 AM Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212197/webrev.00/ > > This simple patch fixes the issue Sven reports [1] where > the order of names and values when creating CompositeData > for StackTraceElement is mismatched. I keep names/values > in the order of the attributes defined from old to new > version. > > Mandy > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html > -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Oct 16 08:52:18 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 16 Oct 2018 09:52:18 +0100 Subject: RFR JDK-8212197: OpenDataException thrown when constructing CompositeData for StackTraceElement In-Reply-To: <217293a2-5399-a1cb-ad5b-ea0463299a8c@oracle.com> References: <217293a2-5399-a1cb-ad5b-ea0463299a8c@oracle.com> Message-ID: Hi Mandy, This looks good to me. best regards, -- daniel On 15/10/2018 23:02, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212197/webrev.00/ > > This simple patch fixes the issue Sven reports [1] where > the order of names and values when creating CompositeData > for StackTraceElement is mismatched.? I keep names/values > in the order of the attributes defined from old to new > version. > > Mandy > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html From Alan.Bateman at oracle.com Tue Oct 16 10:18:58 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Oct 2018 11:18:58 +0100 Subject: RFR JDK-8212197: OpenDataException thrown when constructing CompositeData for StackTraceElement In-Reply-To: <217293a2-5399-a1cb-ad5b-ea0463299a8c@oracle.com> References: <217293a2-5399-a1cb-ad5b-ea0463299a8c@oracle.com> Message-ID: <003eb2d0-a2f3-2d5a-9a5c-84829558e136@oracle.com> On 15/10/2018 23:02, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212197/webrev.00/ > > This simple patch fixes the issue Sven reports [1] where > the order of names and values when creating CompositeData > for StackTraceElement is mismatched.? I keep names/values > in the order of the attributes defined from old to new > version. Looks good to me. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Tue Oct 16 11:31:05 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 16 Oct 2018 07:31:05 -0400 Subject: RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt In-Reply-To: <11799558-9036-b15c-f2a2-0430be1642ef@oracle.com> References: <5BC4D1EA.8010008@oracle.com> <11799558-9036-b15c-f2a2-0430be1642ef@oracle.com> Message-ID: <5BC5CBF9.1060702@oracle.com> Still seeing a 1/1000 kill002 failure on solais-sparcv9-debug. The message waiting for "killing" is working correctly and only one compound prompt is being delivered. After all the killing a final cont is issued to proceed to the last breakpoint. The simple prompt is seen in the pending reply along with exceptions. Need to understand why it was not a clean kill. ... Sending command: kill 0x2ee nsk.jdb.kill.kill002.kill002a.exceptions[4] reply[0]: killing thread: Thread-4 reply[1]: instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=750) killed reply[2]: main[1] Sending command: threads reply[0]: Group system: reply[1]: (java.lang.ref.Reference$ReferenceHandler)0x17e Reference Handler running reply[2]: (java.lang.ref.Finalizer$FinalizerThread)0x17f Finalizer cond. waiting reply[3]: (java.lang.Thread)0x180 Signal Dispatcher running reply[4]: Group main: reply[5]: (java.lang.Thread)0x1 main running (at breakpoint) reply[6]: (nsk.jdb.kill.kill002.MyThread)0x2d2 Thread-0 cond. waiting reply[7]: (nsk.jdb.kill.kill002.MyThread)0x2eb Thread-1 cond. waiting reply[8]: (nsk.jdb.kill.kill002.MyThread)0x2ec Thread-2 cond. waiting reply[9]: (nsk.jdb.kill.kill002.MyThread)0x2ed Thread-3 cond. waiting reply[10]: (nsk.jdb.kill.kill002.MyThread)0x2ee Thread-4 cond. waiting reply[11]: Group InnocuousThreadGroup: reply[12]: (jdk.internal.misc.InnocuousThread)0x1a4 Common-Cleaner cond. waiting reply[13]: main[1] Sending command: cont receiveReply FAILED due to "nsk.share.Failure: Prompt is not received during 300200 milliseconds.". Pending reply output follows: reply[0]:> nsk.jdb.kill.kill002.kill002a$MyException: kill002a's Exception reply[1]: at nsk.jdb.kill.kill002.kill002a.(kill002a.java:49) reply[2]: java.lang.NullPointerException: kill002a's Exception reply[3]: at nsk.jdb.kill.kill002.kill002a.(kill002a.java:49) reply[4]: com.sun.jdi.IncompatibleThreadStateException: kill002a's Exception reply[5]: at nsk.jdb.kill.kill002.kill002a.(kill002a.java:49) # ERROR: Caught unexpected exception while executing the test: nsk.share.Failure: Prompt is not received during 300200 milliseconds. The following stacktrace is for failure analysis. nsk.share.TestFailure: Caught unexpected exception while executing the test: nsk.share.Failure: Prompt is not received during 300200 milliseconds. at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428) at nsk.share.Log.complain(Log.java:399) at nsk.share.jdb.JdbTest.failure(JdbTest.java:74) at nsk.share.jdb.JdbTest.runTest(JdbTest.java:158) at nsk.jdb.kill.kill002.kill002.run(kill002.java:76) at nsk.jdb.kill.kill002.kill002.main(kill002.java:70) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:835) On 10/15/18, 3:16 PM, Chris Plummer wrote: > Hi Gary, > > I think the simple prompt is meant to indicate that execution is > suspended, but there is no current thread. I don't think that is the > case here, so probably best not to use your alternate suggestion of a > simple prompt. There doesn't seem to be much purpose in the first > prompt being printed. You also seem to just be handling the situation > the same as we do for other async commands, so looks good to me. > > thanks, > > Chris > > On 10/15/18 10:44 AM, Gary Adams wrote: >> kill ... killing ... killed >> >> This bug was filed to cover the issue with the kill002 test, >> which sometimes did not consume enough of the reply >> messages after the wait for the "killed" message is observed. >> >> When a "kill" command is issued it is processed as an asynchronous >> command. The "killing" message is presented before the action is >> evaluated, and the "killed" message is presented after the evaluation >> returns. When the asynchronous action is completed a prompt is >> displayed after restoring the current thread info when the action >> was requested. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211013 >> >> Proposed fix: >> >> diff --git >> a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >> b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >> --- a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >> +++ b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java >> @@ -488,6 +488,7 @@ >> showPrompt = false; >> evaluator.commandNext(); >> } else if (cmd.equals("kill")) { >> + showPrompt = false; // >> asynchronous command >> evaluator.commandKill(t); >> } else if (cmd.equals("interrupt")) { >> evaluator.commandInterrupt(t); >> >> Sample output: >> ... >> main[1] threads >> Group system: >> (java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler >> running >> (java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer >> cond. waiting >> (java.lang.Thread)0x174 Signal Dispatcher >> running >> Group main: >> (java.lang.Thread)0x1 main running (at breakpoint) >> (nsk.jdb.kill.kill002.MyThread)0x2c9 Thread-0 cond. waiting >> (nsk.jdb.kill.kill002.MyThread)0x2e2 Thread-1 cond. waiting >> (nsk.jdb.kill.kill002.MyThread)0x2e3 Thread-2 cond. waiting >> (nsk.jdb.kill.kill002.MyThread)0x2e4 Thread-3 cond. waiting >> (nsk.jdb.kill.kill002.MyThread)0x2e5 Thread-4 cond. waiting >> Group InnocuousThreadGroup: >> (jdk.internal.misc.InnocuousThread)0x19a Common-Cleaner cond. >> waiting >> main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0] >> killing thread: Thread-0 >> instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) >> killed >> main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1] >> killing thread: Thread-1 >> instance of nsk.jdb.kill.kill002.MyThread(name='Thread-1', id=738) >> killed >> main[1] kill 0x2e3 nsk.jdb.kill.kill002.kill002a.exceptions[2] >> killing thread: Thread-2 >> instance of nsk.jdb.kill.kill002.MyThread(name='Thread-2', id=739) >> killed >> main[1] kill 0x2e4 nsk.jdb.kill.kill002.kill002a.exceptions[3] >> killing thread: Thread-3 >> instance of nsk.jdb.kill.kill002.MyThread(name='Thread-3', id=740) >> killed >> main[1] kill 0x2e5 nsk.jdb.kill.kill002.kill002a.exceptions[4] >> killing thread: Thread-4 >> instance of nsk.jdb.kill.kill002.MyThread(name='Thread-4', id=741) >> killed >> main[1] threads >> ... >> >> An alternate proposal would include the simple prompt. e.g. >> ... >> main[1] kill 0x2c9 nsk.jdb.kill.kill002.kill002a.exceptions[0] >> > killing thread: Thread-0 >> instance of nsk.jdb.kill.kill002.MyThread(name='Thread-0', id=713) >> killed >> main[1] kill 0x2e2 nsk.jdb.kill.kill002.kill002a.exceptions[1] >> > killing thread: Thread-1 >> >> Test in progress. > > From dms at samersoff.net Tue Oct 16 12:46:02 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Tue, 16 Oct 2018 15:46:02 +0300 Subject: RFR (S): 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: References: Message-ID: <92bf20b2-931d-a0b4-b346-bf23b2be1b02@samersoff.net> David, The fix looks good to me. PS: This code has lots of formatting nits like missed spaces. It's clearly out of scope of this fix, but it might be worth to launch a second webrev. -Dmitry On 15.10.2018 8:12, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8211909 > webrev: http://cr.openjdk.java.net/~dholmes/8211909/webrev/ > > The crash occurs when trying to access a thread that was returned as > part of JVM TI GetThreadGroupChildren. The problem is that the JVM TI > code tries to use the Threads_lock to ensure atomic access to the > ThreadGroup's threads and child groups: > > ??? { // Cannot allow thread or group counts to change. > ????? MutexLocker mu(Threads_lock); > > but the Threads_lock does not control concurrency in the Java code that > can cause threads to be added and removed, so we do not get a stable > snapshot of the thread array and its length, and contents. To get a > stable snapshot we have to use the same synchronization mechanism as > used by the Java code: lock the monitor of the ThreadGroup instance. > > Two other pointless acquisitions of the Threads_lock, in GetThreadInfo > and GetThreadGroupInfo, were also removed. These functions could report > an inconsistent snapshot of the Thread or ThreadGroup state, if the > mutable state is mutated concurrently. Again we could acquire the > object's monitor to prevent this but it is unclear that there is any > real benefit in doing so - after all the thread/group information could > change immediately after it has been read anyway. So here I just delete > the Threads_lock usage. > > Testing: mach5 tier 1-3 > ???????? JVM TI tests (serviceability/jvmti vmTestbase/nsk/jvmti/) > > A regression test may be possible if we call GetThreadGroupChildren in a > loop, whilst threads add and remove themselves from the group > concurrently. But it is awkward to write. > > Thanks, > David > > Thanks, > David -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From dean.long at oracle.com Tue Oct 16 16:51:43 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 16 Oct 2018 09:51:43 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count Message-ID: https://bugs.openjdk.java.net/browse/JDK-8021335 http://cr.openjdk.java.net/~dlong/8021335/webrev.3/ This change attempts to fix an old and intermittent problem with ThreadMXBean thread counts. Changes have 3 main parts: 1. Make sure hidden threads don't affect counts (even when exiting) 2. Fix race reading counts using atomic counters 3. Remove some workarounds in test (because they hide bugs) dl From jcbeyler at google.com Tue Oct 16 17:28:40 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 16 Oct 2018 10:28:40 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: Message-ID: Hi Dean, I noticed a typo here : "are atomically" is in the comment but should no longer be there I believe; the sentence probably should be: // These 2 counters are like the above thread counts, but are Any way we could move this test into a helper method and both add_thread/current_thread_exiting could use the same "ignore" thread code so that we ensure the two never get out of sync? + if (jt->is_hidden_from_external_view() || + jt->is_jvmti_agent_thread()) { + return; + } (Also by curiosity, add_thread has an assert on the Threads_lock but not thread_exiting?) Thanks, Jc On Tue, Oct 16, 2018 at 9:52 AM wrote: > https://bugs.openjdk.java.net/browse/JDK-8021335 > http://cr.openjdk.java.net/~dlong/8021335/webrev.3/ > > This change attempts to fix an old and intermittent problem with > ThreadMXBean thread counts. > Changes have 3 main parts: > 1. Make sure hidden threads don't affect counts (even when exiting) > 2. Fix race reading counts using atomic counters > 3. Remove some workarounds in test (because they hide bugs) > > dl > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Tue Oct 16 18:59:38 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 16 Oct 2018 11:59:38 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: Message-ID: On 10/16/18 10:28 AM, JC Beyler wrote: > Hi Dean, > > I noticed a typo here : > "are atomically" is in the comment but should no longer be there I > believe; the sentence probably should be: > // These 2 counters are like the above thread counts, but are > Fixed! > Any way we could move this test into a helper method and both > add_thread/current_thread_exiting could use the same "ignore" thread > code so that we ensure the two never get out of sync? > > +? if (jt->is_hidden_from_external_view() || > +? ? ? jt->is_jvmti_agent_thread()) { > +? ? return; > +? } > Good idea.? Fixed. > (Also by curiosity, add_thread has an assert on the Threads_lock but > not thread_exiting?) > Right, I followed the existing pattern where current_thread_exiting() only uses the atomic counters, so it doesn't need Threads_lock. dl > Thanks, > Jc > > > On Tue, Oct 16, 2018 at 9:52 AM > wrote: > > https://bugs.openjdk.java.net/browse/JDK-8021335 > http://cr.openjdk.java.net/~dlong/8021335/webrev.3/ > > > This change attempts to fix an old and intermittent problem with > ThreadMXBean thread counts. > Changes have 3 main parts: > 1. Make sure hidden threads don't affect counts (even when exiting) > 2. Fix race reading counts using atomic counters > 3. Remove some workarounds in test (because they hide bugs) > > dl > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Oct 16 20:22:40 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 16 Oct 2018 13:22:40 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> Message-ID: Hi all, How about on a Tuesday? :) Sneak peak and motivational sentence: after this goes in, we have this one which removes the NSK_CPP_STUBs from the tests entirely! :) Jc On Fri, Oct 12, 2018 at 5:37 PM JC Beyler wrote: > Hi all, > > Any chance for a second reviewer on a Friday? :) > Jc > > On Thu, Oct 11, 2018 at 11:03 AM Alex Menkov > wrote: > >> got it. >> >> LGTM. >> >> --alex >> >> On 10/10/2018 19:03, JC Beyler wrote: >> > Hi Alex, >> > >> > Thanks for the review! Yes I had seen that too before sending this >> > review out and forked that fix into this: >> > https://bugs.openjdk.java.net/browse/JDK-8211905 >> > >> > Which now is merged and I've updated my webrev to reflect this of >> course. >> > >> > My rationale for not doing it here directly is always the same: keeping >> > the changes to the "spirit" of what the change is trying to do. Those >> > extra casts were a bit out-of-scope and so I just forked the fix in >> 8211905. >> > >> > Thanks! >> > Jc >> > >> > On Wed, Oct 10, 2018 at 5:40 PM Alex Menkov > > > wrote: >> > >> > Hi Jc, >> > >> > Overall looks good. >> > >> > one minor note: >> > >> > >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: >> > - jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) >> > (jstring) (jstring) (jstring) (jstring) >> NSK_CPP_STUB3(CallObjectMethod, >> > jni_env, klass, >> > - methodID); >> > + jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) >> > (jstring) (jstring) (jstring) (jstring) >> > jni_env->CallObjectMethod(klass, >> > methodID); >> > >> > Please drop multi "(jstring)" >> > >> > --alex >> > >> > On 10/08/2018 21:21, JC Beyler wrote: >> > > Hi all, >> > > >> > > I am continuing the NSK_CPP_STUB removal with this next webrev. >> > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ >> > >> > > >> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 >> > > >> > > The change is still straight-forward though, since it is just >> > doing the >> > > same NSK_CPP_STUB removal. However when I was looking at the >> > changes, a >> > > lot of these changes are touching lines with spaces before/after >> > > parenthesis. I've almost never touched the spaces except if I was >> > > refactoring by hand the line at the same time. The rationale >> > being that >> > > the lines will get fixed a few more times and are, at worse, >> > covered by >> > > the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which >> > I've >> > > commited to doing. >> > > >> > > Two exceptions are here where I pushed out the code into >> > assignments due >> > > to really long lines and complex if structures: >> > > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp.udiff.html >> > >> > > - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp.udiff.html >> > >> > > >> > > And one exception here where a commented line was doing the >> > out-of-if >> > > assignment so I just uncommented it and used the variable: >> > > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp >> > > >> > < >> http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp.udiff.html >> > >> > > >> > > I've tested the modified changes on my machine, all modified >> > tests pass. >> > > >> > > Let me know what you think, >> > > Jc >> > > >> > > Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* >> > > >> > >> > >> > >> > -- >> > >> > Thanks, >> > Jc >> > > > -- > > Thanks, > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Oct 16 22:50:25 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Oct 2018 08:50:25 +1000 Subject: RFR (S): 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: <92bf20b2-931d-a0b4-b346-bf23b2be1b02@samersoff.net> References: <92bf20b2-931d-a0b4-b346-bf23b2be1b02@samersoff.net> Message-ID: Hi Dmitry, On 16/10/2018 10:46 PM, Dmitry Samersoff wrote: > David, > > The fix looks good to me. Thanks for taking a look. > PS: This code has lots of formatting nits like missed spaces. > It's clearly out of scope of this fix, but it might be worth to > launch a second webrev. out of scope but launch a second webrev? Sorry I'm a little confused. But I only see a few missed space around for-loops: 929 for (int i=0; i < nthreads; i++) { 1463 for (int i=0, j=0; i > -Dmitry > > On 15.10.2018 8:12, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211909 >> webrev: http://cr.openjdk.java.net/~dholmes/8211909/webrev/ >> >> The crash occurs when trying to access a thread that was returned as >> part of JVM TI GetThreadGroupChildren. The problem is that the JVM TI >> code tries to use the Threads_lock to ensure atomic access to the >> ThreadGroup's threads and child groups: >> >> ??? { // Cannot allow thread or group counts to change. >> ????? MutexLocker mu(Threads_lock); >> >> but the Threads_lock does not control concurrency in the Java code that >> can cause threads to be added and removed, so we do not get a stable >> snapshot of the thread array and its length, and contents. To get a >> stable snapshot we have to use the same synchronization mechanism as >> used by the Java code: lock the monitor of the ThreadGroup instance. >> >> Two other pointless acquisitions of the Threads_lock, in GetThreadInfo >> and GetThreadGroupInfo, were also removed. These functions could report >> an inconsistent snapshot of the Thread or ThreadGroup state, if the >> mutable state is mutated concurrently. Again we could acquire the >> object's monitor to prevent this but it is unclear that there is any >> real benefit in doing so - after all the thread/group information could >> change immediately after it has been read anyway. So here I just delete >> the Threads_lock usage. >> >> Testing: mach5 tier 1-3 >> ???????? JVM TI tests (serviceability/jvmti vmTestbase/nsk/jvmti/) >> >> A regression test may be possible if we call GetThreadGroupChildren in a >> loop, whilst threads add and remove themselves from the group >> concurrently. But it is awkward to write. >> >> Thanks, >> David >> >> Thanks, >> David > > From dean.long at oracle.com Tue Oct 16 23:43:16 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 16 Oct 2018 16:43:16 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: Message-ID: New webrev: http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ dl On 10/16/18 11:59 AM, dean.long at oracle.com wrote: > On 10/16/18 10:28 AM, JC Beyler wrote: >> Hi Dean, >> >> I noticed a typo here : >> "are atomically" is in the comment but should no longer be there I >> believe; the sentence probably should be: >> // These 2 counters are like the above thread counts, but are >> > > Fixed! > >> Any way we could move this test into a helper method and both >> add_thread/current_thread_exiting could use the same "ignore" thread >> code so that we ensure the two never get out of sync? >> >> +? if (jt->is_hidden_from_external_view() || >> +? ? ? jt->is_jvmti_agent_thread()) { >> +? ? return; >> +? } >> > > Good idea.? Fixed. > >> (Also by curiosity, add_thread has an assert on the Threads_lock but >> not thread_exiting?) >> > > Right, I followed the existing pattern where current_thread_exiting() > only uses the atomic counters, so it doesn't need Threads_lock. > > dl > >> Thanks, >> Jc >> >> >> On Tue, Oct 16, 2018 at 9:52 AM > > wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8021335 >> http://cr.openjdk.java.net/~dlong/8021335/webrev.3/ >> >> >> This change attempts to fix an old and intermittent problem with >> ThreadMXBean thread counts. >> Changes have 3 main parts: >> 1. Make sure hidden threads don't affect counts (even when exiting) >> 2. Fix race reading counts using atomic counters >> 3. Remove some workarounds in test (because they hide bugs) >> >> dl >> >> >> >> -- >> >> Thanks, >> Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Oct 17 02:33:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Oct 2018 12:33:55 +1000 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: Message-ID: Hi Dean, Thanks for tackling this. I'm still struggling to fully grasp why we need both the PerfCounters and the regular counters. I get that we have to decrement the live counts before ensure_join() has allowed Thread.join() to return, to ensure that if we then check the number of threads it has dropped by one. But I don't understand why that means we need to manage the thread count in two parts. Particularly as now you don't use the PerfCounter to return the live count, so it makes me wonder what role the PerfCounter is playing as it is temporarily inconsistent with the reported live count? Is it simply that we can't atomically decrement the PerfCounters, and we can't require the Threads_lock when decrementing? On the code itself one thing I find irksome is that we already have a daemon flag in remove_thread but decrement_thread_counts doesn't get passed that and so always re-examines the thread to see if it is a daemon. I know only one of the code paths has the daemon flag, so perhaps we should hoist the daemon check up into JavaThread::exit and then pass a daemon parameter to decrement_thread_counts. There's also some ambiguity (existing) in relation to the existence of the jt->threadObj() and its affect on whether the thread is considered a daemon or not. Your check has to mirror the existing checks - the threadObj may be NULL at removal if it was a failed attach, but the addition considers a JNI-attached thread to be non-daemon. Overall this seems buggy to me but as long as your check follows the same rules that is okay. In that regard JavaThread::exit should never encounter a NULL threadObj(). Minor nit: I suggest moving the two occurrences of the comment // Do not count VM internal or JVMTI agent threads inside is_hidden_thread so that we don't have to remember to update the comments if the definition changes. Thanks, David ----- On 17/10/2018 9:43 AM, dean.long at oracle.com wrote: > New webrev: > > http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ > > dl > > On 10/16/18 11:59 AM, dean.long at oracle.com wrote: >> On 10/16/18 10:28 AM, JC Beyler wrote: >>> Hi Dean, >>> >>> I noticed a typo here : >>> "are atomically" is in the comment but should no longer be there I >>> believe; the sentence probably should be: >>> // These 2 counters are like the above thread counts, but are >>> >> >> Fixed! >> >>> Any way we could move this test into a helper method and both >>> add_thread/current_thread_exiting could use the same "ignore" thread >>> code so that we ensure the two never get out of sync? >>> >>> +? if (jt->is_hidden_from_external_view() || >>> +? ? ? jt->is_jvmti_agent_thread()) { >>> +? ? return; >>> +? } >>> >> >> Good idea.? Fixed. >> >>> (Also by curiosity, add_thread has an assert on the Threads_lock but >>> not thread_exiting?) >>> >> >> Right, I followed the existing pattern where current_thread_exiting() >> only uses the atomic counters, so it doesn't need Threads_lock. >> >> dl >> >>> Thanks, >>> Jc >>> >>> >>> On Tue, Oct 16, 2018 at 9:52 AM >> > wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8021335 >>> http://cr.openjdk.java.net/~dlong/8021335/webrev.3/ >>> >>> >>> This change attempts to fix an old and intermittent problem with >>> ThreadMXBean thread counts. >>> Changes have 3 main parts: >>> 1. Make sure hidden threads don't affect counts (even when exiting) >>> 2. Fix race reading counts using atomic counters >>> 3. Remove some workarounds in test (because they hide bugs) >>> >>> dl >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> > From daniil.x.titov at oracle.com Wed Oct 17 03:59:36 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 16 Oct 2018 20:59:36 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> Message-ID: <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> Hi Alex, Chris and JC, Please review an updated version of the patch that addresses these issues. Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 Thanks! --Daniil ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: Hi Daniil, 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL 2) wrong indent in JdbStopThreadTest.java: 36 import lib.jdb.JdbCommand; 37 import lib.jdb.JdbTest; 3) I think it would be better to make waitForSimplePrompt property of JdbCommand (like JdbCommand.allowExit) jdb.command(JdbCommand.run().replyIsSimplePrompt()); looks much clearer than jdb.command(JdbCommand.run(), true); 4) (TTY.java) MessageOutput.lnprint("Breakpoint hit:"); + // Print current location and prompt if suspend policy is SUSPEND_EVENT_THREAD. + // In case of SUSPEND_ALL policy this is handled by vmInterrupted() method. + if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) { + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); + MessageOutput.printPrompt(); + } We have 3 separate outputs. If we have several concurrent threads, we can easy get mess of outputs from different threads. I think it would be better to print everything in a single chunk. I suppose TTY has other places with similar "non-atomic" output, so maybe revising TTY output should be handled by separate issue. --alex On 10/11/2018 22:00, Chris Plummer wrote: > Hi Daniil, > > Can you send output from an example jdb session? > > Do you think maybe we should also call printCurrentLocation() when the > suspend policy is NONE? > > There's a typo in the following line. The space is on the wrong side of > the comma. > > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine)); > > thanks, > > Chris > > On 10/11/18 8:02 PM, Daniil Titov wrote: >> >> Thank you, JC! >> >> Please review an updated version of the patch that fixes newly added >> test for Windows platform (now it uses system dependent line >> separator string). >> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >> >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Best regards, >> >> --Daniil >> >> *From: *JC Beyler >> *Date: *Thursday, October 11, 2018 at 7:17 PM >> *To: * >> *Cc: * >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint >> is hit and suspend policy is STOP_EVENT_THREAD >> >> Hi Daniil, >> >> Looks good to me. I saw a really small nit: >> >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >> >> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine)); >> >> There is a space after the '('. >> >> No need to send a new webrev for that evidently :), >> >> Jc >> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >> > wrote: >> >> Please review the change that fixes the issue with missing prompt >> in jdb when a breakpoint is hit and the suspend policy is set to >> stop the thread only. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Thanks! >> --Daniil >> >> >> >> -- >> >> Thanks, >> >> Jc >> > From sven.reimers at gmail.com Wed Oct 17 06:16:27 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 17 Oct 2018 08:16:27 +0200 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: Hi, thanks for fixing. What about a backport to 11? Thanks -Sven Mandy Chung schrieb am Mo., 15. Okt. 2018, 19:50: > Hi Sven, > > It's indeed a bug in the order of names and values when constructing > CompositeData for StackTraceElement. I created > https://bugs.openjdk.java.net/browse/JDK-8212197 for this issue. > > Mandy > > On 10/14/18 3:52 PM, David Holmes wrote: > > Hi Sven, > > Moving to serviceability-dev mailing list. Please don't reply to jdk-dev. > > Thanks, > David > > On 15/10/2018 5:42 AM, Sven Reimers wrote: > > Hi all, > > I hope this is the correct e-mailing list. During out testing of Apache > NetBeans 10 we discovered a problem with self sampling capability of > NetBeans. Digging further into this problem (NETBEANS-1359 > > ) I debugged through > the code and it seems that there is a problem with the order of the values > and the order of the attributes. > > From the code I see the order of the values is > > final Object[] stackTraceElementItemValues = { > ste.getClassLoaderName(), > ste.getModuleName(), > ste.getModuleVersion(), > ste.getClassName(), > ste.getMethodName(), > ste.getFileName(), > ste.getLineNumber(), > ste.isNativeMethod(), > }; > > compared to the order of the attributes > > > private static final String[] V5_ATTRIBUTES = { > CLASS_NAME, > METHOD_NAME, > FILE_NAME, > LINE_NUMBER, > NATIVE_METHOD, > }; > > private static final String[] V9_ATTRIBUTES = { > CLASS_LOADER_NAME, > MODULE_NAME, > MODULE_VERSION, > }; > > private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = > Stream.of(V5_ATTRIBUTES, V9_ATTRIBUTES).flatMap(Arrays::stream) > .toArray(String[]::new); > > which can be expanded to > > CLASS_NAME, > METHOD_NAME, > FILE_NAME, > LINE_NUMBER, > NATIVE_METHOD, > CLASS_LOADER_NAME, > MODULE_NAME, > MODULE_VERSION, > > With the difference in ordering you will get an exception in > CompositeDataSupport, if you try to convert things (lines 228ff) > > // Check each value, if not null, is of the open type defined for > the > // corresponding item > for (String name : namesFromType) { > Object value = items.get(name); > if (value != null) { > OpenType itemType = compositeType.getType(name); > if (!itemType.isValue(value)) { > throw new OpenDataException( > "Argument value of wrong type for item " + > name > + > ": value " + value + ", type " + itemType); > } > } > } > > which is hard to compensate from the caller side. > > I think the change, which introduced this was > > > https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470 > > The proposed patch seems simple, just change the ordering of the > attributes > > private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = > Stream.of(V9_ATTRIBUTES, V5_ATTRIBUTES).flatMap(Arrays::stream) > .toArray(String[]::new); > > or change the value ordering to fit the attributes order. > > Can anyone confirm the analysis? > > Thanks > > -Sven > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Wed Oct 17 11:45:09 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 17 Oct 2018 07:45:09 -0400 Subject: Restoring nsk/jvmti/scenarios/hotswap tests from ProblemList.txt Message-ID: <5BC720C5.4060907@oracle.com> While investigating other issues with hotswap tests I noticed 2 tests on the Problemlist that I think can be restored. I have not been able to reproduce the failure with hs102t002 It is marked in the ProblemList as related to JDK-8203350, but that bug is about hs201t002. It is also marked as related to JDK-8204506, which is concerned with test hs102t002, but is specific to a graal failure and is already recorded in ProblemList-graal.txt https://bugs.openjdk.java.net/browse/JDK-8203350 https://bugs.openjdk.java.net/browse/JDK-8204506 I did run into some intermittent failures with hs204t001 and the utility class ExecDriver. It appears that it took advantage of other tests building the class file. A simple directive to build ExecDirver will bring it in line with the other hotswap tests. diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -184,8 +184,6 @@ vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted004/TestDescription.java 7013634,6606767 generic-all vmTestbase/nsk/jvmti/ThreadStart/threadstart001/TestDescription.java 8016181 generic-all vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/TestDescription.java 8173658 generic-all -vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t002/TestDescription.java 8204506,8203350 generic-all -vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java 6813266 generic-all vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/TestDescription.java 8051349 generic-all vmTestbase/nsk/jvmti/AttachOnDemand/attach034/TestDescription.java 8042145 generic-all vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java 8202971 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java @@ -46,7 +46,8 @@ * @library /vmTestbase * /test/lib * @run driver jdk.test.lib.FileInstaller . . - * @build nsk.jvmti.scenarios.hotswap.HS204.hs204t001.hs204t001 + * @build ExecDriver + * nsk.jvmti.scenarios.hotswap.HS204.hs204t001.hs204t001 * * @comment compile newclassXX to bin/newclassXX * @run driver nsk.share.ExtraClassesBuilder From jcbeyler at google.com Wed Oct 17 15:03:35 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 17 Oct 2018 08:03:35 -0700 Subject: Restoring nsk/jvmti/scenarios/hotswap tests from ProblemList.txt In-Reply-To: <5BC720C5.4060907@oracle.com> References: <5BC720C5.4060907@oracle.com> Message-ID: Hi Gary, Looks good to me. The only thing I would note is that all other tests put the @build ExecDriver right before the @run for the test. I think that perhaps it would be good to either refactor them all at some point to what you've done here; or put the @build ExecDriver separate to keep all tests consistent. But it's a nit so looks good to me :) Jc On Wed, Oct 17, 2018 at 4:43 AM Gary Adams wrote: > While investigating other issues with hotswap tests I noticed > 2 tests on the Problemlist that I think can be restored. > > I have not been able to reproduce the failure with hs102t002 > It is marked in the ProblemList as related to JDK-8203350, > but that bug is about hs201t002. It is also marked as related > to JDK-8204506, which is concerned with test hs102t002, but > is specific to a graal failure and is already recorded in > ProblemList-graal.txt > > https://bugs.openjdk.java.net/browse/JDK-8203350 > https://bugs.openjdk.java.net/browse/JDK-8204506 > > I did run into some intermittent failures with hs204t001 and the > utility class ExecDriver. It appears that it took advantage of other tests > building the class file. A simple directive to build ExecDirver will > bring it > in line with the other hotswap tests. > > diff --git a/test/hotspot/jtreg/ProblemList.txt > b/test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -184,8 +184,6 @@ > > vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted004/TestDescription.java > 7013634,6606767 generic-all > vmTestbase/nsk/jvmti/ThreadStart/threadstart001/TestDescription.java > 8016181 generic-all > > vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/TestDescription.java > 8173658 generic-all > -vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t002/TestDescription.java > > 8204506,8203350 generic-all > -vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > 6813266 generic-all > > vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/TestDescription.java > 8051349 generic-all > vmTestbase/nsk/jvmti/AttachOnDemand/attach034/TestDescription.java > 8042145 generic-all > vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java > 8202971 generic-all > > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > > > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > --- > > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > +++ > > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > @@ -46,7 +46,8 @@ > * @library /vmTestbase > * /test/lib > * @run driver jdk.test.lib.FileInstaller . . > - * @build nsk.jvmti.scenarios.hotswap.HS204.hs204t001.hs204t001 > + * @build ExecDriver > + * nsk.jvmti.scenarios.hotswap.HS204.hs204t001.hs204t001 > * > * @comment compile newclassXX to bin/newclassXX > * @run driver nsk.share.ExtraClassesBuilder > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Oct 17 16:26:22 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 17 Oct 2018 09:26:22 -0700 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: I plan to request the backport to 11u. Mandy On 10/16/18 11:16 PM, Sven Reimers wrote: > Hi, > > thanks for fixing. What about a backport to 11? > > Thanks > > -Sven > > > > Mandy Chung > > schrieb am Mo., 15. Okt. 2018, 19:50: > > Hi Sven, > > It's indeed a bug in the order of names and values when > constructing CompositeData for StackTraceElement.? I created > https://bugs.openjdk.java.net/browse/JDK-8212197 for this issue. > > Mandy > > On 10/14/18 3:52 PM, David Holmes wrote: >> Hi Sven, >> >> Moving to serviceability-dev mailing list. Please don't reply to >> jdk-dev. >> >> Thanks, >> David >> >> On 15/10/2018 5:42 AM, Sven Reimers wrote: >>> Hi all, >>> >>> I hope this is the correct e-mailing list. During out testing of >>> Apache >>> NetBeans 10 we discovered a problem with self sampling >>> capability of >>> NetBeans. Digging further into this problem (NETBEANS-1359 >>> >>> ) I >>> debugged through >>> the code and it seems that there is a problem with the order of >>> the values >>> and the order of the attributes. >>> >>> ?From the code I see the order of the values is >>> >>> ???????? final Object[] stackTraceElementItemValues = { >>> ???????????? ste.getClassLoaderName(), >>> ???????????? ste.getModuleName(), >>> ???????????? ste.getModuleVersion(), >>> ???????????? ste.getClassName(), >>> ???????????? ste.getMethodName(), >>> ???????????? ste.getFileName(), >>> ???????????? ste.getLineNumber(), >>> ???????????? ste.isNativeMethod(), >>> ???????? }; >>> >>> compared to? the order of the attributes >>> >>> >>> ???? private static final String[] V5_ATTRIBUTES = { >>> ???????? CLASS_NAME, >>> ???????? METHOD_NAME, >>> ???????? FILE_NAME, >>> ???????? LINE_NUMBER, >>> ???????? NATIVE_METHOD, >>> ???? }; >>> >>> ???? private static final String[] V9_ATTRIBUTES = { >>> ???????? CLASS_LOADER_NAME, >>> ???????? MODULE_NAME, >>> ???????? MODULE_VERSION, >>> ???? }; >>> >>> ???? private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = >>> ???????? Stream.of(V5_ATTRIBUTES, >>> V9_ATTRIBUTES).flatMap(Arrays::stream) >>> ?????????????? .toArray(String[]::new); >>> >>> which can be expanded to >>> >>> ???????? CLASS_NAME, >>> ???????? METHOD_NAME, >>> ???????? FILE_NAME, >>> ???????? LINE_NUMBER, >>> ???????? NATIVE_METHOD, >>> ???????? CLASS_LOADER_NAME, >>> ???????? MODULE_NAME, >>> ???????? MODULE_VERSION, >>> >>> With the difference in ordering you will get an exception? in >>> CompositeDataSupport, if you try to convert things (lines 228ff) >>> >>> ???????? // Check each value, if not null, is of the open type >>> defined for >>> the >>> ???????? // corresponding item >>> ???????? for (String name : namesFromType) { >>> ???????????? Object value = items.get(name); >>> ???????????? if (value != null) { >>> ???????????????? OpenType itemType = >>> compositeType.getType(name); >>> ???????????????? if (!itemType.isValue(value)) { >>> ???????????????????? throw new OpenDataException( >>> ???????????????????????????? "Argument value of wrong type for >>> item " + name >>> + >>> ???????????????????????????? ": value " + value + ", type " + >>> itemType); >>> ???????????????? } >>> ???????????? } >>> ???????? } >>> >>> which is hard to compensate from the caller side. >>> >>> I think the change, which introduced this was >>> >>> https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470 >>> >>> >>> The proposed patch seems simple, just change the ordering of the >>> attributes >>> >>> ?? private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = >>> ???????? Stream.of(V9_ATTRIBUTES, >>> V5_ATTRIBUTES).flatMap(Arrays::stream) >>> ?????????????? .toArray(String[]::new); >>> >>> or change the value ordering to fit the attributes order. >>> >>> Can anyone confirm the analysis? >>> >>> Thanks >>> >>> -Sven >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Wed Oct 17 16:46:07 2018 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 17 Oct 2018 12:46:07 -0400 Subject: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java Message-ID: <5BC7674F.5070501@oracle.com> The RedefineCrossEvent test has been on been on the ProblemList for a very long time. In the past this test had some dependency on the Java EE modules, but they were deprecated for jdk9 and later removed completely in jdk11. This changeset to restore it, removes the corba module reference and blocks the redefine operations for jdk.internal classes that presented an issue when the RedefineCrossEvent test launches the InstanceFilter test. Issue: https://bugs.openjdk.java.net/browse/JDK-8206330 Webrev: http://cr.openjdk.java.net/~gadams/8206330/webrev/index.html From chris.plummer at oracle.com Wed Oct 17 17:47:03 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Oct 2018 10:47:03 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> Message-ID: Hi Alex, I think the tty buffering should be a separate bug fix, and I'd also like input from Gary on it since he had tried something similar at one point. It should probably also include a multithread test to prove the fix is working (after first getting the test to fail without the changes). thanks, Chris On 10/16/18 8:59 PM, Daniil Titov wrote: > Hi Alex, Chris and JC, > > Please review an updated version of the patch that addresses these issues. > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Thanks! > --Daniil > > > ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: > > Hi Daniil, > > 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL > > 2) wrong indent in JdbStopThreadTest.java: > 36 import lib.jdb.JdbCommand; > 37 import lib.jdb.JdbTest; > > 3) I think it would be better to make waitForSimplePrompt property of > JdbCommand (like JdbCommand.allowExit) > > jdb.command(JdbCommand.run().replyIsSimplePrompt()); > looks much clearer than > jdb.command(JdbCommand.run(), true); > > 4) (TTY.java) > MessageOutput.lnprint("Breakpoint hit:"); > + // Print current location and prompt if suspend policy is > SUSPEND_EVENT_THREAD. > + // In case of SUSPEND_ALL policy this is handled by vmInterrupted() > method. > + if (be.request().suspendPolicy() == EventRequest.SUSPEND_EVENT_THREAD) { > + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); > + MessageOutput.printPrompt(); > + } > We have 3 separate outputs. > If we have several concurrent threads, we can easy get mess of outputs > from different threads. > I think it would be better to print everything in a single chunk. > I suppose TTY has other places with similar "non-atomic" output, so > maybe revising TTY output should be handled by separate issue. > > --alex > > On 10/11/2018 22:00, Chris Plummer wrote: > > Hi Daniil, > > > > Can you send output from an example jdb session? > > > > Do you think maybe we should also call printCurrentLocation() when the > > suspend policy is NONE? > > > > There's a typo in the following line. The space is on the wrong side of > > the comma. > > > > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine)); > > > > thanks, > > > > Chris > > > > On 10/11/18 8:02 PM, Daniil Titov wrote: > >> > >> Thank you, JC! > >> > >> Please review an updated version of the patch that fixes newly added > >> test for Windows platform (now it uses system dependent line > >> separator string). > >> > >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ > >> > >> > >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > >> > >> Best regards, > >> > >> --Daniil > >> > >> *From: *JC Beyler > >> *Date: *Thursday, October 11, 2018 at 7:17 PM > >> *To: * > >> *Cc: * > >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when breakpoint > >> is hit and suspend policy is STOP_EVENT_THREAD > >> > >> Hi Daniil, > >> > >> Looks good to me. I saw a really small nit: > >> > >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html > >> > >> > >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS ,bpLine)); > >> > >> There is a space after the '('. > >> > >> No need to send a new webrev for that evidently :), > >> > >> Jc > >> > >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov > >> > wrote: > >> > >> Please review the change that fixes the issue with missing prompt > >> in jdb when a breakpoint is hit and the suspend policy is set to > >> stop the thread only. > >> > >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 > >> > >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > >> > >> Thanks! > >> --Daniil > >> > >> > >> > >> -- > >> > >> Thanks, > >> > >> Jc > >> > > > > > From mandy.chung at oracle.com Wed Oct 17 17:50:28 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 17 Oct 2018 10:50:28 -0700 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: Hi Sven, This NetBeans SamplesOutputStream calls sun.management.ThreadInfoCompositeData.toCompositeData which is an internal API.? It will be inaccessible when strong encapsulation is enabled. Have you looked into javax.management API to get the CompositeData directly? Mandy On 10/15/18 10:51 AM, Mandy Chung wrote: > Hi Sven, > > It's indeed a bug in the order of names and values when constructing > CompositeData for StackTraceElement.? I created > https://bugs.openjdk.java.net/browse/JDK-8212197 for this issue. > > Mandy > > On 10/14/18 3:52 PM, David Holmes wrote: >> Hi Sven, >> >> Moving to serviceability-dev mailing list. Please don't reply to >> jdk-dev. >> >> Thanks, >> David >> >> On 15/10/2018 5:42 AM, Sven Reimers wrote: >>> Hi all, >>> >>> I hope this is the correct e-mailing list. During out testing of Apache >>> NetBeans 10 we discovered a problem with self sampling capability of >>> NetBeans. Digging further into this problem (NETBEANS-1359 >>> ) I debugged >>> through >>> the code and it seems that there is a problem with the order of the >>> values >>> and the order of the attributes. >>> >>> ?From the code I see the order of the values is >>> >>> ???????? final Object[] stackTraceElementItemValues = { >>> ???????????? ste.getClassLoaderName(), >>> ???????????? ste.getModuleName(), >>> ???????????? ste.getModuleVersion(), >>> ???????????? ste.getClassName(), >>> ???????????? ste.getMethodName(), >>> ???????????? ste.getFileName(), >>> ???????????? ste.getLineNumber(), >>> ???????????? ste.isNativeMethod(), >>> ???????? }; >>> >>> compared to? the order of the attributes >>> >>> >>> ???? private static final String[] V5_ATTRIBUTES = { >>> ???????? CLASS_NAME, >>> ???????? METHOD_NAME, >>> ???????? FILE_NAME, >>> ???????? LINE_NUMBER, >>> ???????? NATIVE_METHOD, >>> ???? }; >>> >>> ???? private static final String[] V9_ATTRIBUTES = { >>> ???????? CLASS_LOADER_NAME, >>> ???????? MODULE_NAME, >>> ???????? MODULE_VERSION, >>> ???? }; >>> >>> ???? private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = >>> ???????? Stream.of(V5_ATTRIBUTES, >>> V9_ATTRIBUTES).flatMap(Arrays::stream) >>> ?????????????? .toArray(String[]::new); >>> >>> which can be expanded to >>> >>> ???????? CLASS_NAME, >>> ???????? METHOD_NAME, >>> ???????? FILE_NAME, >>> ???????? LINE_NUMBER, >>> ???????? NATIVE_METHOD, >>> ???????? CLASS_LOADER_NAME, >>> ???????? MODULE_NAME, >>> ???????? MODULE_VERSION, >>> >>> With the difference in ordering you will get an exception? in >>> CompositeDataSupport, if you try to convert things (lines 228ff) >>> >>> ???????? // Check each value, if not null, is of the open type >>> defined for >>> the >>> ???????? // corresponding item >>> ???????? for (String name : namesFromType) { >>> ???????????? Object value = items.get(name); >>> ???????????? if (value != null) { >>> ???????????????? OpenType itemType = compositeType.getType(name); >>> ???????????????? if (!itemType.isValue(value)) { >>> ???????????????????? throw new OpenDataException( >>> ???????????????????????????? "Argument value of wrong type for item >>> " + name >>> + >>> ???????????????????????????? ": value " + value + ", type " + >>> itemType); >>> ???????????????? } >>> ???????????? } >>> ???????? } >>> >>> which is hard to compensate from the caller side. >>> >>> I think the change, which introduced this was >>> >>> https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470 >>> >>> >>> The proposed patch seems simple, just change the ordering of the >>> attributes >>> >>> ?? private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = >>> ???????? Stream.of(V9_ATTRIBUTES, >>> V5_ATTRIBUTES).flatMap(Arrays::stream) >>> ?????????????? .toArray(String[]::new); >>> >>> or change the value ordering to fit the attributes order. >>> >>> Can anyone confirm the analysis? >>> >>> Thanks >>> >>> -Sven >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Oct 17 18:04:06 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Oct 2018 11:04:06 -0700 Subject: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java In-Reply-To: <5BC7674F.5070501@oracle.com> References: <5BC7674F.5070501@oracle.com> Message-ID: Hi Gary, Can this be on one line now: ? 30? * @modules ? 31? *????????? jdk.jdi What are you blocking all jdk.* classes from redef when you pointed out that only jdk.internal.* is an issue? Is this also addressing JDK-8180804? If not, should it stay on the problem list until JDK-8180804 is fixed? thanks, Chris On 10/17/18 9:46 AM, Gary Adams wrote: > The RedefineCrossEvent test has been on been on the ProblemList for a > very long time. > In the past this test had some dependency on the Java EE modules, but > they? were > deprecated for jdk9 and later removed completely in jdk11. This > changeset to restore > it, removes the corba module reference and blocks the redefine operations > for jdk.internal classes that presented an issue when the > RedefineCrossEvent > test launches the InstanceFilter test. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8206330 > ? Webrev: http://cr.openjdk.java.net/~gadams/8206330/webrev/index.html From chris.plummer at oracle.com Wed Oct 17 18:10:15 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Oct 2018 11:10:15 -0700 Subject: Restoring nsk/jvmti/scenarios/hotswap tests from ProblemList.txt In-Reply-To: <5BC720C5.4060907@oracle.com> References: <5BC720C5.4060907@oracle.com> Message-ID: <62d1bc9e-400a-70bf-b4c2-05266b66b575@oracle.com> The changes look fine. thanks, Chris On 10/17/18 4:45 AM, Gary Adams wrote: > While investigating other issues with hotswap tests I noticed > 2 tests on the Problemlist that I think can be restored. > > I have not been able to reproduce the failure with hs102t002 > It is marked in the ProblemList as related to JDK-8203350, > but that bug is about hs201t002. It is also marked as related > to JDK-8204506, which is concerned with test hs102t002, but > is specific to a graal failure and is already recorded in > ProblemList-graal.txt > > ? https://bugs.openjdk.java.net/browse/JDK-8203350 > ? https://bugs.openjdk.java.net/browse/JDK-8204506 > > I did run into some intermittent failures with hs204t001 and the > utility class ExecDriver. It appears that it took advantage of other > tests > building the class file. A simple directive to build ExecDirver will > bring it > in line with the other hotswap tests. > > diff --git a/test/hotspot/jtreg/ProblemList.txt > b/test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -184,8 +184,6 @@ > ?vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted004/TestDescription.java > 7013634,6606767 generic-all > ?vmTestbase/nsk/jvmti/ThreadStart/threadstart001/TestDescription.java > 8016181 generic-all > ?vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/TestDescription.java > 8173658 generic-all > -vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t002/TestDescription.java > 8204506,8203350 generic-all > -vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > 6813266 generic-all > ?vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/TestDescription.java > 8051349 generic-all > ?vmTestbase/nsk/jvmti/AttachOnDemand/attach034/TestDescription.java > 8042145 generic-all > ?vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java > 8202971 generic-all > > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > > --- > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > +++ > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java > @@ -46,7 +46,8 @@ > ? * @library /vmTestbase > ? *????????? /test/lib > ? * @run driver jdk.test.lib.FileInstaller . . > - * @build nsk.jvmti.scenarios.hotswap.HS204.hs204t001.hs204t001 > + * @build ExecDriver > + *????? nsk.jvmti.scenarios.hotswap.HS204.hs204t001.hs204t001 > ? * > ? * @comment compile newclassXX to bin/newclassXX > ? * @run driver nsk.share.ExtraClassesBuilder > From sven.reimers at gmail.com Wed Oct 17 18:48:07 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Wed, 17 Oct 2018 20:48:07 +0200 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: Hi Mandy, Thanks for the pointer. I have not yet investigated the usage, but will check if we can use the official API instead. Thanks again for the quick response. -Sven Mandy Chung schrieb am Mi., 17. Okt. 2018, 19:50: > Hi Sven, > > This NetBeans SamplesOutputStream calls > sun.management.ThreadInfoCompositeData.toCompositeData > which is an internal API. It will be inaccessible when > strong encapsulation is enabled. > > Have you looked into javax.management API to get the > CompositeData directly? > > Mandy > > On 10/15/18 10:51 AM, Mandy Chung wrote: > > Hi Sven, > > It's indeed a bug in the order of names and values when constructing > CompositeData for StackTraceElement. I created > https://bugs.openjdk.java.net/browse/JDK-8212197 for this issue. > > Mandy > > On 10/14/18 3:52 PM, David Holmes wrote: > > Hi Sven, > > Moving to serviceability-dev mailing list. Please don't reply to jdk-dev. > > Thanks, > David > > On 15/10/2018 5:42 AM, Sven Reimers wrote: > > Hi all, > > I hope this is the correct e-mailing list. During out testing of Apache > NetBeans 10 we discovered a problem with self sampling capability of > NetBeans. Digging further into this problem (NETBEANS-1359 > > ) I debugged through > the code and it seems that there is a problem with the order of the values > and the order of the attributes. > > From the code I see the order of the values is > > final Object[] stackTraceElementItemValues = { > ste.getClassLoaderName(), > ste.getModuleName(), > ste.getModuleVersion(), > ste.getClassName(), > ste.getMethodName(), > ste.getFileName(), > ste.getLineNumber(), > ste.isNativeMethod(), > }; > > compared to the order of the attributes > > > private static final String[] V5_ATTRIBUTES = { > CLASS_NAME, > METHOD_NAME, > FILE_NAME, > LINE_NUMBER, > NATIVE_METHOD, > }; > > private static final String[] V9_ATTRIBUTES = { > CLASS_LOADER_NAME, > MODULE_NAME, > MODULE_VERSION, > }; > > private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = > Stream.of(V5_ATTRIBUTES, V9_ATTRIBUTES).flatMap(Arrays::stream) > .toArray(String[]::new); > > which can be expanded to > > CLASS_NAME, > METHOD_NAME, > FILE_NAME, > LINE_NUMBER, > NATIVE_METHOD, > CLASS_LOADER_NAME, > MODULE_NAME, > MODULE_VERSION, > > With the difference in ordering you will get an exception in > CompositeDataSupport, if you try to convert things (lines 228ff) > > // Check each value, if not null, is of the open type defined for > the > // corresponding item > for (String name : namesFromType) { > Object value = items.get(name); > if (value != null) { > OpenType itemType = compositeType.getType(name); > if (!itemType.isValue(value)) { > throw new OpenDataException( > "Argument value of wrong type for item " + > name > + > ": value " + value + ", type " + itemType); > } > } > } > > which is hard to compensate from the caller side. > > I think the change, which introduced this was > > > https://github.com/openjdk/jdk/commit/9091926ae64690982d59f1d634f96bb9b79a5470 > > The proposed patch seems simple, just change the ordering of the > attributes > > private static final String[] STACK_TRACE_ELEMENT_ATTRIBUTES = > Stream.of(V9_ATTRIBUTES, V5_ATTRIBUTES).flatMap(Arrays::stream) > .toArray(String[]::new); > > or change the value ordering to fit the attributes order. > > Can anyone confirm the analysis? > > Thanks > > -Sven > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Wed Oct 17 19:40:44 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Wed, 17 Oct 2018 15:40:44 -0400 Subject: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java In-Reply-To: References: <5BC7674F.5070501@oracle.com> Message-ID: <9cb267ea-ad1f-2728-a616-34cc52b08859@oracle.com> On 10/17/18 2:04 PM, Chris Plummer wrote: > Hi Gary, > > Can this be on one line now: > > ? 30? * @modules > ? 31? *????????? jdk.jdi OK > > What are you blocking all jdk.* classes from redef when you pointed > out that only jdk.internal.* is an issue? The file I'm modifying already has some blocking checks that look for java., com, and sun., so it seemed appropriate that the jdk. prefix was appropriate for this check. > > Is this also addressing JDK-8180804? If not, should it stay on the > problem list until JDK-8180804 is fixed? I'll run through the usual testing to see if I can force the timeout. Since the test has been on the ProblemList for a year and half it is hard to know if this is an intermittent failure or not. If I can't reproduce the failure, then I'd like to go ahead with this change and see if it shows up again. The original reason the test was placed on the ProblemList was because of the removal of java ee modules, not because of the timeout that was observed. > > thanks, > > Chris > > On 10/17/18 9:46 AM, Gary Adams wrote: >> The RedefineCrossEvent test has been on been on the ProblemList for a >> very long time. >> In the past this test had some dependency on the Java EE modules, but >> they? were >> deprecated for jdk9 and later removed completely in jdk11. This >> changeset to restore >> it, removes the corba module reference and blocks the redefine >> operations >> for jdk.internal classes that presented an issue when the >> RedefineCrossEvent >> test launches the InstanceFilter test. >> >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8206330 >> ? Webrev: http://cr.openjdk.java.net/~gadams/8206330/webrev/index.html > > > From chris.plummer at oracle.com Wed Oct 17 19:58:53 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Oct 2018 12:58:53 -0700 Subject: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java In-Reply-To: <9cb267ea-ad1f-2728-a616-34cc52b08859@oracle.com> References: <5BC7674F.5070501@oracle.com> <9cb267ea-ad1f-2728-a616-34cc52b08859@oracle.com> Message-ID: On 10/17/18 12:40 PM, gary.adams at oracle.com wrote: > On 10/17/18 2:04 PM, Chris Plummer wrote: >> Hi Gary, >> >> Can this be on one line now: >> >> ? 30? * @modules >> ? 31? *????????? jdk.jdi > OK >> >> What are you blocking all jdk.* classes from redef when you pointed >> out that only jdk.internal.* is an issue? > The file I'm modifying already has some blocking checks that look > for java., com, and sun., so it seemed appropriate that the jdk. prefix > was appropriate for this check. Ok. >> >> Is this also addressing JDK-8180804? If not, should it stay on the >> problem list until JDK-8180804 is fixed? > I'll run through the usual testing to see if I can force the timeout. > Since the test has been on the ProblemList for a year and half > it is hard to know if this is an intermittent failure or not. > > If I can't reproduce the failure, then I'd like to go ahead with this > change and see if it shows up again. > Ok. > The original reason the test was placed on the ProblemList > was because of the removal of java ee modules, not because of the > timeout that was observed. Yes, I realize that. But if the timeout is also somewhat new, it could be problematic enough to warrant keeping it on the problem list. thanks, Chris >> >> thanks, >> >> Chris >> >> On 10/17/18 9:46 AM, Gary Adams wrote: >>> The RedefineCrossEvent test has been on been on the ProblemList for >>> a very long time. >>> In the past this test had some dependency on the Java EE modules, >>> but they? were >>> deprecated for jdk9 and later removed completely in jdk11. This >>> changeset to restore >>> it, removes the corba module reference and blocks the redefine >>> operations >>> for jdk.internal classes that presented an issue when the >>> RedefineCrossEvent >>> test launches the InstanceFilter test. >>> >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8206330 >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8206330/webrev/index.html >> >> >> > From hohensee at amazon.com Wed Oct 17 20:01:47 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Oct 2018 20:01:47 +0000 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> Message-ID: <71A6706A-B1C5-46CD-927B-BE07538AB779@amazon.com> Re spaces :). There?s a bunch of places where ?(jvmti_env? should be ?( jvmti_env?, but of course not all of them. I found a bunch. Otherwise, lgtm., no need for another webrev. Paul In hs104t002.cpp - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, - &caps) )) { + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { => + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { In hs203t003.cpp - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB4(GetClassSignature, - jvmti_env, klass, &className, &generic) ) ) { + if ( ! NSK_JVMTI_VERIFY (jvmti_env->GetClassSignature(klass, &className, &generic) ) ) { => + if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GetClassSignature(klass, &className, &generic) ) ) { and - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) )) { + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { => + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { and - if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, thread, &state) ) ) { + if ( ! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state) ) ) { => + if ( ! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state) ) ) { and - if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, thread, &state) ) ) { + if ( ! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state) ) ) { nsk_printf(" Agent :: Error while getting thread state.\n"); nsk_jvmti_agentFailed(); } else { if ( state & JVMTI_THREAD_STATE_SUSPENDED) { - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2( PopFrame, jvmti, thread) ) ) { + if ( ! NSK_JVMTI_VERIFY (jvmti->PopFrame(thread) ) ) { => + if ( ! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state) ) ) { ? + if ( ! NSK_JVMTI_VERIFY ( jvmti->PopFrame(thread) ) ) { and - if ( !NSK_JVMTI_VERIFY( NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)) ) { + if ( !NSK_JVMTI_VERIFY(jvmti->ResumeThread(thread)) ) { => + if ( !NSK_JVMTI_VERIFY( jvmti->ResumeThread(thread)) ) { In hs203t004.cpp - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(GenerateEvents, jvmti_env, - JVMTI_EVENT_COMPILED_METHOD_LOAD ) )) { + if ( ! NSK_JVMTI_VERIFY (jvmti_env->GenerateEvents(JVMTI_EVENT_COMPILED_METHOD_LOAD) )) { => + if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GenerateEvents(JVMTI_EVENT_COMPILED_METHOD_LOAD) )) { and - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB3(GetMethodDeclaringClass, - jvmti_env, method, &threadClass) ) ) { + if ( ! NSK_JVMTI_VERIFY (jvmti_env->GetMethodDeclaringClass(method, &threadClass) ) ) { => + if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GetMethodDeclaringClass(method, &threadClass) ) ) { and - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) )) { + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { => + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { and - if ( NSK_JVMTI_VERIFY( NSK_CPP_STUB2(SuspendThread, jvmti, thread) ) ) { + if ( NSK_JVMTI_VERIFY(jvmti->SuspendThread(thread) ) ) { => + if ( NSK_JVMTI_VERIFY( jvmti->SuspendThread(thread) ) ) { and - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB3(GetThreadState, jvmti, - thread, &state) ) ) { + if ( ! NSK_JVMTI_VERIFY (jvmti->GetThreadState(thread, &state) ) ) { NSK_COMPLAIN0("#error Agent :: while getting thread's state.\n"); nsk_jvmti_agentFailed(); } else { if ( state & JVMTI_THREAD_STATE_SUSPENDED) { - if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB2(PopFrame, jvmti, thread) ) ){ + if ( ! NSK_JVMTI_VERIFY(jvmti->PopFrame(thread) ) ){ => + if ( ! NSK_JVMTI_VERIFY ( jvmti->GetThreadState(thread, &state) ) ) { ? + if ( ! NSK_JVMTI_VERIFY( jvmti->PopFrame(thread) ) ){ In hs204t001.cpp - /* if( (myTestClass =NSK_CPP_STUB2(NewGlobalRef,jni_env, klass)) == NULL) { + /* if( (myTestClass =jni_env->NewGlobalRef(klass)) == NULL) { => + /* if( (myTestClass = jni_env->NewGlobalRef(klass)) == NULL) { and - if (!NSK_JNI_VERIFY(env, (testClass =(jclass) NSK_CPP_STUB2(NewGlobalRef, env, klass)) != NULL)) + if (!NSK_JNI_VERIFY(env, (testClass =(jclass) env->NewGlobalRef(klass)) != NULL)) nsk_jvmti_setFailStatus(); - if (!NSK_JNI_VERIFY(env, (testedThread =NSK_CPP_STUB2(NewGlobalRef, env, thread)) != NULL)) + if (!NSK_JNI_VERIFY(env, (testedThread =env->NewGlobalRef(thread)) != NULL)) => + if (!NSK_JNI_VERIFY(env, (testClass = (jclass) env->NewGlobalRef(klass)) != NULL)) nsk_jvmti_setFailStatus(); ? + if (!NSK_JNI_VERIFY(env, (testedThread = env->NewGlobalRef(thread)) != NULL)) and - if (!NSK_JVMTI_VERIFY( NSK_CPP_STUB2(SuspendThread, jvmti, thread))) { + if (!NSK_JVMTI_VERIFY( jvmti->SuspendThread(thread))) { => + if (!NSK_JVMTI_VERIFY(jvmti->SuspendThread(thread))) { In hs204t003.cpp - if (! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, thread, &state)) ){ + if (! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state)) ){ NSK_DISPLAY0(" Agent :: Error getting thread state.\n"); nsk_jvmti_agentFailed(); } else { if ( state & JVMTI_THREAD_STATE_SUSPENDED) { NSK_DISPLAY0(" Agent :: Thread state = JVMTI_THREAD_STATE_SUSPENDED.\n"); - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(PopFrame, jvmti, thread) ) ) { + if ( ! NSK_JVMTI_VERIFY (jvmti->PopFrame(thread) ) ) { NSK_DISPLAY0("#error Agent :: Jvmti failed to do popFrame.\n"); nsk_jvmti_agentFailed(); } else { - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(ResumeThread, jvmti, thread)) ) { + if ( ! NSK_JVMTI_VERIFY (jvmti->ResumeThread(thread)) ) { => + if (! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state)) ){ ? + if ( ! NSK_JVMTI_VERIFY ( jvmti->PopFrame(thread) ) ) { ? + if ( ! NSK_JVMTI_VERIFY ( jvmti->ResumeThread(thread)) ) { In hs301t001.cpp - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) )) { + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { => + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { In hs301t002.cpp - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) ) ) { + if ( ! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) ) ) { => + if ( ! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) ) ) { In hs301t003.cpp - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB4(GetClassSignature, - jvmti_env, klass, &className, &generic) ) ) { + if ( ! NSK_JVMTI_VERIFY (jvmti_env->GetClassSignature(klass, &className, &generic) ) ) { => + if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GetClassSignature(klass, &className, &generic) ) ) { and - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) )) { + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { => + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { and - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, - jvmti, &caps) )) { + if ( ! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { => + if ( ! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { From: serviceability-dev on behalf of JC Beyler Date: Tuesday, October 16, 2018 at 4:24 PM To: "alexey.menkov at oracle.com" Cc: "serviceability-dev at openjdk.java.net" Subject: Re: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] Hi all, How about on a Tuesday? :) Sneak peak and motivational sentence: after this goes in, we have this one which removes the NSK_CPP_STUBs from the tests entirely! :) Jc On Fri, Oct 12, 2018 at 5:37 PM JC Beyler > wrote: Hi all, Any chance for a second reviewer on a Friday? :) Jc On Thu, Oct 11, 2018 at 11:03 AM Alex Menkov > wrote: got it. LGTM. --alex On 10/10/2018 19:03, JC Beyler wrote: > Hi Alex, > > Thanks for the review! Yes I had seen that too before sending this > review out and forked that fix into this: > https://bugs.openjdk.java.net/browse/JDK-8211905 > > Which now is merged and I've updated my webrev to reflect this of course. > > My rationale for not doing it here directly is always the same: keeping > the changes to the "spirit" of what the change is trying to do. Those > extra casts were a bit out-of-scope and so I just forked the fix in 8211905. > > Thanks! > Jc > > On Wed, Oct 10, 2018 at 5:40 PM Alex Menkov > >> wrote: > > Hi Jc, > > Overall looks good. > > one minor note: > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: > - jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > (jstring) (jstring) (jstring) (jstring) NSK_CPP_STUB3(CallObjectMethod, > jni_env, klass, > - methodID); > + jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > (jstring) (jstring) (jstring) (jstring) > jni_env->CallObjectMethod(klass, > methodID); > > Please drop multi "(jstring)" > > --alex > > On 10/08/2018 21:21, JC Beyler wrote: > > Hi all, > > > > I am continuing the NSK_CPP_STUB removal with this next webrev. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 > > > > The change is still straight-forward though, since it is just > doing the > > same NSK_CPP_STUB removal. However when I was looking at the > changes, a > > lot of these changes are touching lines with spaces before/after > > parenthesis. I've almost never touched the spaces except if I was > > refactoring by hand the line at the same time. The rationale > being that > > the lines will get fixed a few more times and are, at worse, > covered by > > the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which > I've > > commited to doing. > > > > Two exceptions are here where I pushed out the code into > assignments due > > to really long lines and complex if structures: > > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp > > > > > - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp > > > > > > > And one exception here where a commented line was doing the > out-of-if > > assignment so I just uncommented it and used the variable: > > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp > > > > > > > I've tested the modified changes on my machine, all modified > tests pass. > > > > Let me know what you think, > > Jc > > > > Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* > > > > > > -- > > Thanks, > Jc -- Thanks, Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Wed Oct 17 20:14:58 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Oct 2018 20:14:58 +0000 Subject: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results In-Reply-To: <7565CED8-5174-4CB2-8AC1-F2544BD3B316@amazon.com> References: <7565CED8-5174-4CB2-8AC1-F2544BD3B316@amazon.com> Message-ID: <22380FF1-A213-464A-9F5B-8A7D6815909E@amazon.com> Ping. Reviews please, before the cutoff? Thanks, Paul From: hotspot-gc-dev on behalf of "Hohensee, Paul" Date: Friday, October 12, 2018 at 10:14 AM To: JC Beyler Cc: "serviceability-dev at openjdk.java.net" , "jdk8u-dev at openjdk.java.net" , "hotspot-gc-dev at openjdk.java.net" Subject: Re: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Thanks for the review, new webrev at http://cr.openjdk.java.net/~phh/8195115/webrev.06/. The different requires were an artifact of me trying to get TestOldGenCollectionUsage.java to run. Good catch. Jiangli changed the heap size to 14m to get it to work with CDS, see https://bugs.openjdk.java.net/browse/JDK-8210193. Paul From: JC Beyler Date: Thursday, October 11, 2018 at 10:37 PM To: "Hohensee, Paul" Cc: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" , "jdk8u-dev at openjdk.java.net" Subject: Re: RFR: Backport 8195115: G1 Old Gen MemoryPool CollectionUsage.used values don't reflect mixed GC results Hi Paul, The biggest thing I saw in this RFR was that the flags for the test: http://cr.openjdk.java.net/~phh/8195115/webrev.05/test/gc/g1/mixedgc/TestOldGenCollectionUsage.java.html were changed it seems: - the @requires are different for the backport (you accept null for JDK8 for GC and also removed the @requires vm.opt.MaxGCPauseMillis == "null") - the @run flags are different (-Xms/Xmx are 14m for the backport; they were 12 originally; there is a comment below in the backport saying this requires normally 12m though you ask for 14 in the @run) What are the reasons for these differences? Apart from that, the backport seemed ok but I'm not that well versed in the GC changes :) Jc On Thu, Oct 11, 2018 at 5:04 PM Hohensee, Paul > wrote: Please review a backport to jdk8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8195115 Webrev: http://cr.openjdk.java.net/~phh/8195115/webrev.05/ JDK11 patch: http://hg.openjdk.java.net/jdk/jdk/rev/5d3c5af82654 The backport is slightly different from the JDK11 patch due to G1 refactoring, hence my request for new review. I?ll ask for jdk8u approval once the backport is reviewed. I backported two jtreg tests from JDK11, which pass. Also, all the hotspot gc jtreg tests pass as well as they do for jdk8u-dev. There was a CSR involved, https://bugs.openjdk.java.net/browse/JDK-8196719. Does that have to be re-approved for jdk8u as well, and if so, what?s the process? Thanks, Paul -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Wed Oct 17 20:17:25 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 17 Oct 2018 20:17:25 +0000 Subject: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> Message-ID: Ping. From: serviceability-dev on behalf of "Hohensee, Paul" Date: Thursday, October 11, 2018 at 6:46 PM To: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" Subject: Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions Any takers? :) From: serviceability-dev on behalf of "Hohensee, Paul" Date: Monday, October 8, 2018 at 7:50 PM To: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" Subject: RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions Bug: https://bugs.openjdk.java.net/browse/JDK-8196989 CSR: https://bugs.openjdk.java.net/browse/JDK-8196991 Webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.02/ As requested, I split the jstat counter update off from the MXBean update. This is the MXBean update. The jstat counter RFE is https://bugs.openjdk.java.net/browse/JDK-8210965 and its CSR is https://bugs.openjdk.java.net/browse/JDK-8210966. The MXBean CSR is in draft state, I?d greatly appreciate review and sign-off. It?s been suggested that we add another pool to represent the free region set, but doing so would be incompatible with existing MXBean use invariants for all GCs. These are: 1. The sum of the pools? MemoryUsage.max properties is the total reserved heap size. 2. The sum of the pools? MemoryUsage.committed properties is the total committed size. 3. The sum of the pools? MemoryUsage.used properties is the total size of the memory containing objects, live and dead-and-yet-to-be-collected, as the case might be, plus intentional gaps between them. 4. The total free space is (sum of the max properties ? sum of the used properties). 5. The total uncommitted space is (sum of the max properties ? sum of the committed properties). 6. The total committed free space is (2) ? (3). To keep invariants 1, 2 and 3, the free region pool?s ?max? property should be ?undefined? (i.e., -1). The intuitive, to me, ?used? property value would be the total free space, but that would violate invariant 4 above. Defining the ?committed? property as the total committed free space would violate invariants 2 and 6. The patch passes the submit repo, hotspot tier1, and, separately, the serviceability, jfr, and gc jtreg tests. I?m uncertain how to construct a test that checks for valid MXBean content: the existing tests don?t. Any such test will be fragile due to possible future Hotspot changes that affect the values, and to run-to-run variability. I?ve done by-hand comparisons between the old and new MXBean content using the SwingSet2 demo, including using App CDS, and the numbers look reasonable. The guts of the change are in G1MonitoringSupport::recalculate_sizes, initialize_serviceability, memory_managers, memory_pools, and G1MonitoringScope. I also defined TraceConcMemoryManagerStats to track the concurrent cycle in a way analogous to TraceCMSMemoryManagerStats. The changes to the includes in g1FullGCOopClosures.inline.hpp and g1HeapVerifier.cpp are to satisfy compiler complaints. I changed the 3rd argument to the G1MonitoringScope constructor to a mixed_gc flag, and use accessor methods instead of direct field accesses when accessor methods exist. I believe I?ve minimized the latter. I updated the copyright date to 2018 in memoryService.hpp because I neglected to do so in my previous G1 MXBean patch. Thanks, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Oct 17 20:41:55 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 17 Oct 2018 13:41:55 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: Message-ID: On 10/16/18 7:33 PM, David Holmes wrote: > Hi Dean, > > Thanks for tackling this. > > I'm still struggling to fully grasp why we need both the PerfCounters > and the regular counters. I get that we have to decrement the live > counts before ensure_join() has allowed Thread.join() to return, to > ensure that if we then check the number of threads it has dropped by > one. But I don't understand why that means we need to manage the > thread count in two parts. Particularly as now you don't use the > PerfCounter to return the live count, so it makes me wonder what role > the PerfCounter is playing as it is temporarily inconsistent with the > reported live count? Perf counters were added long time back in JDK 1.4.2 for performance measurement before java.lang.management API.? One can use jstat tool to monitor VM perf counters of a running VM.?? One could look into the possibility of deprecating these counters and remove them over time. > On 17/10/2018 9:43 AM, dean.long at oracle.com wrote: > New webrev: > > http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ When the perf counters are updated when a thread is added/removed, it's holding Threads_lock.? Are the asserts in ThreadService::remove_thread necessary? For clarify, I think we could simply set _live_threads_count to the value of _atomic_threads_count and set _daemon_threads_count to the value of _atomic_daemon_threads_count. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Oct 17 20:46:30 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 17 Oct 2018 13:46:30 -0700 Subject: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> Message-ID: Hi Paul, I looked at this but it took time for me to "digest" it and I haven't entirely gone through the real GC changes :) My few remarks on the webrev itself are: - http://cr.openjdk.java.net/~phh/8196989/webrev.02/src/hotspot/share/services/memoryService.hpp.udiff.html - There is no need to change the copyright, right? - http://cr.openjdk.java.net/~phh/8196989/webrev.02/test/hotspot/jtreg/gc/TestMemoryMXBeansAndPoolsPresence.java.udiff.html - the break seems to be on the wrong line, no? + } break; - http://cr.openjdk.java.net/~phh/8196989/webrev.02/test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest.java.udiff.html and http://cr.openjdk.java.net/~phh/8196989/webrev.02/test/jdk/java/lang/management/MemoryMXBean/MemoryManagement.java.udiff.html + // In G1, humongous objects are tracked in the old space only in + // legacy monitoring mode. In default mode, G1 tracks humongous + // objects in the humongous space, which latter also supports a + // usage threshold. Since we're allocating humongous objects in + // this test, in default mode the old space doesn't change. For + // this test, we use the old space in legacy mode (it's called + // "G1 Old Gen" and the humongous space in default mode. If we + // used "G1 Old Space" in default mode, notification would never + // happen. -> latter seems ot be the wrong word or something is missing in that sentence -> the parenthesis is never closed (it's called.... is missing a ) somewhere Thanks, Jc On Wed, Oct 17, 2018 at 1:18 PM Hohensee, Paul wrote: > Ping. > > > > *From: *serviceability-dev > on behalf of "Hohensee, Paul" > *Date: *Thursday, October 11, 2018 at 6:46 PM > *To: *"hotspot-gc-dev at openjdk.java.net" , > "serviceability-dev at openjdk.java.net" > > *Subject: *Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector > MXBean definitions > > > > Any takers? :) > > > > *From: *serviceability-dev > on behalf of "Hohensee, Paul" > *Date: *Monday, October 8, 2018 at 7:50 PM > *To: *"hotspot-gc-dev at openjdk.java.net" , > "serviceability-dev at openjdk.java.net" > > *Subject: *RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector > MXBean definitions > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196989 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8196991 > > Webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.02/ > > > > As requested, I split the jstat counter update off from the MXBean update. > This is the MXBean update. The jstat counter RFE is > https://bugs.openjdk.java.net/browse/JDK-8210965 and its CSR is > https://bugs.openjdk.java.net/browse/JDK-8210966. > > > > The MXBean CSR is in draft state, I?d greatly appreciate review and > sign-off. > > > > It?s been suggested that we add another pool to represent the free region > set, but doing so would be incompatible with existing MXBean use invariants > for all GCs. These are: > > > > 1. The sum of the pools? MemoryUsage.max properties is the total > reserved heap size. > 2. The sum of the pools? MemoryUsage.committed properties is the total > committed size. > 3. The sum of the pools? MemoryUsage.used properties is the total size > of the memory containing objects, live and dead-and-yet-to-be-collected, as > the case might be, plus intentional gaps between them. > 4. The total free space is (sum of the max properties ? sum of the > used properties). > 5. The total uncommitted space is (sum of the max properties ? sum of > the committed properties). > 6. The total committed free space is (2) ? (3). > > > > To keep invariants 1, 2 and 3, the free region pool?s ?max? property > should be ?undefined? (i.e., -1). The intuitive, to me, ?used? property > value would be the total free space, but that would violate invariant 4 > above. Defining the ?committed? property as the total committed free space > would violate invariants 2 and 6. > > > > The patch passes the submit repo, hotspot tier1, and, separately, the > serviceability, jfr, and gc jtreg tests. I?m uncertain how to construct a > test that checks for valid MXBean content: the existing tests don?t. Any > such test will be fragile due to possible future Hotspot changes that > affect the values, and to run-to-run variability. I?ve done by-hand > comparisons between the old and new MXBean content using the SwingSet2 > demo, including using App CDS, and the numbers look reasonable. > > > > The guts of the change are in G1MonitoringSupport::recalculate_sizes, > initialize_serviceability, memory_managers, memory_pools, and > G1MonitoringScope. I also defined TraceConcMemoryManagerStats to track the > concurrent cycle in a way analogous to TraceCMSMemoryManagerStats. The > changes to the includes in g1FullGCOopClosures.inline.hpp and > g1HeapVerifier.cpp are to satisfy compiler complaints. I changed the 3rd > argument to the G1MonitoringScope constructor to a mixed_gc flag, and use > accessor methods instead of direct field accesses when accessor methods > exist. I believe I?ve minimized the latter. I updated the copyright date to > 2018 in memoryService.hpp because I neglected to do so in my previous G1 > MXBean patch. > > > > Thanks, > > > > Paul > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Wed Oct 17 21:10:48 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 17 Oct 2018 14:10:48 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: Message-ID: <81de4bbe-2461-e969-7b82-99a7854bb990@oracle.com> On 10/16/18 7:33 PM, David Holmes wrote: > Hi Dean, > > Thanks for tackling this. > > I'm still struggling to fully grasp why we need both the PerfCounters > and the regular counters. I get that we have to decrement the live > counts before ensure_join() has allowed Thread.join() to return, to > ensure that if we then check the number of threads it has dropped by > one. But I don't understand why that means we need to manage the > thread count in two parts. Particularly as now you don't use the > PerfCounter to return the live count, so it makes me wonder what role > the PerfCounter is playing as it is temporarily inconsistent with the > reported live count? Is it simply that we can't atomically decrement > the PerfCounters, and we can't require the Threads_lock when > decrementing? > Good questions.? I didn't know the history, so I tried not to change too much.? The PerfCounters appear to be there to support StatSampler.? I think it's OK for them to be a little out of sync. If we wanted to make them more in sync with the atomic counters, I think we could do any of the following: - Grab Threads_lock before SR_lock() where we call current_thread_exiting, and update perf counts at that time - instead of decrementing in remove_thread, do this in decrement_thread_counts ? _live_threads_count->set_value(_atomic_threads_count); ? _daemon_threads_count->set_value(_atomic_daemon_threads_count); ( I see that Mandy has suggested the same thing.) - DO update the perf counts atomically However, I consider the PerfCounters inconsistency a separate issue from this bug. > On the code itself one thing I find irksome is that we already have a > daemon flag in remove_thread but decrement_thread_counts doesn't get > passed that and so always re-examines the thread to see if it is a > daemon. I know only one of the code paths has the daemon flag, so > perhaps we should hoist the daemon check up into JavaThread::exit and > then pass a daemon parameter to decrement_thread_counts. > OK, I've fixed this. > There's also some ambiguity (existing) in relation to the existence of > the jt->threadObj() and its affect on whether the thread is considered > a daemon or not. Your check has to mirror the existing checks - the > threadObj may be NULL at removal if it was a failed attach, but the > addition considers a JNI-attached thread to be non-daemon. Overall > this seems buggy to me but as long as your check follows the same > rules that is okay. In that regard JavaThread::exit should never > encounter a NULL threadObj(). > I refactored is_daemon checks into a single helper function. > Minor nit: I suggest moving the two occurrences of the comment > > // Do not count VM internal or JVMTI agent threads > > inside is_hidden_thread so that we don't have to remember to update > the comments if the definition changes. > OK.? New webrev: http://cr.openjdk.java.net/~dlong/8021335/webrev.5/ dl > Thanks, > David > ----- > > On 17/10/2018 9:43 AM, dean.long at oracle.com wrote: >> New webrev: >> >> http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ >> >> dl >> >> On 10/16/18 11:59 AM, dean.long at oracle.com wrote: >>> On 10/16/18 10:28 AM, JC Beyler wrote: >>>> Hi Dean, >>>> >>>> I noticed a typo here : >>>> "are atomically" is in the comment but should no longer be there I >>>> believe; the sentence probably should be: >>>> // These 2 counters are like the above thread counts, but are >>>> >>> >>> Fixed! >>> >>>> Any way we could move this test into a helper method and both >>>> add_thread/current_thread_exiting could use the same "ignore" >>>> thread code so that we ensure the two never get out of sync? >>>> >>>> +? if (jt->is_hidden_from_external_view() || >>>> +? ? ? jt->is_jvmti_agent_thread()) { >>>> +? ? return; >>>> +? } >>>> >>> >>> Good idea.? Fixed. >>> >>>> (Also by curiosity, add_thread has an assert on the Threads_lock >>>> but not thread_exiting?) >>>> >>> >>> Right, I followed the existing pattern where >>> current_thread_exiting() only uses the atomic counters, so it >>> doesn't need Threads_lock. >>> >>> dl >>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> On Tue, Oct 16, 2018 at 9:52 AM >>> > wrote: >>>> >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8021335 >>>> ??? http://cr.openjdk.java.net/~dlong/8021335/webrev.3/ >>>> >>>> >>>> ??? This change attempts to fix an old and intermittent problem with >>>> ??? ThreadMXBean thread counts. >>>> ??? Changes have 3 main parts: >>>> ??? 1. Make sure hidden threads don't affect counts (even when >>>> exiting) >>>> ??? 2. Fix race reading counts using atomic counters >>>> ??? 3. Remove some workarounds in test (because they hide bugs) >>>> >>>> ??? dl >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >> From dean.long at oracle.com Wed Oct 17 21:13:57 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 17 Oct 2018 14:13:57 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: Message-ID: On 10/17/18 1:41 PM, Mandy Chung wrote: > > > On 10/16/18 7:33 PM, David Holmes wrote: >> Hi Dean, >> >> Thanks for tackling this. >> >> I'm still struggling to fully grasp why we need both the PerfCounters >> and the regular counters. I get that we have to decrement the live >> counts before ensure_join() has allowed Thread.join() to return, to >> ensure that if we then check the number of threads it has dropped by >> one. But I don't understand why that means we need to manage the >> thread count in two parts. Particularly as now you don't use the >> PerfCounter to return the live count, so it makes me wonder what role >> the PerfCounter is playing as it is temporarily inconsistent with the >> reported live count? > > Perf counters were added long time back in JDK 1.4.2 for performance > measurement before java.lang.management API.? One can use jstat tool > to monitor VM perf counters of a running VM.?? One could look into the > possibility of deprecating these counters and remove them over time. > >> On 17/10/2018 9:43 AM, dean.long at oracle.com wrote: >> New webrev: >> >> http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ > > When the perf counters are updated when a thread is added/removed, > it's holding Threads_lock.? Are the asserts in > ThreadService::remove_thread necessary? > Not really.? They were intended to catch the case where the atomic counters weren't decremented for some reason, not for the perf counters. Should I remove them? > For clarify, I think we could simply set _live_threads_count to the > value of _atomic_threads_count and set _daemon_threads_count to the > value of _atomic_daemon_threads_count. > I think that works, even inside decrement_thread_counts() without holding the Threads_lock.? If you agree, I'll make that change. dl > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Oct 17 21:38:41 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 17 Oct 2018 14:38:41 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: Message-ID: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> On 10/17/18 2:13 PM, dean.long at oracle.com wrote: > On 10/17/18 1:41 PM, Mandy Chung wrote: >> >> >> On 10/16/18 7:33 PM, David Holmes wrote: >>> Hi Dean, >>> >>> Thanks for tackling this. >>> >>> I'm still struggling to fully grasp why we need both the >>> PerfCounters and the regular counters. I get that we have to >>> decrement the live counts before ensure_join() has allowed >>> Thread.join() to return, to ensure that if we then check the number >>> of threads it has dropped by one. But I don't understand why that >>> means we need to manage the thread count in two parts. Particularly >>> as now you don't use the PerfCounter to return the live count, so it >>> makes me wonder what role the PerfCounter is playing as it is >>> temporarily inconsistent with the reported live count? >> >> Perf counters were added long time back in JDK 1.4.2 for performance >> measurement before java.lang.management API.? One can use jstat tool >> to monitor VM perf counters of a running VM.?? One could look into >> the possibility of deprecating these counters and remove them over time. >> >>> On 17/10/2018 9:43 AM, dean.long at oracle.com wrote: >>> New webrev: >>> >>> http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ >> >> When the perf counters are updated when a thread is added/removed, >> it's holding Threads_lock.? Are the asserts in >> ThreadService::remove_thread necessary? >> > > Not really.? They were intended to catch the case where the atomic > counters weren't decremented for some reason, not for the perf counters. > Should I remove them? > Hmm... when remove_thread is called but decrement_thread_counts has not been called. ? It's a bug in thread accounting.? It happens to have the perf counters that can be compared to assert.? It seems not obvious.? Setting the perf counters same values as _atomic_threads_count and _atomic_daemon_threads_count makes sense to me. I would opt for removing the asserts but I can't think of an alternative how to catch the issue you concern about. >> For clarify, I think we could simply set _live_threads_count to the >> value of _atomic_threads_count and set _daemon_threads_count to the >> value of _atomic_daemon_threads_count. >> > > I think that works, even inside decrement_thread_counts() without > holding the Threads_lock.? If you agree, I'll make that change. > +1 Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Wed Oct 17 22:18:32 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 17 Oct 2018 15:18:32 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> Message-ID: <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> On 10/17/18 2:38 PM, Mandy Chung wrote: > > > On 10/17/18 2:13 PM, dean.long at oracle.com wrote: >> On 10/17/18 1:41 PM, Mandy Chung wrote: >>> >>> >>> On 10/16/18 7:33 PM, David Holmes wrote: >>>> Hi Dean, >>>> >>>> Thanks for tackling this. >>>> >>>> I'm still struggling to fully grasp why we need both the >>>> PerfCounters and the regular counters. I get that we have to >>>> decrement the live counts before ensure_join() has allowed >>>> Thread.join() to return, to ensure that if we then check the number >>>> of threads it has dropped by one. But I don't understand why that >>>> means we need to manage the thread count in two parts. Particularly >>>> as now you don't use the PerfCounter to return the live count, so >>>> it makes me wonder what role the PerfCounter is playing as it is >>>> temporarily inconsistent with the reported live count? >>> >>> Perf counters were added long time back in JDK 1.4.2 for performance >>> measurement before java.lang.management API.? One can use jstat tool >>> to monitor VM perf counters of a running VM.?? One could look into >>> the possibility of deprecating these counters and remove them over time. >>> >>>> On 17/10/2018 9:43 AM, dean.long at oracle.com wrote: >>>> New webrev: >>>> >>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ >>> >>> When the perf counters are updated when a thread is added/removed, >>> it's holding Threads_lock.? Are the asserts in >>> ThreadService::remove_thread necessary? >>> >> >> Not really.? They were intended to catch the case where the atomic >> counters weren't decremented for some reason, not for the perf counters. >> Should I remove them? >> > > Hmm... when remove_thread is called but decrement_thread_counts has > not been called. ? It's a bug in thread accounting.? It happens to > have the perf counters that can be compared to assert. It seems not > obvious.? Setting the perf counters same values as > _atomic_threads_count and _atomic_daemon_threads_count makes sense to me. > > I would opt for removing the asserts but I can't think of an > alternative how to catch the issue you concern about. > >>> For clarify, I think we could simply set _live_threads_count to the >>> value of _atomic_threads_count and set _daemon_threads_count to the >>> value of _atomic_daemon_threads_count. >>> >> >> I think that works, even inside decrement_thread_counts() without >> holding the Threads_lock.? If you agree, I'll make that change. >> > +1 > New webrevs, full and incremental: http://cr.openjdk.java.net/~dlong/8021335/webrev.6/ http://cr.openjdk.java.net/~dlong/8021335/webrev.6.diff/ I like it better without all the asserts too. dl > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Oct 17 22:18:47 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 17 Oct 2018 15:18:47 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: <71A6706A-B1C5-46CD-927B-BE07538AB779@amazon.com> References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> <71A6706A-B1C5-46CD-927B-BE07538AB779@amazon.com> Message-ID: Hi Paul, Thanks for the review :) I've fixed the cases you saw to at least keep them consistent. However, I'm not too worried about these as my next set of webrevs is going to fix the spaces for all ( and ) in the vmTestbase so we will fix everything once and for all. The JDK bug I'm referring to is : https://bugs.openjdk.java.net/browse/JDK-8211335 I already have relatively the scripts to do it :-), Jc On Wed, Oct 17, 2018 at 1:01 PM Hohensee, Paul wrote: > Re spaces :). There?s a bunch of places where ?(jvmti_env? should be ?( > jvmti_env?, but of course not all of them. I found a bunch. Otherwise, > lgtm., no need for another webrev. > > > > Paul > > > > In hs104t002.cpp > > > > - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, > > - &caps) )) { > > + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > > > => > > > > + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > > > In hs203t003.cpp > > > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB4(GetClassSignature, > > - jvmti_env, klass, &className, &generic) ) ) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti_env->GetClassSignature(klass, &className, &generic) ) ) { > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GetClassSignature(klass, &className, &generic) ) ) { > > > > and > > > > - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) )) { > > + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > > > => > > > > + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > > > and > > > > - if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, thread, &state) ) ) { > > + if ( ! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state) ) ) { > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state) ) ) { > > > > and > > > > - if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, thread, &state) ) ) { > > + if ( ! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state) ) ) { > > nsk_printf(" Agent :: Error while getting thread state.\n"); > > nsk_jvmti_agentFailed(); > > } else { > > if ( state & JVMTI_THREAD_STATE_SUSPENDED) { > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2( PopFrame, jvmti, thread) ) ) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti->PopFrame(thread) ) ) { > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state) ) ) { > > ? > > + if ( ! NSK_JVMTI_VERIFY ( jvmti->PopFrame(thread) ) ) { > > > > and > > > > - if ( !NSK_JVMTI_VERIFY( NSK_CPP_STUB2 ( ResumeThread, jvmti, thread)) ) { > > + if ( !NSK_JVMTI_VERIFY(jvmti->ResumeThread(thread)) ) { > > > > => > > > > + if ( !NSK_JVMTI_VERIFY( jvmti->ResumeThread(thread)) ) { > > > > In hs203t004.cpp > > > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(GenerateEvents, jvmti_env, > > - JVMTI_EVENT_COMPILED_METHOD_LOAD ) )) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti_env->GenerateEvents(JVMTI_EVENT_COMPILED_METHOD_LOAD) )) { > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GenerateEvents(JVMTI_EVENT_COMPILED_METHOD_LOAD) )) { > > > > and > > > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB3(GetMethodDeclaringClass, > > - jvmti_env, method, &threadClass) ) ) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti_env->GetMethodDeclaringClass(method, &threadClass) ) ) { > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GetMethodDeclaringClass(method, &threadClass) ) ) { > > > > and > > > > - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) )) { > > + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > > > => > > > > + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > > > and > > > > - if ( NSK_JVMTI_VERIFY( NSK_CPP_STUB2(SuspendThread, jvmti, thread) ) ) { > > + if ( NSK_JVMTI_VERIFY(jvmti->SuspendThread(thread) ) ) { > > > > => > > > > + if ( NSK_JVMTI_VERIFY( jvmti->SuspendThread(thread) ) ) { > > > > and > > > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB3(GetThreadState, jvmti, > > - thread, &state) ) ) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti->GetThreadState(thread, &state) ) ) { > > NSK_COMPLAIN0("#error Agent :: while getting thread's state.\n"); > > nsk_jvmti_agentFailed(); > > } else { > > if ( state & JVMTI_THREAD_STATE_SUSPENDED) { > > - if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB2(PopFrame, jvmti, thread) ) ){ > > + if ( ! NSK_JVMTI_VERIFY(jvmti->PopFrame(thread) ) ){ > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY ( jvmti->GetThreadState(thread, &state) ) ) { > > ? > > + if ( ! NSK_JVMTI_VERIFY( jvmti->PopFrame(thread) ) ){ > > > > In hs204t001.cpp > > > > - /* if( (myTestClass =NSK_CPP_STUB2(NewGlobalRef,jni_env, klass)) == NULL) { > > + /* if( (myTestClass =jni_env->NewGlobalRef(klass)) == NULL) { > > > > => > > > > + /* if( (myTestClass = jni_env->NewGlobalRef(klass)) == NULL) { > > > > and > > > > - if (!NSK_JNI_VERIFY(env, (testClass =(jclass) NSK_CPP_STUB2(NewGlobalRef, env, klass)) != NULL)) > > + if (!NSK_JNI_VERIFY(env, (testClass =(jclass) env->NewGlobalRef(klass)) != NULL)) > > nsk_jvmti_setFailStatus(); > > - if (!NSK_JNI_VERIFY(env, (testedThread =NSK_CPP_STUB2(NewGlobalRef, env, thread)) != NULL)) > > + if (!NSK_JNI_VERIFY(env, (testedThread =env->NewGlobalRef(thread)) != NULL)) > > > > => > > > > + if (!NSK_JNI_VERIFY(env, (testClass = (jclass) env->NewGlobalRef(klass)) != NULL)) > > nsk_jvmti_setFailStatus(); > > ? > > + if (!NSK_JNI_VERIFY(env, (testedThread = env->NewGlobalRef(thread)) != NULL)) > > > > and > > > > - if (!NSK_JVMTI_VERIFY( NSK_CPP_STUB2(SuspendThread, jvmti, thread))) { > > + if (!NSK_JVMTI_VERIFY( jvmti->SuspendThread(thread))) { > > > > => > > > > + if (!NSK_JVMTI_VERIFY(jvmti->SuspendThread(thread))) { > > > > In hs204t003.cpp > > > > - if (! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, thread, &state)) ){ > > + if (! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state)) ){ > > NSK_DISPLAY0(" Agent :: Error getting thread state.\n"); > > nsk_jvmti_agentFailed(); > > } else { > > if ( state & JVMTI_THREAD_STATE_SUSPENDED) { > > NSK_DISPLAY0(" Agent :: Thread state = JVMTI_THREAD_STATE_SUSPENDED.\n"); > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(PopFrame, jvmti, thread) ) ) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti->PopFrame(thread) ) ) { > > NSK_DISPLAY0("#error Agent :: Jvmti failed to do popFrame.\n"); > > nsk_jvmti_agentFailed(); > > } else { > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(ResumeThread, jvmti, thread)) ) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti->ResumeThread(thread)) ) { > > > > => > > > > + if (! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state)) ){ > > ? > > + if ( ! NSK_JVMTI_VERIFY ( jvmti->PopFrame(thread) ) ) { > > ? > > + if ( ! NSK_JVMTI_VERIFY ( jvmti->ResumeThread(thread)) ) { > > > > In hs301t001.cpp > > > > - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) )) { > > + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > > > => > > > > + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > > > In hs301t002.cpp > > > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) ) ) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) ) ) { > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) ) ) { > > > > In hs301t003.cpp > > > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB4(GetClassSignature, > > - jvmti_env, klass, &className, &generic) ) ) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti_env->GetClassSignature(klass, &className, &generic) ) ) { > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GetClassSignature(klass, &className, &generic) ) ) { > > > > and > > > > - if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, &caps) )) { > > + if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > > > => > > > > + if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > > > and > > > > - if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, > > - jvmti, &caps) )) { > > + if ( ! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > > > => > > > > + if ( ! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Tuesday, October 16, 2018 at 4:24 PM > *To: *"alexey.menkov at oracle.com" > *Cc: *"serviceability-dev at openjdk.java.net" < > serviceability-dev at openjdk.java.net> > *Subject: *Re: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from > vmTestbase for jvmti/scenarios/[E-M] > > > > Hi all, > > > > How about on a Tuesday? :) > > > > Sneak peak and motivational sentence: after this goes in, we have this one > which removes > the NSK_CPP_STUBs from the tests entirely! :) > > Jc > > > > > > On Fri, Oct 12, 2018 at 5:37 PM JC Beyler wrote: > > Hi all, > > > > Any chance for a second reviewer on a Friday? :) > > Jc > > > > On Thu, Oct 11, 2018 at 11:03 AM Alex Menkov > wrote: > > got it. > > LGTM. > > --alex > > On 10/10/2018 19:03, JC Beyler wrote: > > Hi Alex, > > > > Thanks for the review! Yes I had seen that too before sending this > > review out and forked that fix into this: > > https://bugs.openjdk.java.net/browse/JDK-8211905 > > > > Which now is merged and I've updated my webrev to reflect this of course. > > > > My rationale for not doing it here directly is always the same: keeping > > the changes to the "spirit" of what the change is trying to do. Those > > extra casts were a bit out-of-scope and so I just forked the fix in > 8211905. > > > > Thanks! > > Jc > > > > On Wed, Oct 10, 2018 at 5:40 PM Alex Menkov > > wrote: > > > > Hi Jc, > > > > Overall looks good. > > > > one minor note: > > > > > test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: > > - jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > > (jstring) (jstring) (jstring) (jstring) > NSK_CPP_STUB3(CallObjectMethod, > > jni_env, klass, > > - methodID); > > + jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) > > (jstring) (jstring) (jstring) (jstring) > > jni_env->CallObjectMethod(klass, > > methodID); > > > > Please drop multi "(jstring)" > > > > --alex > > > > On 10/08/2018 21:21, JC Beyler wrote: > > > Hi all, > > > > > > I am continuing the NSK_CPP_STUB removal with this next webrev. > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 > > > > > > The change is still straight-forward though, since it is just > > doing the > > > same NSK_CPP_STUB removal. However when I was looking at the > > changes, a > > > lot of these changes are touching lines with spaces before/after > > > parenthesis. I've almost never touched the spaces except if I was > > > refactoring by hand the line at the same time. The rationale > > being that > > > the lines will get fixed a few more times and are, at worse, > > covered by > > > the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which > > I've > > > commited to doing. > > > > > > Two exceptions are here where I pushed out the code into > > assignments due > > > to really long lines and complex if structures: > > > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp.udiff.html > > > > > - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp.udiff.html > > > > > > > > And one exception here where a commented line was doing the > > out-of-if > > > assignment so I just uncommented it and used the variable: > > > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/8211899/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp.udiff.html > > > > > > > > I've tested the modified changes on my machine, all modified > > tests pass. > > > > > > Let me know what you think, > > > Jc > > > > > > Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* > > > > > > > > > > > -- > > > > Thanks, > > Jc > > > > > -- > > > > Thanks, > > Jc > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Oct 17 22:31:50 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 17 Oct 2018 15:31:50 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> Message-ID: <2c4b4671-492a-8293-e925-59b88bc22173@oracle.com> Hi Daniil, Chris, As far as I understand, the fix does not completely fixes all "non-atomic" output issues (at least TTY.executeCommand still prints prompt separately), so I agree that handle it as separate issue would be better. Unfortunately I don't know Gary's ideas for the issue. About the fix for print prompt: 1) TTY.java: + // Print current location if suspend policy is SUSPEND_NONE I suppose you mean "Print breakpoint location" 2) Does it make sense to use printCurrentLocation for SUSPEND_EVENT_THREAD? Is it expected to print something different from printBreakpointLocation? 3) I don't quite understand why we don't print simple prompt for SUSPEND_NONE. IIUC jdb can accept new command in both SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb waits for next command, right?) 4) JdbStopThreadTest.java New line line in Java regexp is "\\R" --alex On 10/17/2018 10:47, Chris Plummer wrote: > Hi Alex, > > I think the tty buffering should be a separate bug fix, and I'd also > like input from Gary on it since he had tried something similar at one > point. It should probably also include a multithread test to prove the > fix is working (after first getting the test to fail without the changes). > > thanks, > > Chris > > On 10/16/18 8:59 PM, Daniil Titov wrote: >> Hi Alex, Chris and JC, >> >> Please review an updated version of the patch that addresses these >> issues. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Thanks! >> --Daniil >> >> >> ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: >> >> ???? Hi Daniil, >> ???? 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL >> ???? 2) wrong indent in JdbStopThreadTest.java: >> ??????? 36???????? import lib.jdb.JdbCommand; >> ??????? 37???????? import lib.jdb.JdbTest; >> ???? 3) I think it would be better to make waitForSimplePrompt >> property of >> ???? JdbCommand (like JdbCommand.allowExit) >> ???? jdb.command(JdbCommand.run().replyIsSimplePrompt()); >> ???? looks much clearer than >> ???? jdb.command(JdbCommand.run(), true); >> ???? 4) (TTY.java) >> ???????? MessageOutput.lnprint("Breakpoint hit:"); >> ???? +? // Print current location and prompt if suspend policy is >> ???? SUSPEND_EVENT_THREAD. >> ???? +? // In case of SUSPEND_ALL policy this is handled by >> vmInterrupted() >> ???? method. >> ???? +? if (be.request().suspendPolicy() == >> EventRequest.SUSPEND_EVENT_THREAD) { >> ???? +????? printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); >> ???? +????? MessageOutput.printPrompt(); >> ???? +? } >> ???? We have 3 separate outputs. >> ???? If we have several concurrent threads, we can easy get mess of >> outputs >> ???? from different threads. >> ???? I think it would be better to print everything in a single chunk. >> ???? I suppose TTY has other places with similar "non-atomic" output, so >> ???? maybe revising TTY output should be handled by separate issue. >> ???? --alex >> ???? On 10/11/2018 22:00, Chris Plummer wrote: >> ???? > Hi Daniil, >> ???? > >> ???? > Can you send output from an example jdb session? >> ???? > >> ???? > Do you think maybe we should also call printCurrentLocation() >> when the >> ???? > suspend policy is NONE? >> ???? > >> ???? > There's a typo in the following line. The space is on the wrong >> side of >> ???? > the comma. >> ???? > >> ???? >??? 72 >> jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS ,bpLine)); >> ???? > >> ???? > thanks, >> ???? > >> ???? > Chris >> ???? > >> ???? > On 10/11/18 8:02 PM, Daniil Titov wrote: >> ???? >> >> ???? >> Thank you,? JC! >> ???? >> >> ???? >> Please review an updated version of the patch that fixes newly >> added >> ???? >> test for Windows platform? (now it uses system dependent line >> ???? >> separator string). >> ???? >> >> ???? >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >> ???? >> >> ???? >> >> ???? >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> ???? >> >> ???? >> Best regards, >> ???? >> >> ???? >> --Daniil >> ???? >> >> ???? >> *From: *JC Beyler >> ???? >> *Date: *Thursday, October 11, 2018 at 7:17 PM >> ???? >> *To: * >> ???? >> *Cc: * >> ???? >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when >> breakpoint >> ???? >> is hit and suspend policy is STOP_EVENT_THREAD >> ???? >> >> ???? >> Hi Daniil, >> ???? >> >> ???? >> Looks good to me. I saw a really small nit: >> ???? >> >> ???? >> >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >> >> ???? >> >> >> >> ???? >> >> ???? >> 70? jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS >> ,bpLine)); >> ???? >> >> ???? >> There is a space after the '('. >> ???? >> >> ???? >> No need to send a new webrev for that evidently :), >> ???? >> >> ???? >> Jc >> ???? >> >> ???? >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >> ???? >> > >> wrote: >> ???? >> >> ???? >>???? Please review the change that fixes the issue with missing >> prompt >> ???? >>???? in jdb when a breakpoint is hit and the suspend policy is >> set to >> ???? >>???? stop the thread only. >> ???? >> >> ???? >>???? Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >> ???? >>???? >> ???? >>???? Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> ???? >> >> ???? >>???? Thanks! >> ???? >>???? --Daniil >> ???? >> >> ???? >> >> ???? >> >> ???? >> -- >> ???? >> >> ???? >> Thanks, >> ???? >> >> ???? >> Jc >> ???? >> >> ???? > >> >> > > From alexey.menkov at oracle.com Wed Oct 17 22:35:31 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 17 Oct 2018 15:35:31 -0700 Subject: Restoring nsk/jvmti/scenarios/hotswap tests from ProblemList.txt In-Reply-To: <62d1bc9e-400a-70bf-b4c2-05266b66b575@oracle.com> References: <5BC720C5.4060907@oracle.com> <62d1bc9e-400a-70bf-b4c2-05266b66b575@oracle.com> Message-ID: <45699b21-08c1-6d0b-4a08-ba69cd696c92@oracle.com> +1 --alex On 10/17/2018 11:10, Chris Plummer wrote: > The changes look fine. > > thanks, > > Chris > > On 10/17/18 4:45 AM, Gary Adams wrote: >> While investigating other issues with hotswap tests I noticed >> 2 tests on the Problemlist that I think can be restored. >> >> I have not been able to reproduce the failure with hs102t002 >> It is marked in the ProblemList as related to JDK-8203350, >> but that bug is about hs201t002. It is also marked as related >> to JDK-8204506, which is concerned with test hs102t002, but >> is specific to a graal failure and is already recorded in >> ProblemList-graal.txt >> >> ? https://bugs.openjdk.java.net/browse/JDK-8203350 >> ? https://bugs.openjdk.java.net/browse/JDK-8204506 >> >> I did run into some intermittent failures with hs204t001 and the >> utility class ExecDriver. It appears that it took advantage of other >> tests >> building the class file. A simple directive to build ExecDirver will >> bring it >> in line with the other hotswap tests. >> >> diff --git a/test/hotspot/jtreg/ProblemList.txt >> b/test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -184,8 +184,6 @@ >> ?vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted004/TestDescription.java >> 7013634,6606767 generic-all >> ?vmTestbase/nsk/jvmti/ThreadStart/threadstart001/TestDescription.java >> 8016181 generic-all >> ?vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/TestDescription.java >> 8173658 generic-all >> -vmTestbase/nsk/jvmti/scenarios/hotswap/HS102/hs102t002/TestDescription.java >> 8204506,8203350 generic-all >> -vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java >> 6813266 generic-all >> ?vmTestbase/nsk/jvmti/scenarios/sampling/SP06/sp06t003/TestDescription.java >> 8051349 generic-all >> ?vmTestbase/nsk/jvmti/AttachOnDemand/attach034/TestDescription.java >> 8042145 generic-all >> ?vmTestbase/nsk/jvmti/AttachOnDemand/attach045/TestDescription.java >> 8202971 generic-all >> >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java >> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java >> >> --- >> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java >> >> +++ >> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS204/hs204t001/hs204t001.java >> >> @@ -46,7 +46,8 @@ >> ? * @library /vmTestbase >> ? *????????? /test/lib >> ? * @run driver jdk.test.lib.FileInstaller . . >> - * @build nsk.jvmti.scenarios.hotswap.HS204.hs204t001.hs204t001 >> + * @build ExecDriver >> + *????? nsk.jvmti.scenarios.hotswap.HS204.hs204t001.hs204t001 >> ? * >> ? * @comment compile newclassXX to bin/newclassXX >> ? * @run driver nsk.share.ExtraClassesBuilder >> > > From serguei.spitsyn at oracle.com Wed Oct 17 22:45:58 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Oct 2018 15:45:58 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> Message-ID: Hi Jc, ++LGTM. Sorry for being late. This takes a lot of efforts - thank you so much for being so patient! Thanks, Serguei On 10/11/18 11:03, Alex Menkov wrote: > got it. > > LGTM. > > --alex > > On 10/10/2018 19:03, JC Beyler wrote: >> Hi Alex, >> >> Thanks for the review! Yes I had seen that too before sending this >> review out and forked that fix into this: >> https://bugs.openjdk.java.net/browse/JDK-8211905 >> >> Which now is merged and I've updated my webrev to reflect this of >> course. >> >> My rationale for not doing it here directly is always the same: >> keeping the changes to the "spirit" of what the change is trying to >> do. Those extra casts were a bit out-of-scope and so I just forked >> the fix in 8211905. >> >> Thanks! >> Jc >> >> On Wed, Oct 10, 2018 at 5:40 PM Alex Menkov > > wrote: >> >> ??? Hi Jc, >> >> ??? Overall looks good. >> >> ??? one minor note: >> >> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: >> ??? -? ? jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) >> ??? (jstring) (jstring) (jstring) (jstring) >> NSK_CPP_STUB3(CallObjectMethod, >> ??? jni_env, klass, >> ??? -? ? ? ? ? ? ? ? ? ? ? ? methodID); >> ??? +? ? jclassName = (jstring) (jstring) (jstring) (jstring) (jstring) >> ??? (jstring) (jstring) (jstring) (jstring) >> ??? jni_env->CallObjectMethod(klass, >> ??? methodID); >> >> ??? Please drop multi "(jstring)" >> >> ??? --alex >> >> ??? On 10/08/2018 21:21, JC Beyler wrote: >> ???? > Hi all, >> ???? > >> ???? > I am continuing the NSK_CPP_STUB removal with this next webrev. >> ???? > Webrev: http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ >> >> ???? > >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 >> ???? > >> ???? > The change is still straight-forward though, since it is just >> ??? doing the >> ???? > same NSK_CPP_STUB removal. However when I was looking at the >> ??? changes, a >> ???? > lot of these changes are touching lines with spaces before/after >> ???? > parenthesis. I've almost never touched the spaces except if I was >> ???? > refactoring by hand the line at the same time. The rationale >> ??? being that >> ???? > the lines will get fixed a few more times and are, at worse, >> ??? covered by >> ???? > the bug: https://bugs.openjdk.java.net/browse/JDK-8211335, which >> ??? I've >> ???? > commited to doing. >> ???? > >> ???? > Two exceptions are here where I pushed out the code into >> ??? assignments due >> ???? > to really long lines and complex if structures: >> ???? > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp >> ???? > >> >> ???? > - jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp >> ???? > >> >> ???? > >> ???? > And one exception here where a commented line was doing the >> ??? out-of-if >> ???? > assignment so I just uncommented it and used the variable: >> ???? > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp >> ???? > >> >> ???? > >> ???? > I've tested the modified changes on my machine, all modified >> ??? tests pass. >> ???? > >> ???? > Let me know what you think, >> ???? > Jc >> ???? > >> ???? > Ps: 2 more of these and we can say good bye to NSK_CPP_STUB* >> ???? > >> >> >> >> -- >> >> Thanks, >> Jc From alexey.menkov at oracle.com Wed Oct 17 22:46:40 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 17 Oct 2018 15:46:40 -0700 Subject: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java In-Reply-To: <5BC7674F.5070501@oracle.com> References: <5BC7674F.5070501@oracle.com> Message-ID: Hi Gary, - RedefineCrossEvent.java: you can drop "@modules jdk.jdi" as well. jdk.jdi is added to all test in the dir (it's specified in test/jdk/com/sun/jdi/TEST.properties) about InstanceFilter test - it's strange that RedefineCrossEvent fails while InstanceFilter does not. Maybe it's caused by different compiler options? InstanceFilter.java contains: @run compile -g InstanceFilter.java and RedefineCrossEvent.java has: @run build InstanceFilter Note that all other classes in RedefineCrossEvent are compiled with "-g" option. --alex On 10/17/2018 09:46, Gary Adams wrote: > The RedefineCrossEvent test has been on been on the ProblemList for a > very long time. > In the past this test had some dependency on the Java EE modules, but > they? were > deprecated for jdk9 and later removed completely in jdk11. This > changeset to restore > it, removes the corba module reference and blocks the redefine operations > for jdk.internal classes that presented an issue when the > RedefineCrossEvent > test launches the InstanceFilter test. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8206330 > ? Webrev: http://cr.openjdk.java.net/~gadams/8206330/webrev/index.html From chris.plummer at oracle.com Wed Oct 17 22:51:03 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Oct 2018 15:51:03 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> Message-ID: <9e66885a-55ff-6da5-e739-cd78f9aaa036@oracle.com> Sorry, I meant to address Daniil, not Alex. Sorry about any confusion. Chris On 10/17/18 10:47 AM, Chris Plummer wrote: > Hi Alex, > > I think the tty buffering should be a separate bug fix, and I'd also > like input from Gary on it since he had tried something similar at one > point. It should probably also include a multithread test to prove the > fix is working (after first getting the test to fail without the > changes). > > thanks, > > Chris > > On 10/16/18 8:59 PM, Daniil Titov wrote: >> Hi Alex, Chris and JC, >> >> Please review an updated version of the patch that addresses these >> issues. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Thanks! >> --Daniil >> >> >> ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: >> >> ???? Hi Daniil, >> ???? ???? 1) +1 for printCurrentLocation when suspendPolicy != >> SUSPEND_ALL >> ???? ???? 2) wrong indent in JdbStopThreadTest.java: >> ??????? 36???????? import lib.jdb.JdbCommand; >> ??????? 37???????? import lib.jdb.JdbTest; >> ???? ???? 3) I think it would be better to make waitForSimplePrompt >> property of >> ???? JdbCommand (like JdbCommand.allowExit) >> ???? ???? jdb.command(JdbCommand.run().replyIsSimplePrompt()); >> ???? looks much clearer than >> ???? jdb.command(JdbCommand.run(), true); >> ???? ???? 4) (TTY.java) >> ???????? MessageOutput.lnprint("Breakpoint hit:"); >> ???? +? // Print current location and prompt if suspend policy is >> ???? SUSPEND_EVENT_THREAD. >> ???? +? // In case of SUSPEND_ALL policy this is handled by >> vmInterrupted() >> ???? method. >> ???? +? if (be.request().suspendPolicy() == >> EventRequest.SUSPEND_EVENT_THREAD) { >> ???? + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); >> ???? +????? MessageOutput.printPrompt(); >> ???? +? } >> ???? We have 3 separate outputs. >> ???? If we have several concurrent threads, we can easy get mess of >> outputs >> ???? from different threads. >> ???? I think it would be better to print everything in a single chunk. >> ???? I suppose TTY has other places with similar "non-atomic" output, so >> ???? maybe revising TTY output should be handled by separate issue. >> ???? ???? --alex >> ???? ???? On 10/11/2018 22:00, Chris Plummer wrote: >> ???? > Hi Daniil, >> ???? > >> ???? > Can you send output from an example jdb session? >> ???? > >> ???? > Do you think maybe we should also call printCurrentLocation() >> when the >> ???? > suspend policy is NONE? >> ???? > >> ???? > There's a typo in the following line. The space is on the >> wrong side of >> ???? > the comma. >> ???? > >> ???? >??? 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS >> ,bpLine)); >> ???? > >> ???? > thanks, >> ???? > >> ???? > Chris >> ???? > >> ???? > On 10/11/18 8:02 PM, Daniil Titov wrote: >> ???? >> >> ???? >> Thank you,? JC! >> ???? >> >> ???? >> Please review an updated version of the patch that fixes >> newly added >> ???? >> test for Windows platform? (now it uses system dependent line >> ???? >> separator string). >> ???? >> >> ???? >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >> ???? >> >> ???? >> >> ???? >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> ???? >> >> ???? >> Best regards, >> ???? >> >> ???? >> --Daniil >> ???? >> >> ???? >> *From: *JC Beyler >> ???? >> *Date: *Thursday, October 11, 2018 at 7:17 PM >> ???? >> *To: * >> ???? >> *Cc: * >> ???? >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when >> breakpoint >> ???? >> is hit and suspend policy is STOP_EVENT_THREAD >> ???? >> >> ???? >> Hi Daniil, >> ???? >> >> ???? >> Looks good to me. I saw a really small nit: >> ???? >> >> ???? >> >> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >> ???? >> >> >> ???? >> >> ???? >> 70? jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS >> ,bpLine)); >> ???? >> >> ???? >> There is a space after the '('. >> ???? >> >> ???? >> No need to send a new webrev for that evidently :), >> ???? >> >> ???? >> Jc >> ???? >> >> ???? >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >> ???? >> > > wrote: >> ???? >> >> ???? >>???? Please review the change that fixes the issue with >> missing prompt >> ???? >>???? in jdb when a breakpoint is hit and the suspend policy is >> set to >> ???? >>???? stop the thread only. >> ???? >> >> ???? >>???? Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >> ???? >> >> ???? >>???? Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> ???? >> >> ???? >>???? Thanks! >> ???? >>???? --Daniil >> ???? >> >> ???? >> >> ???? >> >> ???? >> -- >> ???? >> >> ???? >> Thanks, >> ???? >> >> ???? >> Jc >> ???? >> >> ???? > >> >> > > From chris.plummer at oracle.com Wed Oct 17 22:52:53 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 17 Oct 2018 15:52:53 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <2c4b4671-492a-8293-e925-59b88bc22173@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> <2c4b4671-492a-8293-e925-59b88bc22173@oracle.com> Message-ID: What is the jdb state for a breakpoint with SUSPEND_NONE? Can you actually type in commands even though no threads are suspended? Chris On 10/17/18 3:31 PM, Alex Menkov wrote: > Hi Daniil, Chris, > > As far as I understand, the fix does not completely fixes all > "non-atomic" output issues (at least TTY.executeCommand still prints > prompt separately), so I agree that handle it as separate issue would > be better. > Unfortunately I don't know Gary's ideas for the issue. > > About the fix for print prompt: > 1) TTY.java: > +??????????? // Print current location if suspend policy is SUSPEND_NONE > I suppose you mean "Print breakpoint location" > > 2) Does it make sense to use printCurrentLocation for > SUSPEND_EVENT_THREAD? > Is it expected to print something different from printBreakpointLocation? > > 3) I don't quite understand why we don't print simple prompt for > SUSPEND_NONE. IIUC jdb can accept new command in both > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb > waits for next command, right?) > > 4) JdbStopThreadTest.java > New line line in Java regexp is "\\R" > > --alex > > On 10/17/2018 10:47, Chris Plummer wrote: >> Hi Alex, >> >> I think the tty buffering should be a separate bug fix, and I'd also >> like input from Gary on it since he had tried something similar at >> one point. It should probably also include a multithread test to >> prove the fix is working (after first getting the test to fail >> without the changes). >> >> thanks, >> >> Chris >> >> On 10/16/18 8:59 PM, Daniil Titov wrote: >>> Hi Alex, Chris and JC, >>> >>> Please review an updated version of the patch that addresses these >>> issues. >>> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ >>> Issue:? https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >>> Thanks! >>> --Daniil >>> >>> >>> ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: >>> >>> ???? Hi Daniil, >>> ???? 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL >>> ???? 2) wrong indent in JdbStopThreadTest.java: >>> ??????? 36???????? import lib.jdb.JdbCommand; >>> ??????? 37???????? import lib.jdb.JdbTest; >>> ???? 3) I think it would be better to make waitForSimplePrompt >>> property of >>> ???? JdbCommand (like JdbCommand.allowExit) >>> ???? jdb.command(JdbCommand.run().replyIsSimplePrompt()); >>> ???? looks much clearer than >>> ???? jdb.command(JdbCommand.run(), true); >>> ???? 4) (TTY.java) >>> ???????? MessageOutput.lnprint("Breakpoint hit:"); >>> ???? +? // Print current location and prompt if suspend policy is >>> ???? SUSPEND_EVENT_THREAD. >>> ???? +? // In case of SUSPEND_ALL policy this is handled by >>> vmInterrupted() >>> ???? method. >>> ???? +? if (be.request().suspendPolicy() == >>> EventRequest.SUSPEND_EVENT_THREAD) { >>> ???? + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); >>> ???? +????? MessageOutput.printPrompt(); >>> ???? +? } >>> ???? We have 3 separate outputs. >>> ???? If we have several concurrent threads, we can easy get mess of >>> outputs >>> ???? from different threads. >>> ???? I think it would be better to print everything in a single chunk. >>> ???? I suppose TTY has other places with similar "non-atomic" >>> output, so >>> ???? maybe revising TTY output should be handled by separate issue. >>> ???? --alex >>> ???? On 10/11/2018 22:00, Chris Plummer wrote: >>> ???? > Hi Daniil, >>> ???? > >>> ???? > Can you send output from an example jdb session? >>> ???? > >>> ???? > Do you think maybe we should also call printCurrentLocation() >>> when the >>> ???? > suspend policy is NONE? >>> ???? > >>> ???? > There's a typo in the following line. The space is on the >>> wrong side of >>> ???? > the comma. >>> ???? > >>> ???? >??? 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS >>> ,bpLine)); >>> ???? > >>> ???? > thanks, >>> ???? > >>> ???? > Chris >>> ???? > >>> ???? > On 10/11/18 8:02 PM, Daniil Titov wrote: >>> ???? >> >>> ???? >> Thank you,? JC! >>> ???? >> >>> ???? >> Please review an updated version of the patch that fixes >>> newly added >>> ???? >> test for Windows platform? (now it uses system dependent line >>> ???? >> separator string). >>> ???? >> >>> ???? >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >>> ???? >> >>> ???? >> >>> ???? >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> ???? >> >>> ???? >> Best regards, >>> ???? >> >>> ???? >> --Daniil >>> ???? >> >>> ???? >> *From: *JC Beyler >>> ???? >> *Date: *Thursday, October 11, 2018 at 7:17 PM >>> ???? >> *To: * >>> ???? >> *Cc: * >>> ???? >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when >>> breakpoint >>> ???? >> is hit and suspend policy is STOP_EVENT_THREAD >>> ???? >> >>> ???? >> Hi Daniil, >>> ???? >> >>> ???? >> Looks good to me. I saw a really small nit: >>> ???? >> >>> ???? >> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >>> >>> ???? >> >>> >>> >>> ???? >> >>> ???? >> 70? jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS >>> ,bpLine)); >>> ???? >> >>> ???? >> There is a space after the '('. >>> ???? >> >>> ???? >> No need to send a new webrev for that evidently :), >>> ???? >> >>> ???? >> Jc >>> ???? >> >>> ???? >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >>> ???? >> >> > wrote: >>> ???? >> >>> ???? >>???? Please review the change that fixes the issue with >>> missing prompt >>> ???? >>???? in jdb when a breakpoint is hit and the suspend policy >>> is set to >>> ???? >>???? stop the thread only. >>> ???? >> >>> ???? >>???? Webrev: >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >>> ???? >> >>> ???? >>???? Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> ???? >> >>> ???? >>???? Thanks! >>> ???? >>???? --Daniil >>> ???? >> >>> ???? >> >>> ???? >> >>> ???? >> -- >>> ???? >> >>> ???? >> Thanks, >>> ???? >> >>> ???? >> Jc >>> ???? >> >>> ???? > >>> >>> >> >> From serguei.spitsyn at oracle.com Wed Oct 17 23:00:23 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Oct 2018 16:00:23 -0700 Subject: RFR (S): 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: References: Message-ID: <4d04cd45-5cc2-0978-fdb4-2f405156c3ef@oracle.com> Hi David, Sorry for being late but just wanted to tell you that it looks good to me. Thank you for catching and taking care about it! Thanks, Serguei On 10/14/18 22:12, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8211909 > webrev: http://cr.openjdk.java.net/~dholmes/8211909/webrev/ > > The crash occurs when trying to access a thread that was returned as > part of JVM TI GetThreadGroupChildren. The problem is that the JVM TI > code tries to use the Threads_lock to ensure atomic access to the > ThreadGroup's threads and child groups: > > ??? { // Cannot allow thread or group counts to change. > ????? MutexLocker mu(Threads_lock); > > but the Threads_lock does not control concurrency in the Java code > that can cause threads to be added and removed, so we do not get a > stable snapshot of the thread array and its length, and contents. To > get a stable snapshot we have to use the same synchronization > mechanism as used by the Java code: lock the monitor of the > ThreadGroup instance. > > Two other pointless acquisitions of the Threads_lock, in GetThreadInfo > and GetThreadGroupInfo, were also removed. These functions could > report an inconsistent snapshot of the Thread or ThreadGroup state, if > the mutable state is mutated concurrently. Again we could acquire the > object's monitor to prevent this but it is unclear that there is any > real benefit in doing so - after all the thread/group information > could change immediately after it has been read anyway. So here I just > delete the Threads_lock usage. > > Testing: mach5 tier 1-3 > ???????? JVM TI tests (serviceability/jvmti vmTestbase/nsk/jvmti/) > > A regression test may be possible if we call GetThreadGroupChildren in > a loop, whilst threads add and remove themselves from the group > concurrently. But it is awkward to write. > > Thanks, > David > > Thanks, > David From serguei.spitsyn at oracle.com Wed Oct 17 23:26:52 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 17 Oct 2018 16:26:52 -0700 Subject: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java In-Reply-To: References: <5BC7674F.5070501@oracle.com> <9cb267ea-ad1f-2728-a616-34cc52b08859@oracle.com> Message-ID: <20212085-0d36-ee53-5fb0-4f2d5e5bf64f@oracle.com> Hi Gary, With the suggest tweaks below the fix looks good to me (modulo suggestions from Alex in the following message). I'm Okay with any approach related to the problem list. It looks wrong to keep the test problem listed with the same bug id. If we want to keep it then the bug id needs to be replaced with 8180804. Thanks, Serguei On 10/17/18 12:58, Chris Plummer wrote: > On 10/17/18 12:40 PM, gary.adams at oracle.com wrote: >> On 10/17/18 2:04 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> Can this be on one line now: >>> >>> ? 30? * @modules >>> ? 31? *????????? jdk.jdi >> OK >>> >>> What are you blocking all jdk.* classes from redef when you pointed >>> out that only jdk.internal.* is an issue? >> The file I'm modifying already has some blocking checks that look >> for java., com, and sun., so it seemed appropriate that the jdk. prefix >> was appropriate for this check. > Ok. >>> >>> Is this also addressing JDK-8180804? If not, should it stay on the >>> problem list until JDK-8180804 is fixed? >> I'll run through the usual testing to see if I can force the timeout. >> Since the test has been on the ProblemList for a year and half >> it is hard to know if this is an intermittent failure or not. >> >> If I can't reproduce the failure, then I'd like to go ahead with this >> change and see if it shows up again. >> > Ok. >> The original reason the test was placed on the ProblemList >> was because of the removal of java ee modules, not because of the >> timeout that was observed. > Yes, I realize that. But if the timeout is also somewhat new, it could > be problematic enough to warrant keeping it on the problem list. > > thanks, > > Chris >>> >>> thanks, >>> >>> Chris >>> >>> On 10/17/18 9:46 AM, Gary Adams wrote: >>>> The RedefineCrossEvent test has been on been on the ProblemList for >>>> a very long time. >>>> In the past this test had some dependency on the Java EE modules, >>>> but they? were >>>> deprecated for jdk9 and later removed completely in jdk11. This >>>> changeset to restore >>>> it, removes the corba module reference and blocks the redefine >>>> operations >>>> for jdk.internal classes that presented an issue when the >>>> RedefineCrossEvent >>>> test launches the InstanceFilter test. >>>> >>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8206330 >>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8206330/webrev/index.html >>> >>> >>> >> > > From daniil.x.titov at oracle.com Wed Oct 17 23:44:40 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Oct 2018 16:44:40 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> <2c4b4671-492a-8293-e925-59b88bc22173@oracle.com> Message-ID: <817D3409-3916-4530-B26E-9C2BEEFB6C74@oracle.com> ?On 10/17/18, 3:52 PM, "Chris Plummer" wrote: What is the jdb state for a breakpoint with SUSPEND_NONE? Can you actually type in commands even though no threads are suspended? Chris On 10/17/18 3:31 PM, Alex Menkov wrote: > Hi Daniil, Chris, > > As far as I understand, the fix does not completely fixes all > "non-atomic" output issues (at least TTY.executeCommand still prints > prompt separately), so I agree that handle it as separate issue would > be better. > Unfortunately I don't know Gary's ideas for the issue. > > About the fix for print prompt: > 1) TTY.java: > + // Print current location if suspend policy is SUSPEND_NONE > I suppose you mean "Print breakpoint location" > > 2) Does it make sense to use printCurrentLocation for > SUSPEND_EVENT_THREAD? > Is it expected to print something different from printBreakpointLocation? > > 3) I don't quite understand why we don't print simple prompt for > SUSPEND_NONE. IIUC jdb can accept new command in both > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb > waits for next command, right?) > > 4) JdbStopThreadTest.java > New line line in Java regexp is "\\R" > > --alex > > On 10/17/2018 10:47, Chris Plummer wrote: >> Hi Alex, >> >> I think the tty buffering should be a separate bug fix, and I'd also >> like input from Gary on it since he had tried something similar at >> one point. It should probably also include a multithread test to >> prove the fix is working (after first getting the test to fail >> without the changes). >> >> thanks, >> >> Chris >> >> On 10/16/18 8:59 PM, Daniil Titov wrote: >>> Hi Alex, Chris and JC, >>> >>> Please review an updated version of the patch that addresses these >>> issues. >>> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >>> Thanks! >>> --Daniil >>> >>> >>> ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: >>> >>> Hi Daniil, >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL >>> 2) wrong indent in JdbStopThreadTest.java: >>> 36 import lib.jdb.JdbCommand; >>> 37 import lib.jdb.JdbTest; >>> 3) I think it would be better to make waitForSimplePrompt >>> property of >>> JdbCommand (like JdbCommand.allowExit) >>> jdb.command(JdbCommand.run().replyIsSimplePrompt()); >>> looks much clearer than >>> jdb.command(JdbCommand.run(), true); >>> 4) (TTY.java) >>> MessageOutput.lnprint("Breakpoint hit:"); >>> + // Print current location and prompt if suspend policy is >>> SUSPEND_EVENT_THREAD. >>> + // In case of SUSPEND_ALL policy this is handled by >>> vmInterrupted() >>> method. >>> + if (be.request().suspendPolicy() == >>> EventRequest.SUSPEND_EVENT_THREAD) { >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); >>> + MessageOutput.printPrompt(); >>> + } >>> We have 3 separate outputs. >>> If we have several concurrent threads, we can easy get mess of >>> outputs >>> from different threads. >>> I think it would be better to print everything in a single chunk. >>> I suppose TTY has other places with similar "non-atomic" >>> output, so >>> maybe revising TTY output should be handled by separate issue. >>> --alex >>> On 10/11/2018 22:00, Chris Plummer wrote: >>> > Hi Daniil, >>> > >>> > Can you send output from an example jdb session? >>> > >>> > Do you think maybe we should also call printCurrentLocation() >>> when the >>> > suspend policy is NONE? >>> > >>> > There's a typo in the following line. The space is on the >>> wrong side of >>> > the comma. >>> > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS >>> ,bpLine)); >>> > >>> > thanks, >>> > >>> > Chris >>> > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote: >>> >> >>> >> Thank you, JC! >>> >> >>> >> Please review an updated version of the patch that fixes >>> newly added >>> >> test for Windows platform (now it uses system dependent line >>> >> separator string). >>> >> >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >>> >> >>> >> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >> >>> >> Best regards, >>> >> >>> >> --Daniil >>> >> >>> >> *From: *JC Beyler >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM >>> >> *To: * >>> >> *Cc: * >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when >>> breakpoint >>> >> is hit and suspend policy is STOP_EVENT_THREAD >>> >> >>> >> Hi Daniil, >>> >> >>> >> Looks good to me. I saw a really small nit: >>> >> >>> >> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >>> >>> >> >>> >>> >>> >> >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS >>> ,bpLine)); >>> >> >>> >> There is a space after the '('. >>> >> >>> >> No need to send a new webrev for that evidently :), >>> >> >>> >> Jc >>> >> >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >>> >> >> > wrote: >>> >> >>> >> Please review the change that fixes the issue with >>> missing prompt >>> >> in jdb when a breakpoint is hit and the suspend policy >>> is set to >>> >> stop the thread only. >>> >> >>> >> Webrev: >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >>> >> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >> >>> >> Thanks! >>> >> --Daniil >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Thanks, >>> >> >>> >> Jc >>> >> >>> > >>> >>> >> >> From daniil.x.titov at oracle.com Thu Oct 18 00:06:06 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Oct 2018 17:06:06 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> <2c4b4671-492a-8293-e925-59b88bc22173@oracle.com> Message-ID: Hi Chris, The previous email was accidentally fired before I managed to type anything in. Sorry for confusion. Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed. cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java 786 // Process interactive commands. 787 MessageOutput.printPrompt(); 788 while (true) { 789 String ln = in.readLine(); 790 if (ln == null) { 791 /* 792 * Jdb is being shutdown because debuggee exited, ignore any 'null' 793 * returned by readLine() during shutdown. JDK-8154144. 794 */ 795 if (!isShuttingDown()) { 796 MessageOutput.println("Input stream closed."); 797 } 798 ln = "quit"; 799 } 800 801 if (ln.startsWith("!!") && lastLine != null) { 802 ln = lastLine + ln.substring(2); 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln() 804 } 805 806 StringTokenizer t = new StringTokenizer(ln); 807 if (t.hasMoreTokens()) { 808 lastLine = ln; 809 executeCommand(t); 810 } else { 811 MessageOutput.printPrompt(); 812 } 813 } 814 } catch (VMDisconnectedException e) { 815 handler.handleDisconnectedException(); 816 } Below is a sample debug session for the following test class that sends commands "threads" and "quit" 1 public class LoopTest { 2 public static void main(String[] args) throws Exception { 3 Thread thread = Thread.currentThread(); 4 while(true) { 5 print(thread); 6 Thread.sleep(5000); 7 } 8 } 9 10 public static void print(Object obj) { 11 //System.out.println(obj); 12 } 13 } datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest Initializing jdb ... > stop go at LoopTest:6 Deferring breakpoint LoopTest:6. It will be set after the class is loaded. > run run LoopTest Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint LoopTest:6 Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); threads Group system: (java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running (java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer cond. waiting (java.lang.Thread)0x174 Signal Dispatcher running Group main: (java.lang.Thread)0x1 main sleeping Group InnocuousThreadGroup: (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); quit Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); datitov-mac:work datitov$ I think we could print a simple prompt in this case as Alex suggested. Best regards, Daniil ?On 10/17/18, 3:52 PM, "Chris Plummer" wrote: What is the jdb state for a breakpoint with SUSPEND_NONE? Can you actually type in commands even though no threads are suspended? Chris On 10/17/18 3:31 PM, Alex Menkov wrote: > Hi Daniil, Chris, > > As far as I understand, the fix does not completely fixes all > "non-atomic" output issues (at least TTY.executeCommand still prints > prompt separately), so I agree that handle it as separate issue would > be better. > Unfortunately I don't know Gary's ideas for the issue. > > About the fix for print prompt: > 1) TTY.java: > + // Print current location if suspend policy is SUSPEND_NONE > I suppose you mean "Print breakpoint location" > > 2) Does it make sense to use printCurrentLocation for > SUSPEND_EVENT_THREAD? > Is it expected to print something different from printBreakpointLocation? > > 3) I don't quite understand why we don't print simple prompt for > SUSPEND_NONE. IIUC jdb can accept new command in both > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb > waits for next command, right?) > > 4) JdbStopThreadTest.java > New line line in Java regexp is "\\R" > > --alex > > On 10/17/2018 10:47, Chris Plummer wrote: >> Hi Alex, >> >> I think the tty buffering should be a separate bug fix, and I'd also >> like input from Gary on it since he had tried something similar at >> one point. It should probably also include a multithread test to >> prove the fix is working (after first getting the test to fail >> without the changes). >> >> thanks, >> >> Chris >> >> On 10/16/18 8:59 PM, Daniil Titov wrote: >>> Hi Alex, Chris and JC, >>> >>> Please review an updated version of the patch that addresses these >>> issues. >>> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >>> Thanks! >>> --Daniil >>> >>> >>> ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: >>> >>> Hi Daniil, >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL >>> 2) wrong indent in JdbStopThreadTest.java: >>> 36 import lib.jdb.JdbCommand; >>> 37 import lib.jdb.JdbTest; >>> 3) I think it would be better to make waitForSimplePrompt >>> property of >>> JdbCommand (like JdbCommand.allowExit) >>> jdb.command(JdbCommand.run().replyIsSimplePrompt()); >>> looks much clearer than >>> jdb.command(JdbCommand.run(), true); >>> 4) (TTY.java) >>> MessageOutput.lnprint("Breakpoint hit:"); >>> + // Print current location and prompt if suspend policy is >>> SUSPEND_EVENT_THREAD. >>> + // In case of SUSPEND_ALL policy this is handled by >>> vmInterrupted() >>> method. >>> + if (be.request().suspendPolicy() == >>> EventRequest.SUSPEND_EVENT_THREAD) { >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); >>> + MessageOutput.printPrompt(); >>> + } >>> We have 3 separate outputs. >>> If we have several concurrent threads, we can easy get mess of >>> outputs >>> from different threads. >>> I think it would be better to print everything in a single chunk. >>> I suppose TTY has other places with similar "non-atomic" >>> output, so >>> maybe revising TTY output should be handled by separate issue. >>> --alex >>> On 10/11/2018 22:00, Chris Plummer wrote: >>> > Hi Daniil, >>> > >>> > Can you send output from an example jdb session? >>> > >>> > Do you think maybe we should also call printCurrentLocation() >>> when the >>> > suspend policy is NONE? >>> > >>> > There's a typo in the following line. The space is on the >>> wrong side of >>> > the comma. >>> > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS >>> ,bpLine)); >>> > >>> > thanks, >>> > >>> > Chris >>> > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote: >>> >> >>> >> Thank you, JC! >>> >> >>> >> Please review an updated version of the patch that fixes >>> newly added >>> >> test for Windows platform (now it uses system dependent line >>> >> separator string). >>> >> >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >>> >> >>> >> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >> >>> >> Best regards, >>> >> >>> >> --Daniil >>> >> >>> >> *From: *JC Beyler >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM >>> >> *To: * >>> >> *Cc: * >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when >>> breakpoint >>> >> is hit and suspend policy is STOP_EVENT_THREAD >>> >> >>> >> Hi Daniil, >>> >> >>> >> Looks good to me. I saw a really small nit: >>> >> >>> >> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >>> >>> >> >>> >>> >>> >> >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS >>> ,bpLine)); >>> >> >>> >> There is a space after the '('. >>> >> >>> >> No need to send a new webrev for that evidently :), >>> >> >>> >> Jc >>> >> >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >>> >> >> > wrote: >>> >> >>> >> Please review the change that fixes the issue with >>> missing prompt >>> >> in jdb when a breakpoint is hit and the suspend policy >>> is set to >>> >> stop the thread only. >>> >> >>> >> Webrev: >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >>> >> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >> >>> >> Thanks! >>> >> --Daniil >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Thanks, >>> >> >>> >> Jc >>> >> >>> > >>> >>> >> >> From jcbeyler at google.com Thu Oct 18 00:06:40 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 17 Oct 2018 17:06:40 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> Message-ID: Hi Dean, The new webrev looks much better :) LGTM (not a reviewer though :-)). Thanks, Jc On Wed, Oct 17, 2018 at 3:19 PM wrote: > On 10/17/18 2:38 PM, Mandy Chung wrote: > > > > On 10/17/18 2:13 PM, dean.long at oracle.com wrote: > > On 10/17/18 1:41 PM, Mandy Chung wrote: > > > > On 10/16/18 7:33 PM, David Holmes wrote: > > Hi Dean, > > Thanks for tackling this. > > I'm still struggling to fully grasp why we need both the PerfCounters and > the regular counters. I get that we have to decrement the live counts > before ensure_join() has allowed Thread.join() to return, to ensure that if > we then check the number of threads it has dropped by one. But I don't > understand why that means we need to manage the thread count in two parts. > Particularly as now you don't use the PerfCounter to return the live count, > so it makes me wonder what role the PerfCounter is playing as it is > temporarily inconsistent with the reported live count? > > > Perf counters were added long time back in JDK 1.4.2 for performance > measurement before java.lang.management API. One can use jstat tool to > monitor VM perf counters of a running VM. One could look into the > possibility of deprecating these counters and remove them over time. > > On 17/10/2018 9:43 AM, dean.long at oracle.com wrote: > New webrev: > > http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ > > > When the perf counters are updated when a thread is added/removed, it's > holding Threads_lock. Are the asserts in ThreadService::remove_thread > necessary? > > > Not really. They were intended to catch the case where the atomic > counters weren't decremented for some reason, not for the perf counters. > Should I remove them? > > > Hmm... when remove_thread is called but decrement_thread_counts has not > been called. It's a bug in thread accounting. It happens to have the > perf counters that can be compared to assert. It seems not obvious. > Setting the perf counters same values as _atomic_threads_count and > _atomic_daemon_threads_count makes sense to me. > > I would opt for removing the asserts but I can't think of an alternative > how to catch the issue you concern about. > > For clarify, I think we could simply set _live_threads_count to the value > of _atomic_threads_count and set _daemon_threads_count to the value of > _atomic_daemon_threads_count. > > > I think that works, even inside decrement_thread_counts() without holding > the Threads_lock. If you agree, I'll make that change. > > +1 > > > New webrevs, full and incremental: > > http://cr.openjdk.java.net/~dlong/8021335/webrev.6/ > http://cr.openjdk.java.net/~dlong/8021335/webrev.6.diff/ > > I like it better without all the asserts too. > > dl > > Mandy > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Oct 18 00:38:14 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 17 Oct 2018 17:38:14 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> Message-ID: Thanks JC! dl On 10/17/18 5:06 PM, JC Beyler wrote: > Hi Dean, > > The new webrev looks much better :) LGTM (not a reviewer though :-)). > > Thanks, > Jc > On Wed, Oct 17, 2018 at 3:19 PM > wrote: > > On 10/17/18 2:38 PM, Mandy Chung wrote: >> >> >> On 10/17/18 2:13 PM, dean.long at oracle.com >> wrote: >>> On 10/17/18 1:41 PM, Mandy Chung wrote: >>>> >>>> >>>> On 10/16/18 7:33 PM, David Holmes wrote: >>>>> Hi Dean, >>>>> >>>>> Thanks for tackling this. >>>>> >>>>> I'm still struggling to fully grasp why we need both the >>>>> PerfCounters and the regular counters. I get that we have to >>>>> decrement the live counts before ensure_join() has allowed >>>>> Thread.join() to return, to ensure that if we then check the >>>>> number of threads it has dropped by one. But I don't >>>>> understand why that means we need to manage the thread count >>>>> in two parts. Particularly as now you don't use the >>>>> PerfCounter to return the live count, so it makes me wonder >>>>> what role the PerfCounter is playing as it is temporarily >>>>> inconsistent with the reported live count? >>>> >>>> Perf counters were added long time back in JDK 1.4.2 for >>>> performance measurement before java.lang.management API.? One >>>> can use jstat tool to monitor VM perf counters of a running >>>> VM.?? One could look into the possibility of deprecating these >>>> counters and remove them over time. >>>> >>>>> On 17/10/2018 9:43 AM, dean.long at oracle.com >>>>> wrote: >>>>> New webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.4/ >>>>> >>>> >>>> When the perf counters are updated when a thread is >>>> added/removed, it's holding Threads_lock.? Are the asserts in >>>> ThreadService::remove_thread necessary? >>>> >>> >>> Not really.? They were intended to catch the case where the >>> atomic counters weren't decremented for some reason, not for the >>> perf counters. >>> Should I remove them? >>> >> >> Hmm... when remove_thread is called but decrement_thread_counts >> has not been called. ? It's a bug in thread accounting.? It >> happens to have the perf counters that can be compared to >> assert.? It seems not obvious.? Setting the perf counters same >> values as _atomic_threads_count and _atomic_daemon_threads_count >> makes sense to me. >> >> I would opt for removing the asserts but I can't think of an >> alternative how to catch the issue you concern about. >> >>>> For clarify, I think we could simply set _live_threads_count to >>>> the value of _atomic_threads_count and set >>>> _daemon_threads_count to the value of _atomic_daemon_threads_count. >>>> >>> >>> I think that works, even inside decrement_thread_counts() >>> without holding the Threads_lock.? If you agree, I'll make that >>> change. >>> >> +1 >> > > New webrevs, full and incremental: > > http://cr.openjdk.java.net/~dlong/8021335/webrev.6/ > > http://cr.openjdk.java.net/~dlong/8021335/webrev.6.diff/ > > > I like it better without all the asserts too. > > dl > >> Mandy > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Thu Oct 18 00:50:47 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 17 Oct 2018 17:50:47 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> <2c4b4671-492a-8293-e925-59b88bc22173@oracle.com> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> Message-ID: <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> Hi Chris, Alex and JC, I created a separate issue to deal with "non-atomic" jdb output at https://bugs.openjdk.java.net/browse/JDK-8212626 . Please review an updated fix that includes the changes Alex suggested. Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04 Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 Thanks! --Daniil ?On 10/17/18, 5:06 PM, "Daniil Titov" wrote: Hi Chris, The previous email was accidentally fired before I managed to type anything in. Sorry for confusion. Jdb constantly reads new commands from System.in despite whether the breakpoint is hit and/or the prompt is printed. cat -n src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java 786 // Process interactive commands. 787 MessageOutput.printPrompt(); 788 while (true) { 789 String ln = in.readLine(); 790 if (ln == null) { 791 /* 792 * Jdb is being shutdown because debuggee exited, ignore any 'null' 793 * returned by readLine() during shutdown. JDK-8154144. 794 */ 795 if (!isShuttingDown()) { 796 MessageOutput.println("Input stream closed."); 797 } 798 ln = "quit"; 799 } 800 801 if (ln.startsWith("!!") && lastLine != null) { 802 ln = lastLine + ln.substring(2); 803 MessageOutput.printDirectln(ln);// Special case: use printDirectln() 804 } 805 806 StringTokenizer t = new StringTokenizer(ln); 807 if (t.hasMoreTokens()) { 808 lastLine = ln; 809 executeCommand(t); 810 } else { 811 MessageOutput.printPrompt(); 812 } 813 } 814 } catch (VMDisconnectedException e) { 815 handler.handleDisconnectedException(); 816 } Below is a sample debug session for the following test class that sends commands "threads" and "quit" 1 public class LoopTest { 2 public static void main(String[] args) throws Exception { 3 Thread thread = Thread.currentThread(); 4 while(true) { 5 print(thread); 6 Thread.sleep(5000); 7 } 8 } 9 10 public static void print(Object obj) { 11 //System.out.println(obj); 12 } 13 } datitov-mac:work datitov$ ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest Initializing jdb ... > stop go at LoopTest:6 Deferring breakpoint LoopTest:6. It will be set after the class is loaded. > run run LoopTest Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: Set deferred breakpoint LoopTest:6 Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); threads Group system: (java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler running (java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer cond. waiting (java.lang.Thread)0x174 Signal Dispatcher running Group main: (java.lang.Thread)0x1 main sleeping Group InnocuousThreadGroup: (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner cond. waiting > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); quit Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 6 Thread.sleep(5000); datitov-mac:work datitov$ I think we could print a simple prompt in this case as Alex suggested. Best regards, Daniil ?On 10/17/18, 3:52 PM, "Chris Plummer" wrote: What is the jdb state for a breakpoint with SUSPEND_NONE? Can you actually type in commands even though no threads are suspended? Chris On 10/17/18 3:31 PM, Alex Menkov wrote: > Hi Daniil, Chris, > > As far as I understand, the fix does not completely fixes all > "non-atomic" output issues (at least TTY.executeCommand still prints > prompt separately), so I agree that handle it as separate issue would > be better. > Unfortunately I don't know Gary's ideas for the issue. > > About the fix for print prompt: > 1) TTY.java: > + // Print current location if suspend policy is SUSPEND_NONE > I suppose you mean "Print breakpoint location" > > 2) Does it make sense to use printCurrentLocation for > SUSPEND_EVENT_THREAD? > Is it expected to print something different from printBreakpointLocation? > > 3) I don't quite understand why we don't print simple prompt for > SUSPEND_NONE. IIUC jdb can accept new command in both > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that jdb > waits for next command, right?) > > 4) JdbStopThreadTest.java > New line line in Java regexp is "\\R" > > --alex > > On 10/17/2018 10:47, Chris Plummer wrote: >> Hi Alex, >> >> I think the tty buffering should be a separate bug fix, and I'd also >> like input from Gary on it since he had tried something similar at >> one point. It should probably also include a multithread test to >> prove the fix is working (after first getting the test to fail >> without the changes). >> >> thanks, >> >> Chris >> >> On 10/16/18 8:59 PM, Daniil Titov wrote: >>> Hi Alex, Chris and JC, >>> >>> Please review an updated version of the patch that addresses these >>> issues. >>> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >>> Thanks! >>> --Daniil >>> >>> >>> ?On 10/12/18, 9:52 AM, "Alex Menkov" wrote: >>> >>> Hi Daniil, >>> 1) +1 for printCurrentLocation when suspendPolicy != SUSPEND_ALL >>> 2) wrong indent in JdbStopThreadTest.java: >>> 36 import lib.jdb.JdbCommand; >>> 37 import lib.jdb.JdbTest; >>> 3) I think it would be better to make waitForSimplePrompt >>> property of >>> JdbCommand (like JdbCommand.allowExit) >>> jdb.command(JdbCommand.run().replyIsSimplePrompt()); >>> looks much clearer than >>> jdb.command(JdbCommand.run(), true); >>> 4) (TTY.java) >>> MessageOutput.lnprint("Breakpoint hit:"); >>> + // Print current location and prompt if suspend policy is >>> SUSPEND_EVENT_THREAD. >>> + // In case of SUSPEND_ALL policy this is handled by >>> vmInterrupted() >>> method. >>> + if (be.request().suspendPolicy() == >>> EventRequest.SUSPEND_EVENT_THREAD) { >>> + printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); >>> + MessageOutput.printPrompt(); >>> + } >>> We have 3 separate outputs. >>> If we have several concurrent threads, we can easy get mess of >>> outputs >>> from different threads. >>> I think it would be better to print everything in a single chunk. >>> I suppose TTY has other places with similar "non-atomic" >>> output, so >>> maybe revising TTY output should be handled by separate issue. >>> --alex >>> On 10/11/2018 22:00, Chris Plummer wrote: >>> > Hi Daniil, >>> > >>> > Can you send output from an example jdb session? >>> > >>> > Do you think maybe we should also call printCurrentLocation() >>> when the >>> > suspend policy is NONE? >>> > >>> > There's a typo in the following line. The space is on the >>> wrong side of >>> > the comma. >>> > >>> > 72 jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS >>> ,bpLine)); >>> > >>> > thanks, >>> > >>> > Chris >>> > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote: >>> >> >>> >> Thank you, JC! >>> >> >>> >> Please review an updated version of the patch that fixes >>> newly added >>> >> test for Windows platform (now it uses system dependent line >>> >> separator string). >>> >> >>> >> Webrev:http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ >>> >> >>> >> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >> >>> >> Best regards, >>> >> >>> >> --Daniil >>> >> >>> >> *From: *JC Beyler >>> >> *Date: *Thursday, October 11, 2018 at 7:17 PM >>> >> *To: * >>> >> *Cc: * >>> >> *Subject: *Re: RFR 8211736: jdb doesn't print prompt when >>> breakpoint >>> >> is hit and suspend policy is STOP_EVENT_THREAD >>> >> >>> >> Hi Daniil, >>> >> >>> >> Looks good to me. I saw a really small nit: >>> >> >>> >> >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01/test/jdk/com/sun/jdi/JdbStopThreadTest.java.html >>> >>> >> >>> >>> >>> >> >>> >> 70 jdb.command(JdbCommand.stopThreadAt( DEBUGGEE_CLASS >>> ,bpLine)); >>> >> >>> >> There is a space after the '('. >>> >> >>> >> No need to send a new webrev for that evidently :), >>> >> >>> >> Jc >>> >> >>> >> On Thu, Oct 11, 2018 at 5:07 PM Daniil Titov >>> >> >> > wrote: >>> >> >>> >> Please review the change that fixes the issue with >>> missing prompt >>> >> in jdb when a breakpoint is hit and the suspend policy >>> is set to >>> >> stop the thread only. >>> >> >>> >> Webrev: >>> http://cr.openjdk.java.net/~dtitov/8211736/webrev.01 >>> >> >>> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >>> >> >>> >> Thanks! >>> >> --Daniil >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Thanks, >>> >> >>> >> Jc >>> >> >>> > >>> >>> >> >> From david.holmes at oracle.com Thu Oct 18 01:34:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Oct 2018 11:34:01 +1000 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: <71A6706A-B1C5-46CD-927B-BE07538AB779@amazon.com> References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> <71A6706A-B1C5-46CD-927B-BE07538AB779@amazon.com> Message-ID: <5ac7df0a-1a5d-59ac-4ce5-6dadcbf26b92@oracle.com> On 18/10/2018 6:01 AM, Hohensee, Paul wrote: > Re spaces :).? There?s a bunch of places where ?(jvmti_env? ?should be > ?( jvmti_env?, but of course not all of them. I found a bunch. Why should there be a space after the '(' ? That's not hotspot-style. Neither is a space before ')'. David > Otherwise, lgtm., no need for another webrev. > > Paul > > In hs104t002.cpp > > -??????? if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, > > -??????????????? &caps) )) { > > +??????? if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > => > > +??????? if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > In hs203t003.cpp > > -??? if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB4(GetClassSignature, > > -?????????????????? ?jvmti_env, klass, &className, &generic) ) ) { > > +??? if ( ! NSK_JVMTI_VERIFY (jvmti_env->GetClassSignature(klass, > &className, &generic) ) ) { > > => > > +??? if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GetClassSignature(klass, > &className, &generic) ) ) { > > and > > -??????? if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, > &caps) )) { > > +??????? if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > => > > +??????? if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > and > > -??? if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, > thread, &state) )? ) { > > +??? if ( ! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state) )? ) { > > => > > +??? if ( ! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state) )? ) { > > and > > -??? if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, > thread, &state) )? ) { > > +??? if ( ! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state) )? ) { > > ???????? nsk_printf(" Agent :: Error while getting thread state.\n"); > > ???????? nsk_jvmti_agentFailed(); > > ???? } else { > > ???????? if ( state & JVMTI_THREAD_STATE_SUSPENDED) { > > -??????????? if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2( PopFrame, jvmti, > thread) ) ) { > > +??????????? if ( ! NSK_JVMTI_VERIFY (jvmti->PopFrame(thread) ) ) { > > => > > +??? if ( ! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state) )? ) { > > ? > > +??????????? if ( ! NSK_JVMTI_VERIFY ( jvmti->PopFrame(thread) ) ) { > > and > > -??? if ( !NSK_JVMTI_VERIFY( NSK_CPP_STUB2 ( ResumeThread, jvmti, > thread)) ) { > > +??? if ( !NSK_JVMTI_VERIFY(jvmti->ResumeThread(thread)) ) { > > => > > +??? if ( !NSK_JVMTI_VERIFY( jvmti->ResumeThread(thread)) ) { > > In hs203t004.cpp > > -??????????????? if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(GenerateEvents, > jvmti_env, > > -??????????????????????????????? JVMTI_EVENT_COMPILED_METHOD_LOAD ) )) { > > +??????????????? if ( ! NSK_JVMTI_VERIFY > (jvmti_env->GenerateEvents(JVMTI_EVENT_COMPILED_METHOD_LOAD) )) { > > => > > +??????????????? if ( ! NSK_JVMTI_VERIFY ( > jvmti_env->GenerateEvents(JVMTI_EVENT_COMPILED_METHOD_LOAD) )) { > > and > > -??????? if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB3(GetMethodDeclaringClass, > > -??????????????????????? jvmti_env, method, &threadClass) ) ) { > > +??????? if ( ! NSK_JVMTI_VERIFY > (jvmti_env->GetMethodDeclaringClass(method, &threadClass) ) ) { > > => > > +??????? if ( ! NSK_JVMTI_VERIFY ( > jvmti_env->GetMethodDeclaringClass(method, &threadClass) ) ) { > > and > > -??????? if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, > &caps) )) { > > +??????? if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > => > > +??????? if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > and > > -??? if (? NSK_JVMTI_VERIFY( NSK_CPP_STUB2(SuspendThread, jvmti, thread) > ) ) { > > +??? if (? NSK_JVMTI_VERIFY(jvmti->SuspendThread(thread) ) ) { > > => > > +??? if (? NSK_JVMTI_VERIFY( jvmti->SuspendThread(thread) ) ) { > > and > > -? ??if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB3(GetThreadState, jvmti, > > -??????????????????? thread, &state) ) ) { > > +??? if ( ! NSK_JVMTI_VERIFY (jvmti->GetThreadState(thread, &state) ) ) { > > ???????? NSK_COMPLAIN0("#error Agent :: while getting thread's state.\n"); > > ???????? nsk_jvmti_agentFailed(); > > ???? } else { > > ???????? if ( state & JVMTI_THREAD_STATE_SUSPENDED) { > > -??????????? if ( ! NSK_JVMTI_VERIFY( NSK_CPP_STUB2(PopFrame, jvmti, > thread) ) ){ > > +??????????? if ( ! NSK_JVMTI_VERIFY(jvmti->PopFrame(thread) ) ){ > > => > > +??? if ( ! NSK_JVMTI_VERIFY ( jvmti->GetThreadState(thread, &state) ) ) { > > ? > > +??????????? if ( ! NSK_JVMTI_VERIFY( jvmti->PopFrame(thread) ) ){ > > In hs204t001.cpp > > -??????? /* if( (myTestClass =NSK_CPP_STUB2(NewGlobalRef,jni_env, > klass)) == NULL) { > > +??????? /* if( (myTestClass =jni_env->NewGlobalRef(klass)) == NULL) { > > => > > +??????? /* if( (myTestClass = jni_env->NewGlobalRef(klass)) == NULL) { > > and > > -??? if (!NSK_JNI_VERIFY(env, (testClass =(jclass) > NSK_CPP_STUB2(NewGlobalRef, env, klass)) != NULL)) > > +??? if (!NSK_JNI_VERIFY(env, (testClass =(jclass) > env->NewGlobalRef(klass)) != NULL)) > > ???????? nsk_jvmti_setFailStatus(); > > -??? if (!NSK_JNI_VERIFY(env, (testedThread =NSK_CPP_STUB2(NewGlobalRef, > env, thread)) != NULL)) > > +??? if (!NSK_JNI_VERIFY(env, (testedThread =env->NewGlobalRef(thread)) > != NULL)) > > => > > +??? if (!NSK_JNI_VERIFY(env, (testClass = (jclass) > env->NewGlobalRef(klass)) != NULL)) > > ???????? nsk_jvmti_setFailStatus(); > > ? > > +??? if (!NSK_JNI_VERIFY(env, (testedThread = env->NewGlobalRef(thread)) > != NULL)) > > and > > -??????????? if (!NSK_JVMTI_VERIFY(? NSK_CPP_STUB2(SuspendThread, jvmti, > thread))) { > > +??????????? if (!NSK_JVMTI_VERIFY(? jvmti->SuspendThread(thread))) { > > => > > +??????????? if (!NSK_JVMTI_VERIFY(jvmti->SuspendThread(thread))) { > > In hs204t003.cpp > > -??? if (! NSK_JVMTI_VERIFY( NSK_CPP_STUB3(GetThreadState, jvmti, > thread, &state)) ){ > > +??? if (! NSK_JVMTI_VERIFY(jvmti->GetThreadState(thread, &state)) ){ > > ???????? NSK_DISPLAY0(" Agent :: Error getting thread state.\n"); > > ???????? nsk_jvmti_agentFailed(); > > ???? } else { > > ???????? if ( state & JVMTI_THREAD_STATE_SUSPENDED) { > > ???????????? NSK_DISPLAY0(" Agent :: Thread state = JVMTI_THREAD_STATE_SUSPENDED.\n"); > > -??????????? if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(PopFrame, jvmti, > thread) ) ) { > > +??????????? if ( ! NSK_JVMTI_VERIFY (jvmti->PopFrame(thread) ) ) { > > ???????????????? NSK_DISPLAY0("#error Agent :: Jvmti failed to do popFrame.\n"); > > ???????????????? nsk_jvmti_agentFailed(); > > ???????????? } else { > > -?????? ?????????if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(ResumeThread, > jvmti, thread)) ) { > > +??????????????? if ( ! NSK_JVMTI_VERIFY (jvmti->ResumeThread(thread)) ) { > > => > > +??? if (! NSK_JVMTI_VERIFY( jvmti->GetThreadState(thread, &state)) ){ > > ? > > +??????????? if ( ! NSK_JVMTI_VERIFY ( jvmti->PopFrame(thread) ) ) { > > ? > > +??????????????? if ( ! NSK_JVMTI_VERIFY ( jvmti->ResumeThread(thread)) ) { > > In hs301t001.cpp > > -??????? if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, > &caps) )) { > > +??????? if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) )) { > > => > > +? ??????if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) )) { > > In hs301t002.cpp > > -??????? if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, > &caps) ) ) { > > +??????? if ( ! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) ) ) { > > => > > +??????? if ( ! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) ) ) { > > In hs301t003.cpp > > -? if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB4(GetClassSignature, > > -????????????????? jvmti_env, klass, &className, &generic) ) ) { > > +? if ( ! NSK_JVMTI_VERIFY (jvmti_env->GetClassSignature(klass, > &className, &generic) ) ) { > > => > > +? if ( ! NSK_JVMTI_VERIFY ( jvmti_env->GetClassSignature(klass, > &className, &generic) ) ) { > > and > > -??????? if (! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, jvmti, > &caps) ))? { > > +??????? if (! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) ))? { > > => > > +??????? if (! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) ))? { > > and > > -??????? if ( ! NSK_JVMTI_VERIFY ( NSK_CPP_STUB2(AddCapabilities, > > -??????????????????????? jvmti, &caps) ))? { > > +????? ??if ( ! NSK_JVMTI_VERIFY (jvmti->AddCapabilities(&caps) ))? { > > => > > +??????? if ( ! NSK_JVMTI_VERIFY ( jvmti->AddCapabilities(&caps) ))? { > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Tuesday, October 16, 2018 at 4:24 PM > *To: *"alexey.menkov at oracle.com" > *Cc: *"serviceability-dev at openjdk.java.net" > > *Subject: *Re: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from > vmTestbase for jvmti/scenarios/[E-M] > > Hi all, > > How about on a Tuesday? :) > > Sneak peak and motivational sentence: after this goes in, we have this > one which > removes the NSK_CPP_STUBs from the tests entirely! :) > > Jc > > On Fri, Oct 12, 2018 at 5:37 PM JC Beyler > wrote: > > Hi all, > > Any chance for a second reviewer on a Friday? :) > > Jc > > On Thu, Oct 11, 2018 at 11:03 AM Alex Menkov > > wrote: > > got it. > > LGTM. > > --alex > > On 10/10/2018 19:03, JC Beyler wrote: > > Hi Alex, > > > > Thanks for the review! Yes I had seen that too before sending > this > > review out and forked that fix into this: > > https://bugs.openjdk.java.net/browse/JDK-8211905 > > > > Which now is merged and I've updated my webrev to reflect > this of course. > > > > My rationale for not doing it here directly is always the > same: keeping > > the changes to the "spirit" of what the change is trying to > do. Those > > extra casts were a bit out-of-scope and so I just forked the > fix in 8211905. > > > > Thanks! > > Jc > > > > On Wed, Oct 10, 2018 at 5:40 PM Alex Menkov > > > >> wrote: > > > >? ? ?Hi Jc, > > > >? ? ?Overall looks good. > > > >? ? ?one minor note: > > > > > ?test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM06/em06t001/em06t001.cpp: > >? ? ?-? ? jclassName = (jstring) (jstring) (jstring) (jstring) > (jstring) > >? ? ?(jstring) (jstring) (jstring) (jstring) > NSK_CPP_STUB3(CallObjectMethod, > >? ? ?jni_env, klass, > >? ? ?-? ? ? ? ? ? ? ? ? ? ? ? methodID); > >? ? ?+? ? jclassName = (jstring) (jstring) (jstring) (jstring) > (jstring) > >? ? ?(jstring) (jstring) (jstring) (jstring) > >? ? ?jni_env->CallObjectMethod(klass, > >? ? ?methodID); > > > >? ? ?Please drop multi "(jstring)" > > > >? ? ?--alex > > > >? ? ?On 10/08/2018 21:21, JC Beyler wrote: > >? ? ? > Hi all, > >? ? ? > > >? ? ? > I am continuing the NSK_CPP_STUB removal with this > next webrev. > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8211899/webrev.00/ > > >? ? ? > >? ? ? > > > >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8211899 > >? ? ? > > >? ? ? > The change is still straight-forward though, since it > is just > >? ? ?doing the > >? ? ? > same NSK_CPP_STUB removal. However when I was looking > at the > >? ? ?changes, a > >? ? ? > lot of these changes are touching lines with spaces > before/after > >? ? ? > parenthesis. I've almost never touched the spaces > except if I was > >? ? ? > refactoring by hand the line at the same time. The > rationale > >? ? ?being that > >? ? ? > the lines will get fixed a few more times and are, at > worse, > >? ? ?covered by > >? ? ? > the bug: > https://bugs.openjdk.java.net/browse/JDK-8211335, which > >? ? ?I've > >? ? ? > commited to doing. > >? ? ? > > >? ? ? > Two exceptions are here where I pushed out the code into > >? ? ?assignments due > >? ? ? > to really long lines and complex if structures: > >? ? ? > - jvmti/scenarios/hotswap/HS204/hs204t003/hs204t003.cpp > >? ? ? > > > > ? > >? ? ? > - > jvmti/scenarios/jni_interception/JI01/ji01t001/ji01t001.cpp > >? ? ? > > > > ? > >? ? ? > > >? ? ? > And one exception here where a commented line was > doing the > >? ? ?out-of-if > >? ? ? > assignment so I just uncommented it and used the variable: > >? ? ? > - jvmti/scenarios/hotswap/HS301/hs301t001/hs301t001.cpp > >? ? ? > > > > ? > >? ? ? > > >? ? ? > I've tested the modified changes on my machine, all > modified > >? ? ?tests pass. > >? ? ? > > >? ? ? > Let me know what you think, > >? ? ? > Jc > >? ? ? > > >? ? ? > Ps: 2 more of these and we can say good bye to > NSK_CPP_STUB* > >? ? ? > > > > > > > > > -- > > > > Thanks, > > Jc > > > -- > > Thanks, > > Jc > > > -- > > Thanks, > > Jc > From david.holmes at oracle.com Thu Oct 18 01:34:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Oct 2018 11:34:32 +1000 Subject: RFR (S): 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: <4d04cd45-5cc2-0978-fdb4-2f405156c3ef@oracle.com> References: <4d04cd45-5cc2-0978-fdb4-2f405156c3ef@oracle.com> Message-ID: <65d91773-bd7d-e090-6fbf-80af2dd13aaa@oracle.com> Thanks Serguei! David On 18/10/2018 9:00 AM, serguei.spitsyn at oracle.com wrote: > Hi David, > > Sorry for being late but just wanted to tell you that it looks good to me. > Thank you for catching and taking care about it! > > Thanks, > Serguei > > > On 10/14/18 22:12, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8211909 >> webrev: http://cr.openjdk.java.net/~dholmes/8211909/webrev/ >> >> The crash occurs when trying to access a thread that was returned as >> part of JVM TI GetThreadGroupChildren. The problem is that the JVM TI >> code tries to use the Threads_lock to ensure atomic access to the >> ThreadGroup's threads and child groups: >> >> ??? { // Cannot allow thread or group counts to change. >> ????? MutexLocker mu(Threads_lock); >> >> but the Threads_lock does not control concurrency in the Java code >> that can cause threads to be added and removed, so we do not get a >> stable snapshot of the thread array and its length, and contents. To >> get a stable snapshot we have to use the same synchronization >> mechanism as used by the Java code: lock the monitor of the >> ThreadGroup instance. >> >> Two other pointless acquisitions of the Threads_lock, in GetThreadInfo >> and GetThreadGroupInfo, were also removed. These functions could >> report an inconsistent snapshot of the Thread or ThreadGroup state, if >> the mutable state is mutated concurrently. Again we could acquire the >> object's monitor to prevent this but it is unclear that there is any >> real benefit in doing so - after all the thread/group information >> could change immediately after it has been read anyway. So here I just >> delete the Threads_lock usage. >> >> Testing: mach5 tier 1-3 >> ???????? JVM TI tests (serviceability/jvmti vmTestbase/nsk/jvmti/) >> >> A regression test may be possible if we call GetThreadGroupChildren in >> a loop, whilst threads add and remove themselves from the group >> concurrently. But it is awkward to write. >> >> Thanks, >> David >> >> Thanks, >> David > From mandy.chung at oracle.com Thu Oct 18 01:35:21 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 17 Oct 2018 18:35:21 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> Message-ID: <08740d81-34dd-a356-1f2e-9bd1994b16f1@oracle.com> On 10/17/18 3:18 PM, dean.long at oracle.com wrote: > > New webrevs, full and incremental: > > http://cr.openjdk.java.net/~dlong/8021335/webrev.6/ > http://cr.openjdk.java.net/~dlong/8021335/webrev.6.diff/ > > I like it better without all the asserts too. Looks good to me. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Oct 18 01:53:09 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 17 Oct 2018 18:53:09 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> References: <00A38007-4C48-47F6-BE85-ECA904E56148@oracle.com> <09f1ff49-127e-d5a0-499f-6340f5155837@oracle.com> <0696bbaf-b890-77a4-fa36-24ce8c11f6a0@oracle.com> <1AFE9A3F-2668-4E6F-83D4-839953B980A5@oracle.com> <2c4b4671-492a-8293-e925-59b88bc22173@oracle.com> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> Message-ID: Hi Daniil, It looks good to me. I noticed a tiny nit in TTY.java where you removed an empty line (l171) Thanks! Jc On Wed, Oct 17, 2018 at 5:50 PM Daniil Titov wrote: > Hi Chris, Alex and JC, > > I created a separate issue to deal with "non-atomic" jdb output at > https://bugs.openjdk.java.net/browse/JDK-8212626 . > > Please review an updated fix that includes the changes Alex suggested. > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.04 > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Thanks! > --Daniil > > > ?On 10/17/18, 5:06 PM, "Daniil Titov" wrote: > > Hi Chris, > > The previous email was accidentally fired before I managed to type > anything in. Sorry for confusion. > > Jdb constantly reads new commands from System.in despite whether the > breakpoint is hit and/or the prompt is printed. > > cat -n > src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java > > 786 // Process interactive commands. > 787 MessageOutput.printPrompt(); > 788 while (true) { > 789 String ln = in.readLine(); > 790 if (ln == null) { > 791 /* > 792 * Jdb is being shutdown because > debuggee exited, ignore any 'null' > 793 * returned by readLine() during > shutdown. JDK-8154144. > 794 */ > 795 if (!isShuttingDown()) { > 796 MessageOutput.println("Input > stream closed."); > 797 } > 798 ln = "quit"; > 799 } > 800 > 801 if (ln.startsWith("!!") && lastLine != > null) { > 802 ln = lastLine + ln.substring(2); > 803 MessageOutput.printDirectln(ln);// > Special case: use printDirectln() > 804 } > 805 > 806 StringTokenizer t = new > StringTokenizer(ln); > 807 if (t.hasMoreTokens()) { > 808 lastLine = ln; > 809 executeCommand(t); > 810 } else { > 811 MessageOutput.printPrompt(); > 812 } > 813 } > 814 } catch (VMDisconnectedException e) { > 815 handler.handleDisconnectedException(); > 816 } > > Below is a sample debug session for the following test class that > sends commands "threads" and "quit" > 1 public class LoopTest { > 2 public static void main(String[] args) throws > Exception { > 3 Thread thread = Thread.currentThread(); > 4 while(true) { > 5 print(thread); > 6 Thread.sleep(5000); > 7 } > 8 } > 9 > 10 public static void print(Object obj) { > 11 //System.out.println(obj); > 12 } > 13 } > > datitov-mac:work datitov$ > ~/src/jdk-hs/build/macosx-x64-debug/images/jdk/bin/jdb LoopTest > Initializing jdb ... > > stop go at LoopTest:6 > Deferring breakpoint LoopTest:6. > It will be set after the class is loaded. > > run > run LoopTest > Set uncaught java.lang.Throwable > Set deferred uncaught java.lang.Throwable > > > VM Started: Set deferred breakpoint LoopTest:6 > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 > 6 Thread.sleep(5000); > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 > 6 Thread.sleep(5000); > threads > Group system: > (java.lang.ref.Reference$ReferenceHandler)0x172 Reference Handler > running > (java.lang.ref.Finalizer$FinalizerThread)0x173 Finalizer > cond. waiting > (java.lang.Thread)0x174 Signal Dispatcher > running > Group main: > (java.lang.Thread)0x1 main > sleeping > Group InnocuousThreadGroup: > (jdk.internal.misc.InnocuousThread)0x197 Common-Cleaner > cond. waiting > > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 > 6 Thread.sleep(5000); > > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 > 6 Thread.sleep(5000); > quit > Breakpoint hit: "thread=main", LoopTest.main(), line=6 bci=8 > 6 Thread.sleep(5000); > > datitov-mac:work datitov$ > > I think we could print a simple prompt in this case as Alex suggested. > > Best regards, > Daniil > > ?On 10/17/18, 3:52 PM, "Chris Plummer" > wrote: > > What is the jdb state for a breakpoint with SUSPEND_NONE? Can you > actually type in commands even though no threads are suspended? > > Chris > > On 10/17/18 3:31 PM, Alex Menkov wrote: > > Hi Daniil, Chris, > > > > As far as I understand, the fix does not completely fixes all > > "non-atomic" output issues (at least TTY.executeCommand still > prints > > prompt separately), so I agree that handle it as separate issue > would > > be better. > > Unfortunately I don't know Gary's ideas for the issue. > > > > About the fix for print prompt: > > 1) TTY.java: > > + // Print current location if suspend policy is > SUSPEND_NONE > > I suppose you mean "Print breakpoint location" > > > > 2) Does it make sense to use printCurrentLocation for > > SUSPEND_EVENT_THREAD? > > Is it expected to print something different from > printBreakpointLocation? > > > > 3) I don't quite understand why we don't print simple prompt for > > SUSPEND_NONE. IIUC jdb can accept new command in both > > SUSPEND_EVENT_THREAD and SUSPEND_NONE cases (prompt shows that > jdb > > waits for next command, right?) > > > > 4) JdbStopThreadTest.java > > New line line in Java regexp is "\\R" > > > > --alex > > > > On 10/17/2018 10:47, Chris Plummer wrote: > >> Hi Alex, > >> > >> I think the tty buffering should be a separate bug fix, and I'd > also > >> like input from Gary on it since he had tried something similar > at > >> one point. It should probably also include a multithread test > to > >> prove the fix is working (after first getting the test to fail > >> without the changes). > >> > >> thanks, > >> > >> Chris > >> > >> On 10/16/18 8:59 PM, Daniil Titov wrote: > >>> Hi Alex, Chris and JC, > >>> > >>> Please review an updated version of the patch that addresses > these > >>> issues. > >>> > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/ > >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > >>> > >>> Thanks! > >>> --Daniil > >>> > >>> > >>> ?On 10/12/18, 9:52 AM, "Alex Menkov" > wrote: > >>> > >>> Hi Daniil, > >>> 1) +1 for printCurrentLocation when suspendPolicy != > SUSPEND_ALL > >>> 2) wrong indent in JdbStopThreadTest.java: > >>> 36 import lib.jdb.JdbCommand; > >>> 37 import lib.jdb.JdbTest; > >>> 3) I think it would be better to make waitForSimplePrompt > >>> property of > >>> JdbCommand (like JdbCommand.allowExit) > >>> jdb.command(JdbCommand.run().replyIsSimplePrompt()); > >>> looks much clearer than > >>> jdb.command(JdbCommand.run(), true); > >>> 4) (TTY.java) > >>> MessageOutput.lnprint("Breakpoint hit:"); > >>> + // Print current location and prompt if suspend policy > is > >>> SUSPEND_EVENT_THREAD. > >>> + // In case of SUSPEND_ALL policy this is handled by > >>> vmInterrupted() > >>> method. > >>> + if (be.request().suspendPolicy() == > >>> EventRequest.SUSPEND_EVENT_THREAD) { > >>> + > printCurrentLocation(ThreadInfo.getThreadInfo(be.thread())); > >>> + MessageOutput.printPrompt(); > >>> + } > >>> We have 3 separate outputs. > >>> If we have several concurrent threads, we can easy get > mess of > >>> outputs > >>> from different threads. > >>> I think it would be better to print everything in a > single chunk. > >>> I suppose TTY has other places with similar "non-atomic" > >>> output, so > >>> maybe revising TTY output should be handled by separate > issue. > >>> --alex > >>> On 10/11/2018 22:00, Chris Plummer wrote: > >>> > Hi Daniil, > >>> > > >>> > Can you send output from an example jdb session? > >>> > > >>> > Do you think maybe we should also call > printCurrentLocation() > >>> when the > >>> > suspend policy is NONE? > >>> > > >>> > There's a typo in the following line. The space is on > the > >>> wrong side of > >>> > the comma. > >>> > > >>> > 72 > jdb.command(JdbCommand.stopThreadAt(DEBUGGEE_CLASS > >>> ,bpLine)); > >>> > > >>> > thanks, > >>> > > >>> > Chris > >>> > > >>> > On 10/11/18 8:02 PM, Daniil Titov wrote: > >>> >> > >>> >> Thank you, JC! > >>> >> > >>> >> Please review an updated version of the patch that > fixes > >>> newly added > >>> >> test for Windows platform (now it uses system > dependent line > >>> >> separator string). > >>> >>