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). > >>> >> > >>> >> Webrev: > http://cr.openjdk.java.net/~dtitov/8211736/webrev.02/ > >>> >> < > http://cr.openjdk.java.net/%7Edtitov/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 > >>> > >>> >> > >>> < > http://cr.openjdk.java.net/%7Edtitov/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 > >>> >> < > http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01> > >>> >> Issue: > https://bugs.openjdk.java.net/browse/JDK-8211736 > >>> >> > >>> >> Thanks! > >>> >> --Daniil > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> > >>> >> Thanks, > >>> >> > >>> >> Jc > >>> >> > >>> > > >>> > >>> > >> > >> > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Oct 18 01:57:38 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 17 Oct 2018 18:57:38 -0700 Subject: RFR (L) 8211899: Remove the NSK_CPP_STUB macros from vmTestbase for jvmti/scenarios/[E-M] In-Reply-To: <5ac7df0a-1a5d-59ac-4ce5-6dadcbf26b92@oracle.com> References: <7fb9b64d-4e8a-da44-0d5b-b9b18c542274@oracle.com> <71A6706A-B1C5-46CD-927B-BE07538AB779@amazon.com> <5ac7df0a-1a5d-59ac-4ce5-6dadcbf26b92@oracle.com> Message-ID: Hi all, @Serguei: no worries for the time taken, I am just two webrevs away from conquering the NSK_CPP_STUBs, I might have been a bit pushy for a review :-) I apologize! @David: It's not hotspot style but a lot of those files had that style. My CL actually makes it non-conforming all around: if ( before_we_had_this ) // space after ( + space before ) if (now_we_have_this ) // only space before ) which is kind of weird and Paul's comment was to at least try to not make it inconsistent to that point. I have one webrev to go that will remove NSK_CPP_STUBs and then I'm going to fix all the spaces (via https://bugs.openjdk.java.net/browse/JDK-8211335) for these .cpp files so we won't have the issue anymore. Does that make sense? Thanks! Jc On Wed, Oct 17, 2018 at 6:34 PM David Holmes wrote: > 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/ > > > > > < > http://cr.openjdk.java.net/%7Ejcbeyler/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 david.holmes at oracle.com Thu Oct 18 02:07:27 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Oct 2018 12:07:27 +1000 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: <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> Hi Dean, This still seems racy to me. We increment all counts under the Threads_lock but we still decrement without the Threads_lock. So we can lose updates to the perfCounters. 117 _total_threads_count->inc(); 118 Atomic::inc(&_atomic_threads_count); 119 int count = _atomic_threads_count; <= context switch here 120 _live_threads_count->set_value(count); If a second thread now exits while the above thread is descheduled, it will decrement _atomic_threads_count and _live_threads_count, but when the first thread resumes at line 120 above we will set _live_threads_count to the wrong value! You can't maintain two counters in sync without all changes using locking across both. David On 18/10/2018 8:18 AM, dean.long at oracle.com 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 > From david.holmes at oracle.com Thu Oct 18 02:26:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Oct 2018 12:26:20 +1000 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> <71A6706A-B1C5-46CD-927B-BE07538AB779@amazon.com> <5ac7df0a-1a5d-59ac-4ce5-6dadcbf26b92@oracle.com> Message-ID: <63240ade-4e7a-0723-9074-8c2d1f06647a@oracle.com> On 18/10/2018 11:57 AM, JC Beyler wrote: > Hi all, > > @Serguei: no worries for the time taken, I am just two webrevs away from > conquering the NSK_CPP_STUBs, I might have been a bit pushy for a review > :-) I apologize! > > @David: It's not hotspot style but a lot of those files had that style. > My CL actually makes it non-conforming all around: > > if ( before_we_had_this ) // space after (?+ space before ) > > if (now_we_have_this )? // only space before ) > > which is kind of weird and Paul's comment was to at least try to not > make it inconsistent to that point. > > I have one webrev to go that will remove NSK_CPP_STUBs and then I'm > going to fix all the spaces (via > https://bugs.openjdk.java.net/browse/JDK-8211335) for these .cpp files > so we won't have the issue anymore. > > Does that make sense? Yes thanks for clarifying. David > Thanks! > Jc > > > On Wed, Oct 17, 2018 at 6:34 PM David Holmes > wrote: > > 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 > > > > > > -- > > Thanks, > Jc From dean.long at oracle.com Thu Oct 18 03:09:18 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 17 Oct 2018 20:09:18 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <08740d81-34dd-a356-1f2e-9bd1994b16f1@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <08740d81-34dd-a356-1f2e-9bd1994b16f1@oracle.com> Message-ID: Thanks, Mandy! dl On 10/17/18 6:35 PM, Mandy Chung wrote: > > > 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 dean.long at oracle.com Thu Oct 18 04:06:41 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 17 Oct 2018 21:06:41 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> Message-ID: <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> On 10/17/18 7:07 PM, David Holmes wrote: > Hi Dean, > > This still seems racy to me. We increment all counts under the > Threads_lock but we still decrement without the Threads_lock. So we > can lose updates to the perfCounters. > > ?117?? _total_threads_count->inc(); > ?118?? Atomic::inc(&_atomic_threads_count); > ?119?? int count = _atomic_threads_count; > <= context switch here > ?120?? _live_threads_count->set_value(count); > > If a second thread now exits while the above thread is descheduled, it > will decrement _atomic_threads_count and _live_threads_count, but when > the first thread resumes at line 120 above we will set > _live_threads_count to the wrong value! > > You can't maintain two counters in sync without all changes using > locking across both. > You're right, I missed that.? I think the right thing to do is call current_thread_exiting while holding the Threads_lock. Then we can get rid of the parallel atomic counters.? So, here's one more try: ??? http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ dl > David > > > > On 18/10/2018 8:18 AM, dean.long at oracle.com 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 >> From david.holmes at oracle.com Thu Oct 18 07:27:29 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Oct 2018 17:27:29 +1000 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> Message-ID: Hi Dean, On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: > On 10/17/18 7:07 PM, David Holmes wrote: >> Hi Dean, >> >> This still seems racy to me. We increment all counts under the >> Threads_lock but we still decrement without the Threads_lock. So we >> can lose updates to the perfCounters. >> >> ?117?? _total_threads_count->inc(); >> ?118?? Atomic::inc(&_atomic_threads_count); >> ?119?? int count = _atomic_threads_count; >> <= context switch here >> ?120?? _live_threads_count->set_value(count); >> >> If a second thread now exits while the above thread is descheduled, it >> will decrement _atomic_threads_count and _live_threads_count, but when >> the first thread resumes at line 120 above we will set >> _live_threads_count to the wrong value! >> >> You can't maintain two counters in sync without all changes using >> locking across both. >> > > You're right, I missed that.? I think the right thing to do is call > current_thread_exiting while holding the Threads_lock. > Then we can get rid of the parallel atomic counters.? So, here's one > more try: > > ??? http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ Okay that is the simple and obvious solution that doesn't require split counts. So I have to ask Mandy if she recalls why this approach wasn't taken 15 years ago when the exit counts were added as part of: https://bugs.openjdk.java.net/browse/JDK-4530538 ? Does taking the Threads_lock here cost too much and cause a thread termination bottleneck? Thanks, David ----- > dl > >> David >> >> >> >> On 18/10/2018 8:18 AM, dean.long at oracle.com 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 >>> > From fairoz.matte at oracle.com Thu Oct 18 07:37:06 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Thu, 18 Oct 2018 00:37:06 -0700 (PDT) Subject: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash Message-ID: <26a59905-e267-47d8-90f6-8f0571e5d5ce@default> Hi, Kindly review the backport of "8211909: JDWP Transport Listener: dt_socket thread crash" to 8u code is almost cleanly applied. Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ JBS bug - https://bugs.openjdk.java.net/browse/JDK-8211909 JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/a4d4c609d70c Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025515.html Thanks, Fairoz From david.holmes at oracle.com Thu Oct 18 07:50:05 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 18 Oct 2018 17:50:05 +1000 Subject: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: <26a59905-e267-47d8-90f6-8f0571e5d5ce@default> References: <26a59905-e267-47d8-90f6-8f0571e5d5ce@default> Message-ID: Looks good ! Thanks for doing the backport to 8u. David On 18/10/2018 5:37 PM, Fairoz Matte wrote: > Hi, > > Kindly review the backport of "8211909: JDWP Transport Listener: dt_socket thread crash" to 8u > > code is almost cleanly applied. > > Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8211909 > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/a4d4c609d70c > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025515.html > > Thanks, > Fairoz > From fairoz.matte at oracle.com Thu Oct 18 07:55:35 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Thu, 18 Oct 2018 00:55:35 -0700 (PDT) Subject: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: References: <26a59905-e267-47d8-90f6-8f0571e5d5ce@default> Message-ID: <5dc8dd7d-ceb8-4504-b486-c8f70d4c5474@default> Thanks David, for the review... > -----Original Message----- > From: David Holmes > Sent: Thursday, October 18, 2018 1:20 PM > To: Fairoz Matte ; serviceability- > dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket > thread crash > > Looks good ! Thanks for doing the backport to 8u. > > David > > On 18/10/2018 5:37 PM, Fairoz Matte wrote: > > Hi, > > > > Kindly review the backport of "8211909: JDWP Transport Listener: > dt_socket thread crash" to 8u > > > > code is almost cleanly applied. > > > > Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ > > > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8211909 > > > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/a4d4c609d70c > > > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability- > dev/2018-October/025515.html > > > > Thanks, > > Fairoz > > From gary.adams at oracle.com Thu Oct 18 11:12:26 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 18 Oct 2018 07:12:26 -0400 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: <5BC86A9A.3080602@oracle.com> I'm not certain that we should be printing locations or prompts for events when the vm has not been suspended. This looks OK for the simple test case we are working on here, but in real life there may be a lot more output produced. The user has to select a specific thread before additional commands can be performed in the correct context. e.g. threads, thread n, where, ... So the information is available to the user. It doesn't have to be produced at the time the event is processed. I'm uncomfortable putting too much trust in waiting for the simple prompt, because there is too great a chance of false positives on such a small marker. On 10/17/18, 8: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). > >>> >> > >>> >> 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 gary.adams at oracle.com Thu Oct 18 11:18:27 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 18 Oct 2018 07:18:27 -0400 Subject: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java In-Reply-To: <20212085-0d36-ee53-5fb0-4f2d5e5bf64f@oracle.com> References: <5BC7674F.5070501@oracle.com> <9cb267ea-ad1f-2728-a616-34cc52b08859@oracle.com> <20212085-0d36-ee53-5fb0-4f2d5e5bf64f@oracle.com> Message-ID: <5BC86C03.1050708@oracle.com> So far I have not seen the timeout in my current test runs. Since the test has been on the ProblemList for 1.5 years we would not have seen any timeouts recently. The test does run through a large number of tests that formerly relied on java ee modules, so may have been running longer in the past. My plan is to use this changeset as my first direct submission. If it does start timing out we can added back to the ProblemList and perform some more investigation. On 10/17/18, 7:26 PM, serguei.spitsyn at oracle.com wrote: > 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 gary.adams at oracle.com Thu Oct 18 11:25:59 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 18 Oct 2018 07:25:59 -0400 Subject: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java In-Reply-To: References: <5BC7674F.5070501@oracle.com> Message-ID: <5BC86DC7.2050007@oracle.com> On 10/17/18, 6:46 PM, Alex Menkov wrote: > 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) Done. > > 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. The InstanceFilter test has no problem running stand alone. The RedefineCrossEvent test runs all the other tests in com/sun/jdi dir. The problem is the redefine() that is called for each of the classes encountered. See TestScaffold.java. In jdk9 there was an introduction of jdk.internal classes. In this particular test the jdk.internal.TerminatingThreadLocals class is observed, but the redefine() processing has no compiled bytes to provide if the class were redefined. The test does not expect to process system classes and already includes filters to exclude processing of "java.", "com.", and "sun." prefixed classes. > > --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 gary.adams at oracle.com Thu Oct 18 11:47:19 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 18 Oct 2018 07:47:19 -0400 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: <5BC872C7.3050005@oracle.com> Back in July, I tried to address the jdb output synchronization problem by buffering the output from commands and events. http://cr.openjdk.java.net/~gadams/8169718/webrev.01/ The changes were very invasive and only provided a partial solution. Bottom line for me is the fact that the jdb commands, replies and prompts were never designed as a rigid protocol. They were designed to be interactive with a user and guiding them through a debugging session. The tests that process jdb commands are fragile, because they run much quicker than user interactive speeds, so race conditions can be observed. Also, the reliance on a single standard output stream allows for interspersed output. I think we are pretty close to reaching the current test stabilization goals and this area doesn't really merit additional investment at this time. On 10/17/18, 1:47 PM, 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 gary.adams at oracle.com Thu Oct 18 11:51:30 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 18 Oct 2018 07:51:30 -0400 Subject: Restoring nsk/jvmti/scenarios/hotswap tests from ProblemList.txt In-Reply-To: References: <5BC720C5.4060907@oracle.com> Message-ID: <5BC873C2.201@oracle.com> It's not uncommon to have a couple of build directives before a run request. It made sense to me to combine the build of ExecDriver along with the main test. Then the builds of the redefined newclasses. Followed by the run statement. On 10/17/18, 11:03 AM, JC Beyler wrote: > 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 gary.adams at oracle.com Thu Oct 18 11:55:41 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 18 Oct 2018 07:55:41 -0400 Subject: RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt In-Reply-To: <5BC5CBF9.1060702@oracle.com> References: <5BC4D1EA.8010008@oracle.com> <11799558-9036-b15c-f2a2-0430be1642ef@oracle.com> <5BC5CBF9.1060702@oracle.com> Message-ID: <5BC874BD.4030001@oracle.com> No kill002 failures were observed in the next 1000 testruns. I plan to push the change below and we can see if the exceptions show up in regular CI test runs. On 10/16/18, 7:31 AM, Gary Adams wrote: > 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 gary.adams at oracle.com Thu Oct 18 12:20:30 2018 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 18 Oct 2018 08:20:30 -0400 Subject: Bugs in progress Message-ID: <5BC87A8E.1080904@oracle.com> It would be helpful in tracking bugs we are targetting for the current release, if the bug status was kept up to date. An unassigned or lower priority bug is a good candidate to defer. Sometimes bugs are assigned, but there ends up being resource conflicts to complete the effort. I'd like to ask people to take advantage of the "Start/Stop Working" button in Jira to indicate if they are actively working on code or a review for a particular bug. NEW/OPEN/IN PROGRESS From daniil.x.titov at oracle.com Thu Oct 18 15:53:41 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 18 Oct 2018 08:53:41 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <5BC86A9A.3080602@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> <5BC86A9A.3080602@oracle.com> Message-ID: <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> Hi Gary, Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? Thanks! Best regards, Daniil ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: I'm not certain that we should be printing locations or prompts for events when the vm has not been suspended. This looks OK for the simple test case we are working on here, but in real life there may be a lot more output produced. The user has to select a specific thread before additional commands can be performed in the correct context. e.g. threads, thread n, where, ... So the information is available to the user. It doesn't have to be produced at the time the event is processed. I'm uncomfortable putting too much trust in waiting for the simple prompt, because there is too great a chance of false positives on such a small marker. On 10/17/18, 8: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). > >>> >> > >>> >> 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 16:10:36 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 18 Oct 2018 09:10:36 -0700 Subject: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: <5dc8dd7d-ceb8-4504-b486-c8f70d4c5474@default> References: <26a59905-e267-47d8-90f6-8f0571e5d5ce@default> <5dc8dd7d-ceb8-4504-b486-c8f70d4c5474@default> Message-ID: Hi Fairoz, I compared the original and the port, it looks good to me, Jc On Thu, Oct 18, 2018 at 12:55 AM Fairoz Matte wrote: > Thanks David, for the review... > > > -----Original Message----- > > From: David Holmes > > Sent: Thursday, October 18, 2018 1:20 PM > > To: Fairoz Matte ; serviceability- > > dev at openjdk.java.net > > Subject: Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: > dt_socket > > thread crash > > > > Looks good ! Thanks for doing the backport to 8u. > > > > David > > > > On 18/10/2018 5:37 PM, Fairoz Matte wrote: > > > Hi, > > > > > > Kindly review the backport of "8211909: JDWP Transport Listener: > > dt_socket thread crash" to 8u > > > > > > code is almost cleanly applied. > > > > > > Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ > > > > > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8211909 > > > > > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/a4d4c609d70c > > > > > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability- > > dev/2018-October/025515.html > > > > > > Thanks, > > > Fairoz > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Oct 18 17:27:05 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 18 Oct 2018 10:27:05 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <5BC872C7.3050005@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> <5BC872C7.3050005@oracle.com> Message-ID: <06ed142a-e2bd-3868-ad43-827549abb8c2@oracle.com> +1 On 10/18/18 4:47 AM, Gary Adams wrote: > Back in July, I tried to address the jdb output synchronization problem > by buffering the output from commands and events. > > ? http://cr.openjdk.java.net/~gadams/8169718/webrev.01/ > > The changes were very invasive and only provided a partial solution. > > Bottom line for me is the fact that the jdb commands, replies and prompts > were never designed as a rigid protocol. They were designed to be > interactive > with a user and guiding them through a debugging session. > > The tests that process jdb commands are fragile, because they run > much quicker than user interactive speeds, so race conditions can be > observed. > Also, the reliance on a single standard output stream allows for > interspersed > output. > > I think we are pretty close to reaching the current test stabilization > goals and > this area doesn't really merit additional investment at this time. > > On 10/17/18, 1:47 PM, 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 Thu Oct 18 17:40:00 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 18 Oct 2018 10:40:00 -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> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> Message-ID: +1 --alex On 10/17/2018 18:53, JC Beyler wrote: > 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). > ? ? ? ? >>>? ? ? >> > ? ? ? ? >>>? ? ? >> > 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 > ? ? ? ? >>>? ? ? >> > ? ? ? ? >>>? ? ? > > ? ? ? ? >>> > ? ? ? ? >>> > ? ? ? ? >> > ? ? ? ? >> > > > > > > > > -- > > Thanks, > Jc From hohensee at amazon.com Thu Oct 18 22:18:35 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 18 Oct 2018 22:18:35 +0000 Subject: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> Message-ID: <773340F4-C9A2-4904-A634-1CDE95253E88@amazon.com> Thanks for your review, JC. New webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.03/ I updated the copyright date in memoryService.hpp because I forgot to do so in the patch for https://bugs.openjdk.java.net/browse/JDK-8195115. Thomas asked me to fix in it a separate CR, so I?ve reverted it. Ditto the #include fixes in g1FullGCOopClosures.inline.hpp and g1HeapVerifier.cpp. At one point during development, clang complained about the latter, but no longer does. The ?break? on the same line as the ?}? was in the original version, but I?ve moved it. :) The comment is indeed a bit opaque. I changed it to: // Only check heap pools that support a usage threshold. // This is typically only the old generation space // since the other spaces are expected to get filled up. if (p.getType() == MemoryType.HEAP && p.isUsageThresholdSupported()) { // In all collectors except G1, only the old generation supports a // usage threshold. The G1 legacy mode "G1 Old Gen" also does. In // G1 default mode, both the old space ("G1 Old Space": it's not // really a generation in the non-G1 collector sense) and the // humongous space ("G1 Humongous Space"), support a usage threshold. // So, the following condition is true for all non-G1 old generations, // for the G1 legacy old gen, and for the G1 default humongous space. // It is not true for the G1 default old gen. // // We're allocating humongous objects in this test, so the G1 default // mode "G1 Old Space" occupancy doesn't change, because humongous // objects are allocated in the "G1 Humongous Space". If we allowed // the G1 default mode "G1 Old Space", notification would never // happen because no objects are allocated there. if (!p.getName().equals("G1 Old Space")) { Finally, the G1MonitoringScope constructor now does a better job of selecting a memory manager. Paul From: JC Beyler Date: Wednesday, October 17, 2018 at 4:47 PM To: "Hohensee, Paul" Cc: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" Subject: Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions 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 alexey.menkov at oracle.com Thu Oct 18 22:26:06 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 18 Oct 2018 15:26:06 -0700 Subject: RFR JDK-8212629: [TEST] wrong breakpoint in test/jdk/com/sun/jdi/DeferredStepTest Message-ID: <066601a2-2a07-f445-94d2-c730674228cd@oracle.com> Hi all, please review trivial fix for https://bugs.openjdk.java.net/browse/JDK-8212629 webrev: http://cr.openjdk.java.net/~amenkov/deferredStep_extraBP/webrev/ The fix adds space inside comment to avoid wrong breakpoint parsing (breakpoint lines are marked as "@{id} breakpoint", where {id} is an integer) --alex From chris.plummer at oracle.com Thu Oct 18 22:32:12 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 18 Oct 2018 15:32:12 -0700 Subject: RFR JDK-8212629: [TEST] wrong breakpoint in test/jdk/com/sun/jdi/DeferredStepTest In-Reply-To: <066601a2-2a07-f445-94d2-c730674228cd@oracle.com> References: <066601a2-2a07-f445-94d2-c730674228cd@oracle.com> Message-ID: <0f18c918-36f6-f2b7-a3fc-727387dcf8d2@oracle.com> Looks good. Chris On 10/18/18 3:26 PM, Alex Menkov wrote: > Hi all, > > please review trivial fix for > https://bugs.openjdk.java.net/browse/JDK-8212629 > webrev: > http://cr.openjdk.java.net/~amenkov/deferredStep_extraBP/webrev/ > > The fix adds space inside comment to avoid wrong breakpoint parsing > (breakpoint lines are marked as "@{id} breakpoint", where {id} is an > integer) > > --alex From alexey.menkov at oracle.com Thu Oct 18 22:42:29 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 18 Oct 2018 15:42:29 -0700 Subject: =?UTF-8?Q?=d0=9a=d0=90=d0=9a_JDK-8212665:_com/sun/jdi/DeferredStepT?= =?UTF-8?Q?est.java:_jj1_=28line_57=29_-_unexpected._lastLine=3d52=2c_minLin?= =?UTF-8?Q?e=3d52=2c_maxLine=3d55?= Message-ID: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> Hi all, Please review small test fix for https://bugs.openjdk.java.net/browse/JDK-8212665 webrev: http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/ The test verifies that after "next" command debugger always stops in the position within loops. Each thread has maximum 40 stops (10 iterations, 4 lines each), but with 50 "next" command it's possible that one of the thread exits the loop. The fix increments loops to make 15 iterations, so each thread has more than 50 stops. --alex From mandy.chung at oracle.com Fri Oct 19 01:12:31 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 18 Oct 2018 18:12:31 -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> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> Message-ID: On 10/18/18 12:27 AM, David Holmes wrote: > Hi Dean, > > On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: >> >> You're right, I missed that.? I think the right thing to do is call >> current_thread_exiting while holding the Threads_lock. >> Then we can get rid of the parallel atomic counters.? So, here's one >> more try: >> >> ???? http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ > > Okay that is the simple and obvious solution that doesn't require > split counts. So I have to ask Mandy if she recalls why this approach > wasn't taken 15 years ago when the exit counts were added as part of: > It has been so long.? I think it's likely an oversight. > https://bugs.openjdk.java.net/browse/JDK-4530538 ? > > Does taking the Threads_lock here cost too much and cause a thread > termination bottleneck? If the contention on Threads_lock is not high (that seems to me), it should be okay. ? I'm not close to the VM implementation (lot of changes since then) and I don't have a definitive answer unless I study the code closely.?? You and others have a better judgement on this. AFAICT the change is okay. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 19 01:42:20 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 18 Oct 2018 18:42:20 -0700 Subject: RFR (M) 8212148: Remove remaining NSK_CPP_STUBs Message-ID: Hi all, Here is the final webrev to remove the NSK_CPP_STUB! Please review the end of NSK_CPP_STUB. Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 I've tested the whole vmTestbase since this changed a few shared files. The whole suite passed on my dev machine. Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 19 02:22:08 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 18 Oct 2018 19:22:08 -0700 Subject: =?UTF-8?B?UmU6INCa0JDQmiBKREstODIxMjY2NTogY29tL3N1bi9qZGkvRGVmZXJyZWRTdGVwVGVzdA==?= =?UTF-8?B?LmphdmE6IGpqMSAobGluZSA1NykgLSB1bmV4cGVjdGVkLiBsYXN0TGluZT01MiwgbWluTGluZT01Miwg?= =?UTF-8?B?bWF4TGluZT01NQ==?= In-Reply-To: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> References: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> Message-ID: Hi Alex, Looks good to me. Two nits: - The loops you changed are using ii as the loop counter, any reason we would not just put it to i? - The last comment change, the loop line right under has no spacings, we could extend the webrev a tiny bit and add some spaces? There is no need to resend a webrev for these, regardless if you do them or not :) Jc On Thu, Oct 18, 2018 at 3:43 PM Alex Menkov wrote: > Hi all, > > Please review small test fix for > https://bugs.openjdk.java.net/browse/JDK-8212665 > webrev: > http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/ > > The test verifies that after "next" command debugger always stops in the > position within loops. Each thread has maximum 40 stops (10 iterations, > 4 lines each), but with 50 "next" command it's possible that one of the > thread exits the loop. > The fix increments loops to make 15 iterations, so each thread has more > than 50 stops. > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 19 02:23:16 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 18 Oct 2018 19:23:16 -0700 Subject: RFR JDK-8212629: [TEST] wrong breakpoint in test/jdk/com/sun/jdi/DeferredStepTest In-Reply-To: <0f18c918-36f6-f2b7-a3fc-727387dcf8d2@oracle.com> References: <066601a2-2a07-f445-94d2-c730674228cd@oracle.com> <0f18c918-36f6-f2b7-a3fc-727387dcf8d2@oracle.com> Message-ID: Looks good to me too! Jc On Thu, Oct 18, 2018 at 3:32 PM Chris Plummer wrote: > Looks good. > > Chris > > On 10/18/18 3:26 PM, Alex Menkov wrote: > > Hi all, > > > > please review trivial fix for > > https://bugs.openjdk.java.net/browse/JDK-8212629 > > webrev: > > http://cr.openjdk.java.net/~amenkov/deferredStep_extraBP/webrev/ > > > > The fix adds space inside comment to avoid wrong breakpoint parsing > > (breakpoint lines are marked as "@{id} breakpoint", where {id} is an > > integer) > > > > --alex > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 19 02:45:59 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 18 Oct 2018 19:45:59 -0700 Subject: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: <773340F4-C9A2-4904-A634-1CDE95253E88@amazon.com> References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> <773340F4-C9A2-4904-A634-1CDE95253E88@amazon.com> Message-ID: Hi Paul, Looks much better to me. The other question I have is about the legacy mode. I understand why, from a tool's perspective, having a legacy mode is practical. By doing it this way, we are ensuring we don't break any tools (or at least they can use a flag to be "unbroken") and give time to migrate. This also provides an easier means to backport this fix to older JDKs because now the legacy mode can be used to not break anything and yet provide a means to migrate to a more sane vision of G1 collector definitions. Should the flag perhaps be automatically put in deprecation and then we can mark it as obsolete for JDK13? That would give a limited time for a flag but again I'm not sure this is really done? Or is the plan to keep the flag for a given number of versions, try out these new pools and ensure they provide what we need? Thanks! Jc On Thu, Oct 18, 2018 at 3:18 PM Hohensee, Paul wrote: > Thanks for your review, JC. New webrev: > http://cr.openjdk.java.net/~phh/8196989/webrev.03/ > > > > I updated the copyright date in memoryService.hpp because I forgot to do > so in the patch for https://bugs.openjdk.java.net/browse/JDK-8195115. > Thomas asked me to fix in it a separate CR, so I?ve reverted it. Ditto the > #include fixes in g1FullGCOopClosures.inline.hpp and g1HeapVerifier.cpp. At > one point during development, clang complained about the latter, but no > longer does. > > > > The ?break? on the same line as the ?}? was in the original version, but > I?ve moved it. :) > > > > The comment is indeed a bit opaque. I changed it to: > > > > // Only check heap pools that support a usage threshold. > > // This is typically only the old generation space > > // since the other spaces are expected to get filled up. > > if (p.getType() == MemoryType.HEAP && > > p.isUsageThresholdSupported()) { > > // In all collectors except G1, only the old generation > supports a > > // usage threshold. The G1 legacy mode "G1 Old Gen" also > does. In > > // G1 default mode, both the old space ("G1 Old Space": > it's not > > // really a generation in the non-G1 collector sense) and > the > > // humongous space ("G1 Humongous Space"), support a usage > threshold. > > // So, the following condition is true for all non-G1 old > generations, > > // for the G1 legacy old gen, and for the G1 default > humongous space. > > // It is not true for the G1 default old gen. > > // > > // We're allocating humongous objects in this test, so the > G1 default > > // mode "G1 Old Space" occupancy doesn't change, because > humongous > > // objects are allocated in the "G1 Humongous Space". If > we allowed > > // the G1 default mode "G1 Old Space", notification would > never > > // happen because no objects are allocated there. > > if (!p.getName().equals("G1 Old Space")) { > > > > Finally, the G1MonitoringScope constructor now does a better job of > selecting a memory manager. > > > > Paul > > > > *From: *JC Beyler > *Date: *Wednesday, October 17, 2018 at 4:47 PM > *To: *"Hohensee, Paul" > *Cc: *"hotspot-gc-dev at openjdk.java.net" , > "serviceability-dev at openjdk.java.net" > > *Subject: *Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector > MXBean definitions > > > > 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 > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri Oct 19 07:54:43 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 19 Oct 2018 03:54:43 -0400 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <253448DD-4920-442F-B057-C7F6E8AA95B9@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> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> Message-ID: It's not clear to me if the omitted location information for the non stopping cases was intentional or not. It may be sufficient to know that the event fired without the extra information. I don't think a settable prompt is required either. There are plenty of jdb commands that could be used with the wait for message in tests that need to synchronize at a specific point in the test sequence. I don't think we see wait for simple prompt in any of the tests, because it is not reliable enough. On 10/18/18 11:53 AM, Daniil Titov wrote: > Hi Gary, > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > Thanks! > > Best regards, > Daniil > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > I'm not certain that we should be printing locations or prompts for > events when the vm has not been suspended. This looks OK for the > simple test case we are working on here, but in real life there may > be a lot more output produced. > > The user has to select a specific thread before additional commands > can be performed in the correct context. e.g. threads, thread n, where, ... > So the information is available to the user. It doesn't have to be > produced at the time the event is processed. > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > because there is too great a chance of false positives on such a small > marker. > > > On 10/17/18, 8: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). > > >>> >> > > >>> >> 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 gary.adams at oracle.com Fri Oct 19 09:16:40 2018 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 19 Oct 2018 05:16:40 -0400 Subject: =?UTF-8?Q?Re:_=d0=9a=d0=90=d0=9a_JDK-8212665:_com/sun/jdi/DeferredS?= =?UTF-8?Q?tepTest.java:_jj1_=28line_57=29_-_unexpected._lastLine=3d52=2c_mi?= =?UTF-8?Q?nLine=3d52=2c_maxLine=3d55?= In-Reply-To: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> References: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> Message-ID: Looks good to me. Should the comment "58 steps" be "58 stops"? On 10/18/18 6:42 PM, Alex Menkov wrote: > Hi all, > > Please review small test fix for > https://bugs.openjdk.java.net/browse/JDK-8212665 > webrev: > http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/ > > The test verifies that after "next" command debugger always stops in > the position within loops. Each thread has maximum 40 stops (10 > iterations, 4 lines each), but with 50 "next" command it's possible > that one of the thread exits the loop. > The fix increments loops to make 15 iterations, so each thread has > more than 50 stops. > > --alex From thomas.schatzl at oracle.com Fri Oct 19 13:23:27 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 19 Oct 2018 15:23:27 +0200 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, On Fri, 2018-10-12 at 00:03 +0000, 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. I think the backport is good. Others need to decide whether this change is worth backporting. > 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? CC'ed Joe Darcy as I am not sure either. Thanks, Thomas From hohensee at amazon.com Fri Oct 19 16:05:09 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Oct 2018 16:05:09 +0000 Subject: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> <773340F4-C9A2-4904-A634-1CDE95253E88@amazon.com> Message-ID: <6C5B0F49-6829-4793-BF1A-AD310ABC1B2A@amazon.com> If we put the flag into deprecation, I?d like to keep it for a year so people have time to change their monitoring code (one release to change their code, and another to run with their new code), which would be two releases. I don?t know how the deprecation process works either. Note that if/when this gets backported to jdk8u and/or jdk11u, there?s no mechanism there to obsolete a flag. Discovered an issue with the jdk/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java test, new new webrev at http://cr.openjdk.java.net/~phh/8196989/webrev.04/ Paul From: JC Beyler Date: Thursday, October 18, 2018 at 10:47 PM To: "Hohensee, Paul" Cc: "hotspot-gc-dev at openjdk.java.net" , "serviceability-dev at openjdk.java.net" Subject: Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions Hi Paul, Looks much better to me. The other question I have is about the legacy mode. I understand why, from a tool's perspective, having a legacy mode is practical. By doing it this way, we are ensuring we don't break any tools (or at least they can use a flag to be "unbroken") and give time to migrate. This also provides an easier means to backport this fix to older JDKs because now the legacy mode can be used to not break anything and yet provide a means to migrate to a more sane vision of G1 collector definitions. Should the flag perhaps be automatically put in deprecation and then we can mark it as obsolete for JDK13? That would give a limited time for a flag but again I'm not sure this is really done? Or is the plan to keep the flag for a given number of versions, try out these new pools and ensure they provide what we need? Thanks! Jc On Thu, Oct 18, 2018 at 3:18 PM Hohensee, Paul > wrote: Thanks for your review, JC. New webrev: http://cr.openjdk.java.net/~phh/8196989/webrev.03/ I updated the copyright date in memoryService.hpp because I forgot to do so in the patch for https://bugs.openjdk.java.net/browse/JDK-8195115. Thomas asked me to fix in it a separate CR, so I?ve reverted it. Ditto the #include fixes in g1FullGCOopClosures.inline.hpp and g1HeapVerifier.cpp. At one point during development, clang complained about the latter, but no longer does. The ?break? on the same line as the ?}? was in the original version, but I?ve moved it. :) The comment is indeed a bit opaque. I changed it to: // Only check heap pools that support a usage threshold. // This is typically only the old generation space // since the other spaces are expected to get filled up. if (p.getType() == MemoryType.HEAP && p.isUsageThresholdSupported()) { // In all collectors except G1, only the old generation supports a // usage threshold. The G1 legacy mode "G1 Old Gen" also does. In // G1 default mode, both the old space ("G1 Old Space": it's not // really a generation in the non-G1 collector sense) and the // humongous space ("G1 Humongous Space"), support a usage threshold. // So, the following condition is true for all non-G1 old generations, // for the G1 legacy old gen, and for the G1 default humongous space. // It is not true for the G1 default old gen. // // We're allocating humongous objects in this test, so the G1 default // mode "G1 Old Space" occupancy doesn't change, because humongous // objects are allocated in the "G1 Humongous Space". If we allowed // the G1 default mode "G1 Old Space", notification would never // happen because no objects are allocated there. if (!p.getName().equals("G1 Old Space")) { Finally, the G1MonitoringScope constructor now does a better job of selecting a memory manager. Paul From: JC Beyler > Date: Wednesday, October 17, 2018 at 4:47 PM To: "Hohensee, Paul" > Cc: "hotspot-gc-dev at openjdk.java.net" >, "serviceability-dev at openjdk.java.net" > Subject: Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions 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 -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri Oct 19 16:27:01 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 19 Oct 2018 09:27:01 -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> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> Message-ID: Hi Gary and Chris, Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED --------------------------------------- |---------------------------|-------------------------- SUSPEND_ALL. | yes, e.g. "main[1]" | yes --------------------------------------- |-------------------------- |-------------------------- SUSPEND_EVENT_THREAD | no | no ----------------------------------------|------------------------ --|-------------------------- SUSPEND_ALL. | no | no The fix changes this behavior as the following: SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED --------------------------------------- |----------------------------|-------------------------- SUSPEND_ALL. | yes , e.g. "main[1]" | yes --------------------------------------- |----------------------------|-------------------------- SUSPEND_EVENT_THREAD | yes , ">" | yes ----------------------------------------|--------------------------- |-------------------------- SUSPEND_ALL. | yes, ">". | yes Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... Thanks! Best regards, Daniil ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: It's not clear to me if the omitted location information for the non stopping cases was intentional or not. It may be sufficient to know that the event fired without the extra information. I don't think a settable prompt is required either. There are plenty of jdb commands that could be used with the wait for message in tests that need to synchronize at a specific point in the test sequence. I don't think we see wait for simple prompt in any of the tests, because it is not reliable enough. On 10/18/18 11:53 AM, Daniil Titov wrote: > Hi Gary, > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > Thanks! > > Best regards, > Daniil > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > I'm not certain that we should be printing locations or prompts for > events when the vm has not been suspended. This looks OK for the > simple test case we are working on here, but in real life there may > be a lot more output produced. > > The user has to select a specific thread before additional commands > can be performed in the correct context. e.g. threads, thread n, where, ... > So the information is available to the user. It doesn't have to be > produced at the time the event is processed. > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > because there is too great a chance of false positives on such a small > marker. > > > On 10/17/18, 8: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). > > >>> >> > > >>> >> 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 Fri Oct 19 16:47:23 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 19 Oct 2018 09:47:23 -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> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> Message-ID: <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> Hi Gary and Chris, I am resending the previous email since the table in that email got corrupted. Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: The current behavior. SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed SUSPEND_NONE: Prompt is not printed, location is not printed The fix changes this behavior as the following: SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed SUSPEND_NONE: Prompt is printed ( "> "), location is printed Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... Thanks! --Daniil ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: Hi Gary and Chris, Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED --------------------------------------- |---------------------------|-------------------------- SUSPEND_ALL. | yes, e.g. "main[1]" | yes --------------------------------------- |-------------------------- |-------------------------- SUSPEND_EVENT_THREAD | no | no ----------------------------------------|------------------------ --|-------------------------- SUSPEND_ALL. | no | no The fix changes this behavior as the following: SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED --------------------------------------- |----------------------------|-------------------------- SUSPEND_ALL. | yes , e.g. "main[1]" | yes --------------------------------------- |----------------------------|-------------------------- SUSPEND_EVENT_THREAD | yes , ">" | yes ----------------------------------------|--------------------------- |-------------------------- SUSPEND_ALL. | yes, ">". | yes Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... Thanks! Best regards, Daniil ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: It's not clear to me if the omitted location information for the non stopping cases was intentional or not. It may be sufficient to know that the event fired without the extra information. I don't think a settable prompt is required either. There are plenty of jdb commands that could be used with the wait for message in tests that need to synchronize at a specific point in the test sequence. I don't think we see wait for simple prompt in any of the tests, because it is not reliable enough. On 10/18/18 11:53 AM, Daniil Titov wrote: > Hi Gary, > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > Thanks! > > Best regards, > Daniil > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > I'm not certain that we should be printing locations or prompts for > events when the vm has not been suspended. This looks OK for the > simple test case we are working on here, but in real life there may > be a lot more output produced. > > The user has to select a specific thread before additional commands > can be performed in the correct context. e.g. threads, thread n, where, ... > So the information is available to the user. It doesn't have to be > produced at the time the event is processed. > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > because there is too great a chance of false positives on such a small > marker. > > > On 10/17/18, 8: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). > > >>> >> > > >>> >> 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 Fri Oct 19 16:59:24 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 19 Oct 2018 09:59:24 -0700 Subject: RFR JDK-8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 Message-ID: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> Hi all, jira: https://bugs.openjdk.java.net/browse/JDK-8212151 webrev: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/ The fix updates the test to allow debuggee to select available port instead of using error-prone "getFreePort" approach. --alex From alexey.menkov at oracle.com Fri Oct 19 17:20:15 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 19 Oct 2018 10:20:15 -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> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> Message-ID: <1e22a8c9-ce34-8cc3-95cb-30940096f885@oracle.com> Hi Gary, Just want to remind that jdb is a tool for developers, not a tool for testing. On 10/19/2018 00:54, gary.adams at oracle.com wrote: > It's not clear to me if the omitted location information for the non > stopping > cases was intentional or not. It may be sufficient to know that the > event fired > without the extra information. A single breakpoint is not a common case. Usually you have a number of breakpoints in the debuggee. Note also that currently jdb prints "Breakpoint hit: " only (and colon at the end shows that extra info is expected to be printed). > > I don't think a settable prompt is required either. There are plenty of > jdb commands that > could be used with the wait for message in tests that need to > synchronize at a specific > point in the test sequence. Once again - this is a tool for humans, and show prompt when user input is expected is a good UI practice. --alex > > I don't think we see wait for simple prompt in any of the tests, because it > is not reliable enough. > > On 10/18/18 11:53 AM, Daniil Titov wrote: >> Hi Gary, >> >> Currently when a breakpoint is hit the message "Breakpoint hit:" is >> printed in the debugger output. What we do in this fix we just add >> more information about what exact breakpoint is hit. Do you suggest we >> should not print this line at all if suspend policy is SUSPEND_NONE? >> If so then it is not clear what is the use of the command "stop go >> ..." would be. Regarding waiting for the simple prompt, we could >> change JDbCommand to have a field to store a prompt pattern and use >> this pattern (if it was set) when waiting for command to complete. In >> tests when required we would set the pattern in JdbCommand to more >> complicated one matching a specific output we are expecting at this >> particular step. Do you think it would be a better approach? >> >> Thanks! >> >> Best regards, >> Daniil >> >> >> >> ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: >> >> ???? I'm not certain that we should be printing locations or prompts for >> ???? events when the vm has not been suspended. This looks OK for the >> ???? simple test case we are working on here, but in real life there may >> ???? be a lot more output produced. >> ???? The user has to select a specific thread before additional commands >> ???? can be performed in the correct context. e.g. threads, thread n, >> where, ... >> ???? So the information is available to the user. It doesn't have to be >> ???? produced at the time the event is processed. >> ???? I'm uncomfortable putting too much trust in waiting for the >> simple prompt, >> ???? because there is too great a chance of false positives on such a >> small >> ???? marker. >> ???? On 10/17/18, 8: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). >> ???? >????????? >>>?????? >> >> ???? >????????? >>>?????? >> >> 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 19 17:34:33 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 19 Oct 2018 10:34:33 -0700 Subject: RFR JDK-8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 In-Reply-To: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> References: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> Message-ID: Hi Alex, I remember seeing this same code so went looking for it and saw it in JdbTest.java (you added it here it seems: http://hg.openjdk.java.net/jdk/jdk/rev/083e731da31a). I have two few questions: - Does it make sense to put this code in a helper method? - The code you added in JdbTest.java does not do the adjusted time for 30 it seems, is that normal? Thanks, Jc On Fri, Oct 19, 2018 at 9:59 AM Alex Menkov wrote: > Hi all, > > jira: https://bugs.openjdk.java.net/browse/JDK-8212151 > webrev: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/ > > The fix updates the test to allow debuggee to select available port > instead of using error-prone "getFreePort" approach. > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Fri Oct 19 18:07:44 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 19 Oct 2018 18:07:44 +0000 Subject: RFR (M) 8212148: Remove remaining NSK_CPP_STUBs In-Reply-To: References: Message-ID: <7B89C6C0-A68D-4FA9-8111-CE560A37B923@amazon.com> Looks good. Paul From: serviceability-dev on behalf of JC Beyler Date: Thursday, October 18, 2018 at 9:44 PM To: "serviceability-dev at openjdk.java.net" Subject: RFR (M) 8212148: Remove remaining NSK_CPP_STUBs Hi all, Here is the final webrev to remove the NSK_CPP_STUB! Please review the end of NSK_CPP_STUB. Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 I've tested the whole vmTestbase since this changed a few shared files. The whole suite passed on my dev machine. Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Oct 19 19:02:39 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 19 Oct 2018 12:02:39 -0700 Subject: RFR (M) 8212148: Remove remaining NSK_CPP_STUBs In-Reply-To: <7B89C6C0-A68D-4FA9-8111-CE560A37B923@amazon.com> References: <7B89C6C0-A68D-4FA9-8111-CE560A37B923@amazon.com> Message-ID: <83288d99-9a28-57d4-af7a-a63f8d8d4d9d@oracle.com> +1 --alex On 10/19/2018 11:07, Hohensee, Paul wrote: > Looks good. > > Paul > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Thursday, October 18, 2018 at 9:44 PM > *To: *"serviceability-dev at openjdk.java.net" > > *Subject: *RFR (M) 8212148: Remove remaining NSK_CPP_STUBs > > Hi all, > > Here is the final webrev to remove the NSK_CPP_STUB! Please review the > end of NSK_CPP_STUB. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 > > I've tested the whole vmTestbase since this changed a few shared files. > The whole suite passed on my dev machine. > > Let me know what you think, > > Jc > From alexey.menkov at oracle.com Fri Oct 19 19:36:45 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 19 Oct 2018 12:36:45 -0700 Subject: RFR JDK-8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 In-Reply-To: References: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> Message-ID: Hi Jc, On 10/19/2018 10:34, JC Beyler wrote: > Hi Alex, > > I remember seeing this same code so went looking for it and saw it in > JdbTest.java (you added it here it seems: > http://hg.openjdk.java.net/jdk/jdk/rev/083e731da31a). > > I have two few questions: > ? - Does it make sense to put this code in a helper method? I tried to develop some shared code, but it didn't look good (to me :) I'll rethink this one more time. > ? - The code you added in JdbTest.java does not do the adjusted time > for 30 it seems, is that normal? Actually adjustment is not needed here as ProcessTools.startProcess adjust timeout internally. --alex > > Thanks, > Jc > > On Fri, Oct 19, 2018 at 9:59 AM Alex Menkov > wrote: > > Hi all, > > jira: https://bugs.openjdk.java.net/browse/JDK-8212151 > webrev: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/ > > > The fix updates the test to allow debuggee to select available port > instead of using error-prone "getFreePort" approach. > > --alex > > > > -- > > Thanks, > Jc From chris.plummer at oracle.com Fri Oct 19 19:50:53 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 19 Oct 2018 12:50:53 -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> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> Message-ID: <6fe646e2-0264-de3e-fb91-f7fea51ced6b@oracle.com> I think the line number info is useful. You could have multiple breakpoint messages coming in for different breakpoints and different threads. A message limited to "Breakpoint hit:" is not very useful in that situation. I agree having tests look for a simple prompt is probably not a good idea, but I also think the simple prompt is useful when the breakpoint doesn't suspend all threads and there is no. It's the proper prompt to display in that case. Chris On 10/19/18 12:54 AM, gary.adams at oracle.com wrote: > It's not clear to me if the omitted location information for the non > stopping > cases was intentional or not. It may be sufficient to know that the > event fired > without the extra information. > > I don't think a settable prompt is required either. There are plenty > of jdb commands that > could be used with the wait for message in tests that need to > synchronize at a specific > point in the test sequence. > > I don't think we see wait for simple prompt in any of the tests, > because it > is not reliable enough. > > On 10/18/18 11:53 AM, Daniil Titov wrote: >> Hi Gary, >> >> Currently when a breakpoint is hit the message "Breakpoint hit:" is >> printed in the debugger output. What we do in this fix we just add >> more information about what exact breakpoint is hit. Do you suggest >> we should not print this line at all if suspend policy is >> SUSPEND_NONE? If so then it is not clear what is the use of the >> command "stop go ..." would be. Regarding waiting for the simple >> prompt, we could change JDbCommand to have a field to store a prompt >> pattern and use this pattern (if it was set) when waiting for command >> to complete. In tests when required we would set the pattern in >> JdbCommand to more complicated one matching a specific output we are >> expecting at this particular step. Do you think it would be a better >> approach? >> >> Thanks! >> >> Best regards, >> Daniil >> >> >> >> ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: >> >> ???? I'm not certain that we should be printing locations or prompts for >> ???? events when the vm has not been suspended. This looks OK for the >> ???? simple test case we are working on here, but in real life there may >> ???? be a lot more output produced. >> ???? ???? The user has to select a specific thread before additional >> commands >> ???? can be performed in the correct context. e.g. threads, thread n, >> where, ... >> ???? So the information is available to the user. It doesn't have to be >> ???? produced at the time the event is processed. >> ???? ???? I'm uncomfortable putting too much trust in waiting for the >> simple prompt, >> ???? because there is too great a chance of false positives on such a >> small >> ???? marker. >> ???? ???? ???? On 10/17/18, 8: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). >> ???? >????????? >>>?????? >> >> ???? >????????? >>>?????? >> >> 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 19 19:55:42 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 19 Oct 2018 12:55:42 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <509FDA34-26AA-4B6A-81B6-8F59079C905D@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> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> Message-ID: <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> On 10/19/18 9:47 AM, Daniil Titov wrote: > Hi Gary and Chris, > > I am resending the previous email since the table in that email got corrupted. > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: > > The current behavior. > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed > SUSPEND_NONE: Prompt is not printed, location is not printed > > The fix changes this behavior as the following: > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed > SUSPEND_NONE: Prompt is printed ( "> "), location is printed I'm still in favor of this fix. > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... Maybe we need a version of command() that takes a pattern to look for other than the prompt. Chris > > > Thanks! > --Daniil > > ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: > > Hi Gary and Chris, > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED > --------------------------------------- |---------------------------|-------------------------- > SUSPEND_ALL. | yes, e.g. "main[1]" | yes > --------------------------------------- |-------------------------- |-------------------------- > SUSPEND_EVENT_THREAD | no | no > ----------------------------------------|------------------------ --|-------------------------- > SUSPEND_ALL. | no | no > > > The fix changes this behavior as the following: > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED > --------------------------------------- |----------------------------|-------------------------- > SUSPEND_ALL. | yes , e.g. "main[1]" | yes > --------------------------------------- |----------------------------|-------------------------- > SUSPEND_EVENT_THREAD | yes , ">" | yes > ----------------------------------------|--------------------------- |-------------------------- > SUSPEND_ALL. | yes, ">". | yes > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > > Thanks! > > Best regards, > Daniil > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: > > It's not clear to me if the omitted location information for the non > stopping > cases was intentional or not. It may be sufficient to know that the > event fired > without the extra information. > > I don't think a settable prompt is required either. There are plenty of > jdb commands that > could be used with the wait for message in tests that need to > synchronize at a specific > point in the test sequence. > > I don't think we see wait for simple prompt in any of the tests, because it > is not reliable enough. > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > Hi Gary, > > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > > > I'm not certain that we should be printing locations or prompts for > > events when the vm has not been suspended. This looks OK for the > > simple test case we are working on here, but in real life there may > > be a lot more output produced. > > > > The user has to select a specific thread before additional commands > > can be performed in the correct context. e.g. threads, thread n, where, ... > > So the information is available to the user. It doesn't have to be > > produced at the time the event is processed. > > > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > > because there is too great a chance of false positives on such a small > > marker. > > > > > > On 10/17/18, 8: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). > > > >>> >> > > > >>> >> 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 19 20:47:28 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 19 Oct 2018 13:47:28 -0700 Subject: No subject Message-ID: Hi all, Here is the first of three webrevs to remove spaces around (); I also removed any space after !. When the change modified where future parameters should be indented, I changed those too (such as http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html ) Webrev: https://bugs.openjdk.java.net/browse/JDK-8212535 Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 Let me know what you think, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 19 20:49:22 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 19 Oct 2018 13:49:22 -0700 Subject: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* In-Reply-To: References: Message-ID: Hi all, Sorry about the spam; forgot to add the subject :) Here is the first of three webrevs to remove spaces around (); I also removed any space after !. When the change modified where future parameters should be indented, I changed those too (such as http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html ) Webrev: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 Thanks! Jc On Fri, Oct 19, 2018 at 1:47 PM JC Beyler wrote: > Hi all, > > Here is the first of three webrevs to remove spaces around (); I also > removed any space after !. > > When the change modified where future parameters should be indented, I > changed those too (such as > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html > ) > > Webrev: https://bugs.openjdk.java.net/browse/JDK-8212535 > Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 > > Let me know what you think, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri Oct 19 21:24:25 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 19 Oct 2018 14:24:25 -0700 Subject: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From martinrb at google.com Fri Oct 19 21:43:22 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 19 Oct 2018 14:43:22 -0700 Subject: In-Reply-To: References: Message-ID: Whenever I change only whitespace, I run a variant of hg diff -wbB to more easily see that it's truly only whitespace that has changed. On Fri, Oct 19, 2018 at 1:47 PM, JC Beyler wrote: > Hi all, > > Here is the first of three webrevs to remove spaces around (); I also > removed any space after !. > > When the change modified where future parameters should be indented, I > changed those too (such as http://cr.openjdk.java.net/ > ~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ > IterateOverObjectsReachableFromObject/iterobjreachobj002/ > iterobjreachobj002.cpp.udiff.html) > > Webrev: https://bugs.openjdk.java.net/browse/JDK-8212535 > Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 > > Let me know what you think, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri Oct 19 21:56:44 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 19 Oct 2018 14:56:44 -0700 Subject: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* In-Reply-To: References: Message-ID: Hi Chris, Done! Here is the newest version: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.01/ Thanks for the review! Jc On Fri, Oct 19, 2018 at 2:24 PM Chris Plummer wrote: > Hi JC, > > iterinstcls006.cpp: Can you fix the indentation of the second line. > > 98 NSK_COMPLAIN2("Local storage was corrupted: %s > ,\n\texpected value: %s\n", > 99 (char *)storage_ptr, storage_data); > > iterobjreachobj004.cpp: Can you fix the indentation of the second line. > > 123 NSK_COMPLAIN2("Local storage was corrupted: %s > ,\n\texpected value: %s\n", > 124 (char *)storage_ptr, storage_data); > > iterreachobj002.cpp: You didn't align the arguments like you have > elsewhere. > > 175 stackReferenceCallbackForSecondObjectsIteration(jvmtiHeapRootKind > root_kind, > 176 jlong class_tag, > 177 jlong size, > 178 jlong* tag_ptr, > 179 jlong thread_tag, > 180 jint depth, > 181 jmethodID method, > 182 jint slot, > 183 void* user_data) { > > iterreachobj004.cpp: Can you fix the indentation of the second line. > > 75 NSK_COMPLAIN2("heapRootCallback: Local storage was corrupted: > %s ,\n\texpected value: %s\n", > 76 (char *)storage_ptr, storage_data); > > 119 NSK_COMPLAIN2("stackReferenceCallback: Local storage was > corrupted: %s ,\n\texpected value: %s\n", > 120 (char *)storage_ptr, storage_data); > > 162 NSK_COMPLAIN2("objectReferenceCallback: Local storage was > corrupted: %s ,\n\texpected value: %s\n", > 163 (char *)storage_ptr, storage_data); > > thanks, > > Chris > > On 10/19/18 1:49 PM, JC Beyler wrote: > > Hi all, > > Sorry about the spam; forgot to add the subject :) > > Here is the first of three webrevs to remove spaces around (); I also > removed any space after !. > > When the change modified where future parameters should be indented, I > changed those too (such as > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html > ) > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 > > Thanks! > Jc > > On Fri, Oct 19, 2018 at 1:47 PM JC Beyler wrote: > >> Hi all, >> >> Here is the first of three webrevs to remove spaces around (); I also >> removed any space after !. >> >> When the change modified where future parameters should be indented, I >> changed those too (such as >> http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html >> ) >> >> Webrev: https://bugs.openjdk.java.net/browse/JDK-8212535 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 >> >> Let me know what you think, >> Jc >> > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri Oct 19 22:56:19 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 19 Oct 2018 15:56:19 -0700 Subject: RFR JDK-8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 In-Reply-To: References: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> Message-ID: <523f6153-3376-edda-1786-41cfff3dbdd4@oracle.com> Hi Jc, Updated fix: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev.01/ Moved shared code to new Debuggee class. --alex On 10/19/2018 10:34, JC Beyler wrote: > Hi Alex, > > I remember seeing this same code so went looking for it and saw it in > JdbTest.java (you added it here it seems: > http://hg.openjdk.java.net/jdk/jdk/rev/083e731da31a). > > I have two few questions: > ? - Does it make sense to put this code in a helper method? > ? - The code you added in JdbTest.java does not do the adjusted time > for 30 it seems, is that normal? > > Thanks, > Jc > > On Fri, Oct 19, 2018 at 9:59 AM Alex Menkov > wrote: > > Hi all, > > jira: https://bugs.openjdk.java.net/browse/JDK-8212151 > webrev: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/ > > > The fix updates the test to allow debuggee to select available port > instead of using error-prone "getFreePort" approach. > > --alex > > > > -- > > Thanks, > Jc From daniil.x.titov at oracle.com Fri Oct 19 23:01:20 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 19 Oct 2018 16:01:20 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <1191d89d-b44a-d0b4-b7db-91ec9752ff62@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> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> Message-ID: <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> Hi Chris, Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete. Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 Thanks! --Daniil ?On 10/19/18, 12:55 PM, "Chris Plummer" wrote: On 10/19/18 9:47 AM, Daniil Titov wrote: > Hi Gary and Chris, > > I am resending the previous email since the table in that email got corrupted. > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: > > The current behavior. > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed > SUSPEND_NONE: Prompt is not printed, location is not printed > > The fix changes this behavior as the following: > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed > SUSPEND_NONE: Prompt is printed ( "> "), location is printed I'm still in favor of this fix. > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... Maybe we need a version of command() that takes a pattern to look for other than the prompt. Chris > > > Thanks! > --Daniil > > ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: > > Hi Gary and Chris, > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED > --------------------------------------- |---------------------------|-------------------------- > SUSPEND_ALL. | yes, e.g. "main[1]" | yes > --------------------------------------- |-------------------------- |-------------------------- > SUSPEND_EVENT_THREAD | no | no > ----------------------------------------|------------------------ --|-------------------------- > SUSPEND_ALL. | no | no > > > The fix changes this behavior as the following: > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED > --------------------------------------- |----------------------------|-------------------------- > SUSPEND_ALL. | yes , e.g. "main[1]" | yes > --------------------------------------- |----------------------------|-------------------------- > SUSPEND_EVENT_THREAD | yes , ">" | yes > ----------------------------------------|--------------------------- |-------------------------- > SUSPEND_ALL. | yes, ">". | yes > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > > Thanks! > > Best regards, > Daniil > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: > > It's not clear to me if the omitted location information for the non > stopping > cases was intentional or not. It may be sufficient to know that the > event fired > without the extra information. > > I don't think a settable prompt is required either. There are plenty of > jdb commands that > could be used with the wait for message in tests that need to > synchronize at a specific > point in the test sequence. > > I don't think we see wait for simple prompt in any of the tests, because it > is not reliable enough. > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > Hi Gary, > > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > > > I'm not certain that we should be printing locations or prompts for > > events when the vm has not been suspended. This looks OK for the > > simple test case we are working on here, but in real life there may > > be a lot more output produced. > > > > The user has to select a specific thread before additional commands > > can be performed in the correct context. e.g. threads, thread n, where, ... > > So the information is available to the user. It doesn't have to be > > produced at the time the event is processed. > > > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > > because there is too great a chance of false positives on such a small > > marker. > > > > > > On 10/17/18, 8: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). > > > >>> >> > > > >>> >> 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 Sat Oct 20 02:40:33 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 19 Oct 2018 19:40:33 -0700 Subject: RFR (M) 8212148: Remove remaining NSK_CPP_STUBs In-Reply-To: <83288d99-9a28-57d4-af7a-a63f8d8d4d9d@oracle.com> References: <7B89C6C0-A68D-4FA9-8111-CE560A37B923@amazon.com> <83288d99-9a28-57d4-af7a-a63f8d8d4d9d@oracle.com> Message-ID: Hi all, I pushed the webrev into the submit repo and it failed to build due to internal tests that have references to the NSK_CPP_STUB. Here is the new webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 The only difference is I reverted the changes of the nsk_tools.h file which have the NSK_CPP_STUB. That file now contains the only references to the NSK_CPP_STUB macros until internally there are no references to them. Then we can remove the macros from the header file. Could I please get a new set of LGTM? (I've re-submitted this to the submit repo and am awaiting results) Thanks, Jc On Fri, Oct 19, 2018 at 12:02 PM Alex Menkov wrote: > +1 > > --alex > > On 10/19/2018 11:07, Hohensee, Paul wrote: > > Looks good. > > > > Paul > > > > *From: *serviceability-dev > > > on behalf of JC Beyler > > *Date: *Thursday, October 18, 2018 at 9:44 PM > > *To: *"serviceability-dev at openjdk.java.net" > > > > *Subject: *RFR (M) 8212148: Remove remaining NSK_CPP_STUBs > > > > Hi all, > > > > Here is the final webrev to remove the NSK_CPP_STUB! Please review the > > end of NSK_CPP_STUB. > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.00/ > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 > > > > I've tested the whole vmTestbase since this changed a few shared files. > > The whole suite passed on my dev machine. > > > > Let me know what you think, > > > > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Sat Oct 20 03:28:48 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 19 Oct 2018 20:28:48 -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> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> Message-ID: On 10/18/18 6:12 PM, Mandy Chung wrote: > > > On 10/18/18 12:27 AM, David Holmes wrote: >> Hi Dean, >> >> On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: >>> >>> You're right, I missed that.? I think the right thing to do is call >>> current_thread_exiting while holding the Threads_lock. >>> Then we can get rid of the parallel atomic counters.? So, here's one >>> more try: >>> >>> http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ >> >> Okay that is the simple and obvious solution that doesn't require >> split counts. So I have to ask Mandy if she recalls why this approach >> wasn't taken 15 years ago when the exit counts were added as part of: >> > > It has been so long.? I think it's likely an oversight. >> https://bugs.openjdk.java.net/browse/JDK-4530538 ? >> >> Does taking the Threads_lock here cost too much and cause a thread >> termination bottleneck? > > If the contention on Threads_lock is not high (that seems to me), it > should be okay. ? I'm not close to the VM implementation (lot of > changes since then) and I don't have a definitive answer unless I > study the code closely.?? You and others have a better judgement on this. > > AFAICT the change is okay. > Thanks Mandy.? David, OK to push? dl > Mandy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Sat Oct 20 04:04:59 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 19 Oct 2018 21:04:59 -0700 Subject: RFR (M) 8212148: Remove remaining NSK_CPP_STUBs In-Reply-To: References: <7B89C6C0-A68D-4FA9-8111-CE560A37B923@amazon.com> <83288d99-9a28-57d4-af7a-a63f8d8d4d9d@oracle.com> Message-ID: LGTM -- Igor > On Oct 19, 2018, at 7:40 PM, JC Beyler wrote: > > Hi all, > > I pushed the webrev into the submit repo and it failed to build due to internal tests that have references to the NSK_CPP_STUB. Here is the new webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 > The only difference is I reverted the changes of the nsk_tools.h file which have the NSK_CPP_STUB. That file now contains the only references to the NSK_CPP_STUB macros until internally there are no references to them. Then we can remove the macros from the header file. > > Could I please get a new set of LGTM? > > (I've re-submitted this to the submit repo and am awaiting results) > > Thanks, > Jc > > On Fri, Oct 19, 2018 at 12:02 PM Alex Menkov > wrote: > +1 > > --alex > > On 10/19/2018 11:07, Hohensee, Paul wrote: > > Looks good. > > > > Paul > > > > *From: *serviceability-dev > > > on behalf of JC Beyler > > > *Date: *Thursday, October 18, 2018 at 9:44 PM > > *To: *"serviceability-dev at openjdk.java.net " > > > > > *Subject: *RFR (M) 8212148: Remove remaining NSK_CPP_STUBs > > > > Hi all, > > > > Here is the final webrev to remove the NSK_CPP_STUB! Please review the > > end of NSK_CPP_STUB. > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.00/ > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 > > > > I've tested the whole vmTestbase since this changed a few shared files. > > The whole suite passed on my dev machine. > > > > Let me know what you think, > > > > Jc > > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From fairoz.matte at oracle.com Sat Oct 20 06:08:50 2018 From: fairoz.matte at oracle.com (Fairoz Matte) Date: Fri, 19 Oct 2018 23:08:50 -0700 (PDT) Subject: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash In-Reply-To: References: <26a59905-e267-47d8-90f6-8f0571e5d5ce@default> <5dc8dd7d-ceb8-4504-b486-c8f70d4c5474@default> Message-ID: <932f5391-35c3-4b7d-96db-f69cf3e7e96a@default> Thanks Jc for the review.. ? From: JC Beyler Sent: Thursday, October 18, 2018 9:41 PM To: Fairoz Matte Cc: David Holmes ; serviceability-dev at openjdk.java.net Subject: Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket thread crash ? Hi Fairoz, ? I compared the original and the port, it looks good to me, Jc ? On Thu, Oct 18, 2018 at 12:55 AM Fairoz Matte wrote: Thanks David, for the review... > -----Original Message----- > From: David Holmes > Sent: Thursday, October 18, 2018 1:20 PM > To: Fairoz Matte ; serviceability- > HYPERLINK "mailto:dev at openjdk.java.net"dev at openjdk.java.net > Subject: Re: [8u-backport] RFR: 8211909: JDWP Transport Listener: dt_socket > thread crash > > Looks good ! Thanks for doing the backport to 8u. > > David > > On 18/10/2018 5:37 PM, Fairoz Matte wrote: > > Hi, > > > > Kindly review the backport of? "8211909: JDWP Transport Listener: > dt_socket thread crash" to 8u > > > > code is almost cleanly applied. > > > > Webrev - http://cr.openjdk.java.net/~fmatte/8211909/webrev.00/ > > > > JBS bug - https://bugs.openjdk.java.net/browse/JDK-8211909 > > > > JDK12 changeset - http://hg.openjdk.java.net/jdk/jdk/rev/a4d4c609d70c > > > > Review thread - http://mail.openjdk.java.net/pipermail/serviceability- > dev/2018-October/025515.html > > > > Thanks, > > Fairoz > > ? -- ? Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sven.reimers at gmail.com Sat Oct 20 13:40:07 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Sat, 20 Oct 2018 06:40:07 -0700 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: Hi Mandy, I think the main problem here is that there is no simple was to do CompositeData data = ThreadInfo.toCompositeData(threadInfo) using an official API (there is only ThreadInfo.from(CompositeData..). Do you think it may be a good idea to add such a method? We are using this approach due to performance reasons (details can be found on the original NetBeans issue ). Thanks Sven On Wed, Oct 17, 2018 at 11:48 AM Sven Reimers wrote: > 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 >> >> >> >> -- 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 jcbeyler at google.com Sun Oct 21 03:29:07 2018 From: jcbeyler at google.com (JC Beyler) Date: Sat, 20 Oct 2018 20:29:07 -0700 Subject: RFR JDK-8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 In-Reply-To: <523f6153-3376-edda-1786-41cfff3dbdd4@oracle.com> References: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> <523f6153-3376-edda-1786-41cfff3dbdd4@oracle.com> Message-ID: Hi Alex, It looks really good to me now. The test and JdbTest are now easier to read because we do not have the noise of the debuggee trying to attach. A few nits: - Small nit really is the fact that the javadoc for Debuggee states two usages and JdbTest does not use either :) - You put a few get methods in Debuggee that are seemingly not used anywhere, we could add them later if need be and not have them now? Thanks for this, I think it's really better in the long run to have this in one centralized spot, Jc On Fri, Oct 19, 2018 at 3:56 PM Alex Menkov wrote: > Hi Jc, > > Updated fix: > http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev.01/ > Moved shared code to new Debuggee class. > > --alex > > On 10/19/2018 10:34, JC Beyler wrote: > > Hi Alex, > > > > I remember seeing this same code so went looking for it and saw it in > > JdbTest.java (you added it here it seems: > > http://hg.openjdk.java.net/jdk/jdk/rev/083e731da31a). > > > > I have two few questions: > > - Does it make sense to put this code in a helper method? > > - The code you added in JdbTest.java does not do the adjusted time > > for 30 it seems, is that normal? > > > > Thanks, > > Jc > > > > On Fri, Oct 19, 2018 at 9:59 AM Alex Menkov > > wrote: > > > > Hi all, > > > > jira: https://bugs.openjdk.java.net/browse/JDK-8212151 > > webrev: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/ > > > > > > The fix updates the test to allow debuggee to select available port > > instead of using error-prone "getFreePort" approach. > > > > --alex > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sven.reimers at gmail.com Sun Oct 21 17:50:44 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 21 Oct 2018 10:50:44 -0700 Subject: ThreadInfoCompositeData.compositeType() broken in 11 and later Message-ID: Hi, seems with the change for 8198253: ThreadInfo.from(CompositeData) incorrectly accepts CompositeData with missing JDK 6 attributes ThreadInfoCompositeData.compositeType() was broken. It just returns public static CompositeType compositeType() { return ThreadInfoCompositeTypes.compositeTypes.get(0); } while ThreadInfoCompositeTypes.compositeTypes consists of types.put(CURRENT, ctype); types.put(5, initV5CompositeType(ctype)); types.put(6, initV6CompositeType(ctype)); so that compositeType just returns null, which further down the stack leads to java.lang.reflect.InvocationTargetException 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 org.netbeans.modules.sampler.SamplesOutputStream.toCompositeData(SamplesOutputStream.java:178) at org.netbeans.modules.sampler.SamplesOutputStream.access$400(SamplesOutputStream.java:44) at org.netbeans.modules.sampler.SamplesOutputStream$Sample.writeToStream(SamplesOutputStream.java:285) at org.netbeans.modules.sampler.SamplesOutputStream$Sample.access$300(SamplesOutputStream.java:253) at org.netbeans.modules.sampler.SamplesOutputStream.close(SamplesOutputStream.java:202) at org.netbeans.modules.sampler.Sampler.stopSampling(Sampler.java:231) at org.netbeans.modules.sampler.Sampler.stop(Sampler.java:207) at org.netbeans.core.ui.sampler.SelfSamplerAction$1.doInBackground(SelfSamplerAction.java:90) at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835)xx Caused by: java.lang.IllegalArgumentException: Argument compositeType cannot be null. at java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:206) at java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:118) at java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:130) at java.management/sun.management.ThreadInfoCompositeData.toCompositeData(ThreadInfoCompositeData.java:72) ... 18 more See also latest comments on NETBEANS-1359 . Thanks for investigating. -Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Oct 21 22:07:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Oct 2018 08:07:57 +1000 Subject: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: <6C5B0F49-6829-4793-BF1A-AD310ABC1B2A@amazon.com> References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> <773340F4-C9A2-4904-A634-1CDE95253E88@amazon.com> <6C5B0F49-6829-4793-BF1A-AD310ABC1B2A@amazon.com> Message-ID: <56a2527c-e882-7868-1d3c-ff85aed15ea5@oracle.com> Hi Paul, On 20/10/2018 2:05 AM, Hohensee, Paul wrote: > If we put the flag into deprecation, I?d like to keep it for a year so > people have time to change their monitoring code (one release to change > their code, and another to run with their new code), which would be two > releases. I don?t know how the deprecation process works either. Note > that if/when this gets backported to jdk8u and/or jdk11u, there?s no > mechanism there to obsolete a flag. First the new flag has to be added to the CSR to get approval to be added. It would be quite strange to add a new flag and deprecate it at the same time - not completely out of the question given its legacy compatibility nature, but still odd. So I'd suggest not initially deprecating it but rather file a new bug and CSR to deprecate in 13, obsolete in 14 and expire in 15. That gives you 12 and 13 where the flag is active - though you'll only get a deprecation warning in 13. The obsoletion in 14 will require new bug, but not CSR. The expiration is normally handled en-masse when we bump the JDK release version. For 8u the deprecation process is more manual. You need to add an explicit check and warning in arguments.cpp, then when you're ready to obsolete it add it to the obsolete flag table and remove the deprecation warning. Cheers, David ----- > Discovered an issue with the > jdk/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java > test, new new webrev at > > http://cr.openjdk.java.net/~phh/8196989/webrev.04/ > > > Paul > > *From: *JC Beyler > *Date: *Thursday, October 18, 2018 at 10:47 PM > *To: *"Hohensee, Paul" > *Cc: *"hotspot-gc-dev at openjdk.java.net" > , "serviceability-dev at openjdk.java.net" > > *Subject: *Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector > MXBean definitions > > Hi Paul, > > Looks much better to me. The other question I have is about the legacy > mode. I understand why, from a tool's perspective, having a legacy mode > is practical. By doing it this way, we are ensuring we don't break any > tools (or at least they can use a flag to be "unbroken") and give time > to migrate. This also provides an easier means to backport this fix to > older JDKs because now the legacy mode can be used to not break anything > and yet provide a means to migrate to a more sane vision of G1 collector > definitions. > > Should the flag perhaps be automatically put in deprecation and then we > can mark it as obsolete for JDK13? That would give a limited time for a > flag but again I'm not sure this is really done? > > Or is the plan to keep the flag for a given number of versions, try out > these new pools and ensure they provide what we need? > > Thanks! > > Jc > > On Thu, Oct 18, 2018 at 3:18 PM Hohensee, Paul > wrote: > > Thanks for your review, JC.? New webrev: > http://cr.openjdk.java.net/~phh/8196989/webrev.03/ > > > I updated the copyright date in memoryService.hpp because I forgot > to do so in the patch for > https://bugs.openjdk.java.net/browse/JDK-8195115. Thomas asked me to > fix in it a separate CR, so I?ve reverted it. Ditto the #include > fixes in g1FullGCOopClosures.inline.hpp and g1HeapVerifier.cpp. At > one point during development, clang complained about the latter, but > no longer does. > > The ?break? on the same line as the ?}? was in the original version, > but I?ve moved it. :) > > The comment is indeed a bit opaque. I changed it to: > > ??????? // Only check heap pools that support a usage threshold. > > ??? ????// This is typically only the old generation space > > ??????? // since the other spaces are expected to get filled up. > > ??????? if (p.getType() == MemoryType.HEAP && > > ???????????p.isUsageThresholdSupported()) { > > ???????????????// In all collectors except G1, only the old > generation supports a > > ? ??????????????// usage threshold. The G1 legacy mode "G1 Old Gen" > also does. In > > ? ??????????????// G1 default mode, both the old space ("G1 Old > Space": it's not > > ??? ????????????// really a generation in the non-G1 collector > sense) and the > > ???? ???????????// humongous space ("G1 Humongous Space"), support > a usage threshold. > > ????? ??????????// So, the following condition is true for all > non-G1 old generations, > > ? ??????????????// for the G1 legacy old gen, and for the G1 > default humongous space. > > ???????????????// It is not true for the G1 default old gen. > > ? ??????????????// > > ? ??????????????// We're allocating humongous objects in this test, > so the G1 default > > ?? ?????????????// mode "G1 Old Space" occupancy doesn't change, > because humongous > > ??? ????????????// objects are allocated in the "G1 Humongous > Space". If we allowed > > ???????? ???????// the G1 default mode "G1 Old Space", notification > would never > > ??? ????????????// happen because no objects are allocated there. > > ???????????????if (!p.getName().equals("G1 Old Space")) { > > Finally, the G1MonitoringScope constructor now does a better job of > selecting a memory manager. > > Paul > > *From: *JC Beyler > > *Date: *Wednesday, October 17, 2018 at 4:47 PM > *To: *"Hohensee, Paul" > > *Cc: *"hotspot-gc-dev at openjdk.java.net > " > >, > "serviceability-dev at openjdk.java.net > " > > > *Subject: *Re: 8196989: Revamp G1 JMX MemoryPool and > GarbageCollector MXBean definitions > > 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 3^rd 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 > > > -- > > Thanks, > > Jc > From sven.reimers at gmail.com Mon Oct 22 00:15:22 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 21 Oct 2018 17:15:22 -0700 Subject: ThreadInfoCompositeData.compositeType() broken in 11 and later In-Reply-To: References: Message-ID: Probable fix use Runtime.version().feature() instead of 0: public static CompositeType compositeType() { return ThreadInfoCompositeTypes.compositeTypes.get(Runtime.version().feature()); } Sven On Sun, Oct 21, 2018 at 10:50 AM Sven Reimers wrote: > Hi, > > seems with the change for > > 8198253: ThreadInfo.from(CompositeData) incorrectly accepts CompositeData > with missing JDK 6 attributes > > ThreadInfoCompositeData.compositeType() was broken. It just returns > > public static CompositeType compositeType() { > return ThreadInfoCompositeTypes.compositeTypes.get(0); > } > > while ThreadInfoCompositeTypes.compositeTypes consists of > > types.put(CURRENT, ctype); > types.put(5, initV5CompositeType(ctype)); > types.put(6, initV6CompositeType(ctype)); > > so that compositeType just returns null, which further down the stack > leads to > > java.lang.reflect.InvocationTargetException > 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 > org.netbeans.modules.sampler.SamplesOutputStream.toCompositeData(SamplesOutputStream.java:178) > at > org.netbeans.modules.sampler.SamplesOutputStream.access$400(SamplesOutputStream.java:44) > at > org.netbeans.modules.sampler.SamplesOutputStream$Sample.writeToStream(SamplesOutputStream.java:285) > at > org.netbeans.modules.sampler.SamplesOutputStream$Sample.access$300(SamplesOutputStream.java:253) > at > org.netbeans.modules.sampler.SamplesOutputStream.close(SamplesOutputStream.java:202) > at org.netbeans.modules.sampler.Sampler.stopSampling(Sampler.java:231) > at org.netbeans.modules.sampler.Sampler.stop(Sampler.java:207) > at > org.netbeans.core.ui.sampler.SelfSamplerAction$1.doInBackground(SelfSamplerAction.java:90) > at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:835)xx > Caused by: java.lang.IllegalArgumentException: Argument compositeType > cannot be null. > at > java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:206) > at > java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:118) > at > java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:130) > at > java.management/sun.management.ThreadInfoCompositeData.toCompositeData(ThreadInfoCompositeData.java:72) > ... 18 more > > See also latest comments on NETBEANS-1359 > > . > > Thanks for investigating. > > -Sven > -- 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 sven.reimers at gmail.com Mon Oct 22 00:38:00 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Sun, 21 Oct 2018 17:38:00 -0700 Subject: OpenDataException thrown when constructing CompositeData for ThreadInfo Message-ID: Hi, one more problem to go After applying the proposed fix for the ThreadINfoCompositeData.compositeTyoe() the following exception is raised: java.lang.reflect.InvocationTargetException 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 org.netbeans.modules.sampler.SamplesOutputStream.toCompositeData(SamplesOutputStream.java:178) at org.netbeans.modules.sampler.SamplesOutputStream.access$400(SamplesOutputStream.java:44) at org.netbeans.modules.sampler.SamplesOutputStream$Sample.writeToStream(SamplesOutputStream.java:285) at org.netbeans.modules.sampler.SamplesOutputStream$Sample.access$300(SamplesOutputStream.java:253) at org.netbeans.modules.sampler.SamplesOutputStream.close(SamplesOutputStream.java:202) at org.netbeans.modules.sampler.Sampler.stopSampling(Sampler.java:231) at org.netbeans.modules.sampler.Sampler.stop(Sampler.java:207) at org.netbeans.core.ui.sampler.SelfSamplerAction$1.doInBackground(SelfSamplerAction.java:90) at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:835) Caused by: java.lang.AssertionError: javax.management.openmbean.OpenDataException: Argument value of wrong type for item lockInfo: value false, type javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) at java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:135) at java.management/sun.management.ThreadInfoCompositeData.toCompositeData(ThreadInfoCompositeData.java:72) ... 18 more Caused by: javax.management.openmbean.OpenDataException: Argument value of wrong type for item lockInfo: value false, type javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) at java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:235) at java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:118) at java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:130) ... 19 more Seems the sequence of values is broken for ThreadInfoCompoositeData also. Changing the sequence so that lockInfoData is after isNative fixes the problem: final Object[] threadInfoItemValues = { threadInfo.getThreadId(), threadInfo.getThreadName(), threadInfo.getThreadState().name(), threadInfo.getBlockedTime(), threadInfo.getBlockedCount(), threadInfo.getWaitedTime(), threadInfo.getWaitedCount(), threadInfo.getLockName(), threadInfo.getLockOwnerId(), threadInfo.getLockOwnerName(), stackTraceData, threadInfo.isSuspended(), threadInfo.isInNative(), lockInfoData, lockedMonitorsData, lockedSyncsData, threadInfo.isDaemon(), threadInfo.getPriority(), }; With both of this fixes in place I can finally get the self sampling in NetBeans to work on JDK 12.. (and 11) Thanks for looking into this -Sven -- Sven Reimers * Senior Expert Software Architect * Java Champion * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Mon Oct 22 01:15:18 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 21 Oct 2018 18:15:18 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> Message-ID: Re-sending to the correct mailing lists. Please disregard the other email. http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ https://bugs.openjdk.java.net/browse/JDK-8212200 Hi, CDS has various built-in assumptions that classes loaded by SystemDictionary::resolve_well_known_classes must not be replaced by JVMTI ClassFileLoadHook during run time, including - field offsets computed in JavaClasses::compute_offsets - the layout of the strings objects in the shared strings table The "well-known" classes can be replaced by ClassFileLoadHook only when JvmtiExport::early_class_hook_env() is true. Therefore, the fix is to disable CDS under this condition. I have added a few test cases to try to replace shared classes, including well-known classes and other classes. See comments in ReplaceCriticalClasses.java for details. As a clean up, I also renamed all use of "preloaded" in the source code to "well-known". They refer to the same thing in HotSpot, so there's no need to use 2 terms. Also, The word "preloaded" is ambiguous -- it's unclear when "preloading" happens, and could be confused with what CDS does during archive dump time. > In early e-mails Jiangli wrote: > > We should consider including more classes from the default classlist > in the test. Archived classes loaded during both 'early' phase and after > should be tested. Done. > For future optimizations, we might want to prevent loading additional > shared classes if any of the archived system classes is changed. What's the benefit of doing this? Today we already stop loading a shared class if its super class was not loaded from the archive. Thanks - Ioi From david.holmes at oracle.com Mon Oct 22 01:57:55 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 22 Oct 2018 11:57:55 +1000 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> Message-ID: <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> Hi Ioi, Generally seems okay. On 22/10/2018 11:15 AM, Ioi Lam wrote: > Re-sending to the correct mailing lists. Please disregard the other email. > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ > > https://bugs.openjdk.java.net/browse/JDK-8212200 > > Hi, > > CDS has various built-in assumptions that classes loaded by > SystemDictionary::resolve_well_known_classes must not be replaced > by JVMTI ClassFileLoadHook during run time, including > > - field offsets computed in JavaClasses::compute_offsets > - the layout of the strings objects in the shared strings table > > The "well-known" classes can be replaced by ClassFileLoadHook only > when JvmtiExport::early_class_hook_env() is true. Therefore, the > fix is to disable CDS under this condition. I'm a little unclear why we have to iterate JvmtiEnv list when this has to be checked during JVMTI_PHASE_PRIMORDIAL? > I have added a few test cases to try to replace shared classes, > including well-known classes and other classes. See > comments in ReplaceCriticalClasses.java for details. > > As a clean up, I also renamed all use of "preloaded" in > the source code to "well-known". They refer to the same thing > in HotSpot, so there's no need to use 2 terms. Also, The word > "preloaded" is ambiguous -- it's unclear when "preloading" happens, > and could be confused with what CDS does during archive dump time. A few specific comments: src/hotspot/share/classfile/systemDictionary.cpp + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { + for (int i = 0; ; i++) { + int sid = wk_init_info[i]; + if (sid == 0) { + break; + } I take it a zero value is a guaranteed end-of-list sentinel? + for (int i=FIRST_WKID; i > > In early e-mails Jiangli wrote: > > > > We should consider including more classes from the default classlist > > in the test. Archived classes loaded during both 'early' phase and after > > should be tested. > > Done. > > > > For future optimizations, we might want to prevent loading additional > > shared classes if any of the archived system classes is changed. > > What's the benefit of doing this? Today we already stop loading a shared > class if its super class was not loaded from the archive. > > > Thanks > - Ioi > From jini.george at oracle.com Mon Oct 22 03:58:04 2018 From: jini.george at oracle.com (Jini George) Date: Mon, 22 Oct 2018 09:28:04 +0530 Subject: RFR: (S): JDK-8200613: SA: jstack throws UnmappedAddressException with a CDS core file In-Reply-To: <864997e5-2581-7ac9-44f7-76cc31c9ad93@oracle.com> References: <864997e5-2581-7ac9-44f7-76cc31c9ad93@oracle.com> Message-ID: <60d2e6db-c87b-9658-57cb-b03ca881a624@oracle.com> Gentle reminder! Thanks, - Jini On 10/9/2018 11:31 AM, Jini George wrote: > 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 ioi.lam at oracle.com Mon Oct 22 04:57:30 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 21 Oct 2018 21:57:30 -0700 Subject: RFR: (S): JDK-8200613: SA: jstack throws UnmappedAddressException with a CDS core file In-Reply-To: <60d2e6db-c87b-9658-57cb-b03ca881a624@oracle.com> References: <864997e5-2581-7ac9-44f7-76cc31c9ad93@oracle.com> <60d2e6db-c87b-9658-57cb-b03ca881a624@oracle.com> Message-ID: Hi Jini, Did you see my earlier reply? I might have sent it out during the mail server outage days :-( http://openjdk.5641.n7.nabble.com/RFR-S-JDK-8200613-SA-jstack-throws-UnmappedAddressException-with-a-CDS-core-file-td352681.html#a353026 Here was my reply again: > Hi Jini, > > The changes looks good to me. > > Have you tested this on MacOS? CDS heap support is also enabled on > MacOS. See macros.hpp: > > ???? #if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64) && > !defined(_WINDOWS) > ???? #define INCLUDE_CDS_JAVA_HEAP 1 > > Also, besides CDS, do we know how often other files will be mmaped with > MAP_PRIVATE? Will users get huge core files because CDS is enabled? In > JDK 12, CDS will be enabled by default (see JDK-8202951), so all users > will be affected by the following line: > > ?? if (UseSharedSpaces) { > ???? set_coredump_filter(FILE_BACKED_PVT_BIT); > ?? } > > Maybe you can run an big app such as Eclipse, trigger a core dump, and > compare the size of the core file before/after this change? > > Thanks > > - Ioi Thanks - Ioi On 10/21/18 8:58 PM, Jini George wrote: > Gentle reminder! > > Thanks, > - Jini > > On 10/9/2018 11:31 AM, Jini George wrote: >> 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 ioi.lam at oracle.com Mon Oct 22 05:49:03 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 21 Oct 2018 22:49:03 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> Message-ID: Hi David, Thanks for the review. Updated webrev: http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ More comments below: On 10/21/18 6:57 PM, David Holmes wrote: > Hi Ioi, > > Generally seems okay. > > On 22/10/2018 11:15 AM, Ioi Lam wrote: >> Re-sending to the correct mailing lists. Please disregard the other >> email. >> >> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >> >> https://bugs.openjdk.java.net/browse/JDK-8212200 >> >> Hi, >> >> CDS has various built-in assumptions that classes loaded by >> SystemDictionary::resolve_well_known_classes must not be replaced >> by JVMTI ClassFileLoadHook during run time, including >> >> - field offsets computed in JavaClasses::compute_offsets >> - the layout of the strings objects in the shared strings table >> >> The "well-known" classes can be replaced by ClassFileLoadHook only >> when JvmtiExport::early_class_hook_env() is true. Therefore, the >> fix is to disable CDS under this condition. > > I'm a little unclear why we have to iterate JvmtiEnv list when this > has to be checked during JVMTI_PHASE_PRIMORDIAL? > I think you are asking about this new function? I don't like the name "early_class_hook_env()". Maybe I should change it to "has_early_class_hook_env()"? bool JvmtiExport::early_class_hook_env() { ? JvmtiEnvIterator it; ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { ??? if (env->early_class_hook_env()) { ????? return true; ??? } ? } ? return false; } This function matches condition in the existing code that would call into ClassFileLoadHook: class JvmtiClassFileLoadHookPoster { ?... ? void post_all_envs() { ??? JvmtiEnvIterator it; ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { ? ? ??? .. ??????? post_to_env(env, true); ??? } ? } ... ? void post_to_env(JvmtiEnv* env, bool caching_needed) { ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && !env->early_class_hook_env()) { ????? return; ??? } post_all_envs() is called just before a class is about to be loaded in the JVM. So if *any* env->early_class_hook_env() returns true, there's a chance that it will replace a well-known class.So, as a preventive measure, CDS will be disabled. >> I have added a few test cases to try to replace shared classes, >> including well-known classes and other classes. See >> comments in ReplaceCriticalClasses.java for details. >> >> As a clean up, I also renamed all use of "preloaded" in >> the source code to "well-known". They refer to the same thing >> in HotSpot, so there's no need to use 2 terms. Also, The word >> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >> and could be confused with what CDS does during archive dump time. > > A few specific comments: > > src/hotspot/share/classfile/systemDictionary.cpp > > + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { > +?? for (int i = 0; ; i++) { > +???? int sid = wk_init_info[i]; > +???? if (sid == 0) { > +?????? break; > +???? } > > I take it a zero value is a guaranteed end-of-list sentinel? > Yes. The array is defined just a few lines above: static const short wk_init_info[] = { ? #define WK_KLASS_INIT_INFO(name, symbol) \ ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) ? #undef WK_KLASS_INIT_INFO ? 0 }; Also, class vmSymbols: AllStatic { ? enum SID { ??? NO_SID = 0, ??? .... > + for (int i=FIRST_WKID; i > Style nit: need spaces around = and < > Fixed. > --- > > test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java > > > New file should have current copyright year only. > Fixed. > ?31? * @comment CDS should not be disabled -- these critical classes > will be replaced because JvmtiExport::early_class_hook_env() is true. > > Comment seems contradictory: if we replace critical classes then CDS > should be disabled right?? > Fixed. > I expected to see tests that checked for: > > "CDS is disabled because early JVMTI ClassFileLoadHook is in use." > > in the output. ?? > It would have been easy if jtreg lets you check the output of @run easily. Instead, your innocent suggestion has turned into 150+ lines of new code :-( Maybe "let's write all shell tests in Java" isn't such a great idea after all. Now the test checks that whether CDS is indeed disabled, whether the affected class is loaded from the shared archive, etc. Thanks - Ioi > Thanks, > David > > >> >> ?> In early e-mails Jiangli wrote: >> ?> >> ?> We should consider including more classes from the default classlist >> ?> in the test. Archived classes loaded during both 'early' phase and >> after >> ?> should be tested. >> >> Done. >> >> >> ?> For future optimizations, we might want to prevent loading additional >> ?> shared classes if any of the archived system classes is changed. >> >> What's the benefit of doing this? Today we already stop loading a shared >> class if its super class was not loaded from the archive. >> >> >> Thanks >> - Ioi >> From mandy.chung at oracle.com Mon Oct 22 06:26:33 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 21 Oct 2018 23:26:33 -0700 Subject: OpenDataException thrown when constructing CompositeData for ThreadInfo In-Reply-To: References: Message-ID: <4593ce36-bd87-1162-0932-42b1e1e3ec9a@oracle.com> Hi Sven, Do you have a sample ThreadInfo to reproduce this issue? ? That will be helpful.? JMX monitoring is not impacted as far as I can tell. NB profiling is using this internal API `sun.management.ThreadInfoCompositeData::toCompositeData` which may be unused since JMX supports MXBean. Mandy On 10/21/18 5:38 PM, Sven Reimers wrote: > Hi, > > one more problem to go > > After applying the proposed fix for the > ThreadINfoCompositeData.compositeTyoe() the following exception is raised: > > java.lang.reflect.InvocationTargetException > 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 > org.netbeans.modules.sampler.SamplesOutputStream.toCompositeData(SamplesOutputStream.java:178) > at > org.netbeans.modules.sampler.SamplesOutputStream.access$400(SamplesOutputStream.java:44) > at > org.netbeans.modules.sampler.SamplesOutputStream$Sample.writeToStream(SamplesOutputStream.java:285) > at > org.netbeans.modules.sampler.SamplesOutputStream$Sample.access$300(SamplesOutputStream.java:253) > at > org.netbeans.modules.sampler.SamplesOutputStream.close(SamplesOutputStream.java:202) > at org.netbeans.modules.sampler.Sampler.stopSampling(Sampler.java:231) > at org.netbeans.modules.sampler.Sampler.stop(Sampler.java:207) > at > org.netbeans.core.ui.sampler.SelfSamplerAction$1.doInBackground(SelfSamplerAction.java:90) > at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:835) > Caused by: java.lang.AssertionError: > javax.management.openmbean.OpenDataException: Argument value of wrong > type for item lockInfo: value false, type > javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) > at > java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:135) > at > java.management/sun.management.ThreadInfoCompositeData.toCompositeData(ThreadInfoCompositeData.java:72) > ... 18 more > Caused by: javax.management.openmbean.OpenDataException: Argument > value of wrong type for item lockInfo: value false, type > javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) > at > java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:235) > at > java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:118) > at > java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:130) > ... 19 more > > Seems the sequence of values is broken for ThreadInfoCompoositeData also. > > Changing the sequence so that lockInfoData is after isNative fixes the > problem: > > ? ? ? ?final Object[] threadInfoItemValues = { > ? ? ? ? ? ? threadInfo.getThreadId(), > ? ? ? ? ? ? threadInfo.getThreadName(), > ? ? ? ? ? ? threadInfo.getThreadState().name(), > ? ? ? ? ? ? threadInfo.getBlockedTime(), > ? ? ? ? ? ? threadInfo.getBlockedCount(), > ? ? ? ? ? ? threadInfo.getWaitedTime(), > ? ? ? ? ? ? threadInfo.getWaitedCount(), > ? ? ? ? ? ? threadInfo.getLockName(), > ? ? ? ? ? ? threadInfo.getLockOwnerId(), > ? ? ? ? ? ? threadInfo.getLockOwnerName(), > ? ? ? ? ? ? stackTraceData, > ? ? ? ? ? ? threadInfo.isSuspended(), > ? ? ? ? ? ? threadInfo.isInNative(), > ? ? ? ? ? ? lockInfoData, > ? ? ? ? ? ? lockedMonitorsData, > ? ? ? ? ? ? lockedSyncsData, > ? ? ? ? ? ? threadInfo.isDaemon(), > ? ? ? ? ? ? threadInfo.getPriority(), > ? ? ? ? }; > > With both of this fixes in place I can finally get the self sampling > in NetBeans to work on JDK 12.. (and 11) > > Thanks for looking into this > > -Sven > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Mon Oct 22 11:53:21 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 22 Oct 2018 07:53:21 -0400 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@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> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> Message-ID: <5BCDBA31.6050300@oracle.com> Seems like most people are fine with the breakpoint location for the non stopping cases, so it's OK for me too. Would it make sense for all breakpoint locations to be displayed from BreakpointEvent(). Thanks for making the extra effort to avoid dependency on the simple prompt matching. One thing to check with the large reply matches - make sure the locale translated messages do not interfere with the compiled pattern matching. See MessageOutput.format(). On 10/19/18, 7:01 PM, Daniil Titov wrote: > Hi Chris, > > Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete. > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Thanks! > --Daniil > > > ?On 10/19/18, 12:55 PM, "Chris Plummer" wrote: > > On 10/19/18 9:47 AM, Daniil Titov wrote: > > Hi Gary and Chris, > > > > I am resending the previous email since the table in that email got corrupted. > > > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: > > > > The current behavior. > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed > > SUSPEND_NONE: Prompt is not printed, location is not printed > > > > The fix changes this behavior as the following: > > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed > > SUSPEND_NONE: Prompt is printed ( "> "), location is printed > I'm still in favor of this fix. > > > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > Maybe we need a version of command() that takes a pattern to look for > other than the prompt. > > Chris > > > > > > Thanks! > > --Daniil > > > > ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: > > > > Hi Gary and Chris, > > > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: > > > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED > > --------------------------------------- |---------------------------|-------------------------- > > SUSPEND_ALL. | yes, e.g. "main[1]" | yes > > --------------------------------------- |-------------------------- |-------------------------- > > SUSPEND_EVENT_THREAD | no | no > > ----------------------------------------|------------------------ --|-------------------------- > > SUSPEND_ALL. | no | no > > > > > > The fix changes this behavior as the following: > > > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED > > --------------------------------------- |----------------------------|-------------------------- > > SUSPEND_ALL. | yes , e.g. "main[1]" | yes > > --------------------------------------- |----------------------------|-------------------------- > > SUSPEND_EVENT_THREAD | yes , ">" | yes > > ----------------------------------------|--------------------------- |-------------------------- > > SUSPEND_ALL. | yes, ">". | yes > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: > > > > It's not clear to me if the omitted location information for the non > > stopping > > cases was intentional or not. It may be sufficient to know that the > > event fired > > without the extra information. > > > > I don't think a settable prompt is required either. There are plenty of > > jdb commands that > > could be used with the wait for message in tests that need to > > synchronize at a specific > > point in the test sequence. > > > > I don't think we see wait for simple prompt in any of the tests, because it > > is not reliable enough. > > > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > > Hi Gary, > > > > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > > > > > Thanks! > > > > > > Best regards, > > > Daniil > > > > > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > > > > > I'm not certain that we should be printing locations or prompts for > > > events when the vm has not been suspended. This looks OK for the > > > simple test case we are working on here, but in real life there may > > > be a lot more output produced. > > > > > > The user has to select a specific thread before additional commands > > > can be performed in the correct context. e.g. threads, thread n, where, ... > > > So the information is available to the user. It doesn't have to be > > > produced at the time the event is processed. > > > > > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > > > because there is too great a chance of false positives on such a small > > > marker. > > > > > > > > > On 10/17/18, 8: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). > > > > >>> >> > > > > >>> >> 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 Mon Oct 22 14:53:45 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 22 Oct 2018 07:53:45 -0700 Subject: OpenDataException thrown when constructing CompositeData for ThreadInfo In-Reply-To: <4593ce36-bd87-1162-0932-42b1e1e3ec9a@oracle.com> References: <4593ce36-bd87-1162-0932-42b1e1e3ec9a@oracle.com> Message-ID: Hi Mandy, will try to get a sample to you. Which format do you prefer? Thanks for helping -Sven Mandy Chung schrieb am So., 21. Okt. 2018, 23:26: > Hi Sven, > > Do you have a sample ThreadInfo to reproduce this issue? That will be > helpful. JMX monitoring is not impacted as far as I can tell. NB > profiling is using this internal API > `sun.management.ThreadInfoCompositeData::toCompositeData` which may be > unused since JMX supports MXBean. > > Mandy > > On 10/21/18 5:38 PM, Sven Reimers wrote: > > Hi, > > one more problem to go > > After applying the proposed fix for the > ThreadINfoCompositeData.compositeTyoe() the following exception is raised: > > java.lang.reflect.InvocationTargetException > 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 > org.netbeans.modules.sampler.SamplesOutputStream.toCompositeData(SamplesOutputStream.java:178) > at > org.netbeans.modules.sampler.SamplesOutputStream.access$400(SamplesOutputStream.java:44) > at > org.netbeans.modules.sampler.SamplesOutputStream$Sample.writeToStream(SamplesOutputStream.java:285) > at > org.netbeans.modules.sampler.SamplesOutputStream$Sample.access$300(SamplesOutputStream.java:253) > at > org.netbeans.modules.sampler.SamplesOutputStream.close(SamplesOutputStream.java:202) > at org.netbeans.modules.sampler.Sampler.stopSampling(Sampler.java:231) > at org.netbeans.modules.sampler.Sampler.stop(Sampler.java:207) > at > org.netbeans.core.ui.sampler.SelfSamplerAction$1.doInBackground(SelfSamplerAction.java:90) > at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:835) > Caused by: java.lang.AssertionError: > javax.management.openmbean.OpenDataException: Argument value of wrong type > for item lockInfo: value false, type > javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) > at > java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:135) > at > java.management/sun.management.ThreadInfoCompositeData.toCompositeData(ThreadInfoCompositeData.java:72) > ... 18 more > Caused by: javax.management.openmbean.OpenDataException: Argument value of > wrong type for item lockInfo: value false, type > javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) > at > java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:235) > at > java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:118) > at > java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:130) > ... 19 more > > Seems the sequence of values is broken for ThreadInfoCompoositeData also. > > Changing the sequence so that lockInfoData is after isNative fixes the > problem: > > final Object[] threadInfoItemValues = { > threadInfo.getThreadId(), > threadInfo.getThreadName(), > threadInfo.getThreadState().name(), > threadInfo.getBlockedTime(), > threadInfo.getBlockedCount(), > threadInfo.getWaitedTime(), > threadInfo.getWaitedCount(), > threadInfo.getLockName(), > threadInfo.getLockOwnerId(), > threadInfo.getLockOwnerName(), > stackTraceData, > threadInfo.isSuspended(), > threadInfo.isInNative(), > lockInfoData, > lockedMonitorsData, > lockedSyncsData, > threadInfo.isDaemon(), > threadInfo.getPriority(), > }; > > With both of this fixes in place I can finally get the self sampling in > NetBeans to work on JDK 12.. (and 11) > > Thanks for looking into this > > -Sven > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Mon Oct 22 16:00:00 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 22 Oct 2018 09:00:00 -0700 Subject: OpenDataException thrown when constructing CompositeData for ThreadInfo In-Reply-To: References: <4593ce36-bd87-1162-0932-42b1e1e3ec9a@oracle.com> Message-ID: I assume it's a simple ThreadInfo then a simple text form would work; if not, you can use the format NB use if you have the reader. Mandy On 10/22/18 7:53 AM, Sven Reimers wrote: > Hi Mandy, > will try to get a sample to you. > > Which format do you prefer? > > Thanks for helping > > -Sven > > > Mandy Chung > > schrieb am So., 21. Okt. 2018, 23:26: > > Hi Sven, > > Do you have a sample ThreadInfo to reproduce this issue? ? That > will be helpful.? JMX monitoring is not impacted as far as I can > tell.? NB profiling is using this internal API > `sun.management.ThreadInfoCompositeData::toCompositeData` which > may be unused since JMX supports MXBean. > > Mandy > > On 10/21/18 5:38 PM, Sven Reimers wrote: >> Hi, >> >> one more problem to go >> >> After applying the proposed fix for the >> ThreadINfoCompositeData.compositeTyoe() the following exception >> is raised: >> >> java.lang.reflect.InvocationTargetException >> 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 >> org.netbeans.modules.sampler.SamplesOutputStream.toCompositeData(SamplesOutputStream.java:178) >> at >> org.netbeans.modules.sampler.SamplesOutputStream.access$400(SamplesOutputStream.java:44) >> at >> org.netbeans.modules.sampler.SamplesOutputStream$Sample.writeToStream(SamplesOutputStream.java:285) >> at >> org.netbeans.modules.sampler.SamplesOutputStream$Sample.access$300(SamplesOutputStream.java:253) >> at >> org.netbeans.modules.sampler.SamplesOutputStream.close(SamplesOutputStream.java:202) >> at >> org.netbeans.modules.sampler.Sampler.stopSampling(Sampler.java:231) >> at org.netbeans.modules.sampler.Sampler.stop(Sampler.java:207) >> at >> org.netbeans.core.ui.sampler.SelfSamplerAction$1.doInBackground(SelfSamplerAction.java:90) >> at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304) >> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) >> at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343) >> at >> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) >> at >> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) >> at java.base/java.lang.Thread.run(Thread.java:835) >> Caused by: java.lang.AssertionError: >> javax.management.openmbean.OpenDataException: Argument value of >> wrong type for item lockInfo: value false, type >> javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) >> at >> java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:135) >> at >> java.management/sun.management.ThreadInfoCompositeData.toCompositeData(ThreadInfoCompositeData.java:72) >> ... 18 more >> Caused by: javax.management.openmbean.OpenDataException: Argument >> value of wrong type for item lockInfo: value false, type >> javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) >> at >> java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:235) >> at >> java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:118) >> at >> java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:130) >> ... 19 more >> >> Seems the sequence of values is broken for >> ThreadInfoCompoositeData also. >> >> Changing the sequence so that lockInfoData is after isNative >> fixes the problem: >> >> ? ? ? ?final Object[] threadInfoItemValues = { >> ? ? ? ? ? ? threadInfo.getThreadId(), >> ? ? ? ? ? ? threadInfo.getThreadName(), >> threadInfo.getThreadState().name(), >> ? ? ? ? ? ? threadInfo.getBlockedTime(), >> ? ? ? ? ? ? threadInfo.getBlockedCount(), >> ? ? ? ? ? ? threadInfo.getWaitedTime(), >> ? ? ? ? ? ? threadInfo.getWaitedCount(), >> ? ? ? ? ? ? threadInfo.getLockName(), >> ? ? ? ? ? ? threadInfo.getLockOwnerId(), >> ? ? ? ? ? ? threadInfo.getLockOwnerName(), >> ? ? ? ? ? ? stackTraceData, >> ? ? ? ? ? ? threadInfo.isSuspended(), >> ? ? ? ? ? ? threadInfo.isInNative(), >> ? ? ? ? ? ? lockInfoData, >> ? ? ? ? ? ? lockedMonitorsData, >> ? ? ? ? ? ? lockedSyncsData, >> ? ? ? ? ? ? threadInfo.isDaemon(), >> ? ? ? ? ? ? threadInfo.getPriority(), >> ? ? ? ? }; >> >> With both of this fixes in place I can finally get the self >> sampling in NetBeans to work on JDK 12.. (and 11) >> >> Thanks for looking into this >> >> -Sven >> -- >> Sven Reimers >> >> * Senior Expert Software Architect >> * Java Champion >> * JUG Leader JUG Bodensee: http://www.jug-bodensee.de >> * Duke's Choice Award Winner 2009 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Mon Oct 22 17:25:21 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 22 Oct 2018 10:25:21 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> Message-ID: <48b5854c-1715-b968-4a90-5d243c8994eb@oracle.com> Hi Ioi, Looks good. Please see comments below. - src/hotspot/share/classfile/javaClasses.cpp 4254???? assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, 4255??????????? "Field offsets of well-known classes must be computed in JVMTI_PHASE_PRIMORDIAL or before"); Maybe it is worth adding a function (for example, is_primordial()) in jvmtiEnvBase.hpp, so we can avoid using JVMTI details here? I'm not too sure if the assert is necessary. Why well known-classes' field offsets must be computed in JVMTI_PHASE_PRIMORDIAL or before? Currently they are, however that's because they are used early by the VM. That doesn't directly relate to any JVMTI phase necessarily. With the assert, we are explicitly making a connection to the JVMTI phases. To me, that doesn't seem to be necessary. - src/hotspot/share/classfile/systemDictionary.cpp 2108?? if (UseSharedSpaces) { 2109???? assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, 2110??????????? "All well known classes must be resolved in JVMTI_PHASE_PRIMORDIAL or before"); 2111???? for (int i = FIRST_WKID; i < last; i++) { 2112?????? InstanceKlass* k = _well_known_klasses[i]; 2113?????? assert(k->is_shared(), "must not be replaced by JVMTI class file load hook"); 2114???? } Please include the above block under #ifdef ASSERT. -// preloading is actually performed by resolve_preloaded_classes. +// class resolution is actually performed by resolve_well_known_classes. The original comment is more accurate. Maybe use 'eager loading' if you want to avoid the confusion between 'preloading' and CDS's term? The test looks good. Thanks for filling the gap in this area! Thanks, Jiangli On 10/21/18 10:49 PM, Ioi Lam wrote: > Hi David, > > Thanks for the review. Updated webrev: > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ > > > More comments below: > > > > On 10/21/18 6:57 PM, David Holmes wrote: >> Hi Ioi, >> >> Generally seems okay. >> >> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>> Re-sending to the correct mailing lists. Please disregard the other >>> email. >>> >>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>> >>> Hi, >>> >>> CDS has various built-in assumptions that classes loaded by >>> SystemDictionary::resolve_well_known_classes must not be replaced >>> by JVMTI ClassFileLoadHook during run time, including >>> >>> - field offsets computed in JavaClasses::compute_offsets >>> - the layout of the strings objects in the shared strings table >>> >>> The "well-known" classes can be replaced by ClassFileLoadHook only >>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>> fix is to disable CDS under this condition. >> >> I'm a little unclear why we have to iterate JvmtiEnv list when this >> has to be checked during JVMTI_PHASE_PRIMORDIAL? >> > I think you are asking about this new function? I don't like the name > "early_class_hook_env()". Maybe I should change it to > "has_early_class_hook_env()"? > > > bool JvmtiExport::early_class_hook_env() { > ? JvmtiEnvIterator it; > ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { > ??? if (env->early_class_hook_env()) { > ????? return true; > ??? } > ? } > ? return false; > } > > This function matches condition in the existing code that would call > into ClassFileLoadHook: > > class JvmtiClassFileLoadHookPoster { > ?... > ? void post_all_envs() { > ??? JvmtiEnvIterator it; > ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { > ? ? ??? .. > ??????? post_to_env(env, true); > ??? } > ? } > ... > ? void post_to_env(JvmtiEnv* env, bool caching_needed) { > ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && > !env->early_class_hook_env()) { > ????? return; > ??? } > > > post_all_envs() is called just before a class is about to be loaded in > the JVM. So if *any* env->early_class_hook_env() returns true, there's > a chance that it will replace a well-known class.So, as a preventive > measure, CDS will be disabled. > > > >>> I have added a few test cases to try to replace shared classes, >>> including well-known classes and other classes. See >>> comments in ReplaceCriticalClasses.java for details. >>> >>> As a clean up, I also renamed all use of "preloaded" in >>> the source code to "well-known". They refer to the same thing >>> in HotSpot, so there's no need to use 2 terms. Also, The word >>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>> and could be confused with what CDS does during archive dump time. >> >> A few specific comments: >> >> src/hotspot/share/classfile/systemDictionary.cpp >> >> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >> +?? for (int i = 0; ; i++) { >> +???? int sid = wk_init_info[i]; >> +???? if (sid == 0) { >> +?????? break; >> +???? } >> >> I take it a zero value is a guaranteed end-of-list sentinel? >> > > Yes. The array is defined just a few lines above: > > static const short wk_init_info[] = { > ? #define WK_KLASS_INIT_INFO(name, symbol) \ > ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), > > ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) > ? #undef WK_KLASS_INIT_INFO > ? 0 > }; > > Also, > > class vmSymbols: AllStatic { > ? enum SID { > ??? NO_SID = 0, > ??? .... > > > >> + for (int i=FIRST_WKID; i> >> Style nit: need spaces around = and < >> > > Fixed. > >> --- >> >> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >> >> >> New file should have current copyright year only. >> > Fixed. > >> ?31? * @comment CDS should not be disabled -- these critical classes >> will be replaced because JvmtiExport::early_class_hook_env() is true. >> >> Comment seems contradictory: if we replace critical classes then CDS >> should be disabled right?? >> > Fixed. > >> I expected to see tests that checked for: >> >> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >> >> in the output. ?? >> > > It would have been easy if jtreg lets you check the output of @run > easily. Instead, your innocent suggestion has turned into 150+ lines > of new code :-( Maybe "let's write all shell tests in Java" isn't such > a great idea after all. > > > Now the test checks that whether CDS is indeed disabled, whether the > affected class is loaded from the shared archive, etc. > > Thanks > - Ioi > >> Thanks, >> David >> >> >>> >>> ?> In early e-mails Jiangli wrote: >>> ?> >>> ?> We should consider including more classes from the default classlist >>> ?> in the test. Archived classes loaded during both 'early' phase >>> and after >>> ?> should be tested. >>> >>> Done. >>> >>> >>> ?> For future optimizations, we might want to prevent loading >>> additional >>> ?> shared classes if any of the archived system classes is changed. >>> >>> What's the benefit of doing this? Today we already stop loading a >>> shared >>> class if its super class was not loaded from the archive. >>> >>> >>> Thanks >>> - Ioi >>> > From lois.foltan at oracle.com Mon Oct 22 17:25:53 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 22 Oct 2018 13:25:53 -0400 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> Message-ID: <75b95743-86be-860d-89b8-7e0b5f64ed43@oracle.com> On 10/22/2018 1:49 AM, Ioi Lam wrote: > Hi David, > > Thanks for the review. Updated webrev: > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ > Hi Ioi, Looks good.? A couple of comments: classfile/systemDictionary.cpp - line#1975 - My preference is to declare the variable sid outside the for statement and compare sid == 0 within the for loop conditional. - line#1981 - can you use class_name->fast_compare(symbol) for the equality check? memory/heapShared.cpp - line#422 could be a ResourceMark rm(THREAD); Thanks, Lois > > More comments below: > > > > On 10/21/18 6:57 PM, David Holmes wrote: >> Hi Ioi, >> >> Generally seems okay. >> >> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>> Re-sending to the correct mailing lists. Please disregard the other >>> email. >>> >>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>> >>> Hi, >>> >>> CDS has various built-in assumptions that classes loaded by >>> SystemDictionary::resolve_well_known_classes must not be replaced >>> by JVMTI ClassFileLoadHook during run time, including >>> >>> - field offsets computed in JavaClasses::compute_offsets >>> - the layout of the strings objects in the shared strings table >>> >>> The "well-known" classes can be replaced by ClassFileLoadHook only >>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>> fix is to disable CDS under this condition. >> >> I'm a little unclear why we have to iterate JvmtiEnv list when this >> has to be checked during JVMTI_PHASE_PRIMORDIAL? >> > I think you are asking about this new function? I don't like the name > "early_class_hook_env()". Maybe I should change it to > "has_early_class_hook_env()"? > > > bool JvmtiExport::early_class_hook_env() { > ? JvmtiEnvIterator it; > ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { > ??? if (env->early_class_hook_env()) { > ????? return true; > ??? } > ? } > ? return false; > } > > This function matches condition in the existing code that would call > into ClassFileLoadHook: > > class JvmtiClassFileLoadHookPoster { > ?... > ? void post_all_envs() { > ??? JvmtiEnvIterator it; > ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { > ? ? ??? .. > ??????? post_to_env(env, true); > ??? } > ? } > ... > ? void post_to_env(JvmtiEnv* env, bool caching_needed) { > ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && > !env->early_class_hook_env()) { > ????? return; > ??? } > > > post_all_envs() is called just before a class is about to be loaded in > the JVM. So if *any* env->early_class_hook_env() returns true, there's > a chance that it will replace a well-known class.So, as a preventive > measure, CDS will be disabled. > > > >>> I have added a few test cases to try to replace shared classes, >>> including well-known classes and other classes. See >>> comments in ReplaceCriticalClasses.java for details. >>> >>> As a clean up, I also renamed all use of "preloaded" in >>> the source code to "well-known". They refer to the same thing >>> in HotSpot, so there's no need to use 2 terms. Also, The word >>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>> and could be confused with what CDS does during archive dump time. >> >> A few specific comments: >> >> src/hotspot/share/classfile/systemDictionary.cpp >> >> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >> +?? for (int i = 0; ; i++) { >> +???? int sid = wk_init_info[i]; >> +???? if (sid == 0) { >> +?????? break; >> +???? } >> >> I take it a zero value is a guaranteed end-of-list sentinel? >> > > Yes. The array is defined just a few lines above: > > static const short wk_init_info[] = { > ? #define WK_KLASS_INIT_INFO(name, symbol) \ > ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), > > ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) > ? #undef WK_KLASS_INIT_INFO > ? 0 > }; > > Also, > > class vmSymbols: AllStatic { > ? enum SID { > ??? NO_SID = 0, > ??? .... > > > >> + for (int i=FIRST_WKID; i> >> Style nit: need spaces around = and < >> > > Fixed. > >> --- >> >> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >> >> >> New file should have current copyright year only. >> > Fixed. > >> ?31? * @comment CDS should not be disabled -- these critical classes >> will be replaced because JvmtiExport::early_class_hook_env() is true. >> >> Comment seems contradictory: if we replace critical classes then CDS >> should be disabled right?? >> > Fixed. > >> I expected to see tests that checked for: >> >> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >> >> in the output. ?? >> > > It would have been easy if jtreg lets you check the output of @run > easily. Instead, your innocent suggestion has turned into 150+ lines > of new code :-( Maybe "let's write all shell tests in Java" isn't such > a great idea after all. > > > Now the test checks that whether CDS is indeed disabled, whether the > affected class is loaded from the shared archive, etc. > > Thanks > - Ioi > >> Thanks, >> David >> >> >>> >>> ?> In early e-mails Jiangli wrote: >>> ?> >>> ?> We should consider including more classes from the default classlist >>> ?> in the test. Archived classes loaded during both 'early' phase >>> and after >>> ?> should be tested. >>> >>> Done. >>> >>> >>> ?> For future optimizations, we might want to prevent loading >>> additional >>> ?> shared classes if any of the archived system classes is changed. >>> >>> What's the benefit of doing this? Today we already stop loading a >>> shared >>> class if its super class was not loaded from the archive. >>> >>> >>> Thanks >>> - Ioi >>> > From ioi.lam at oracle.com Mon Oct 22 17:56:49 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 22 Oct 2018 10:56:49 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: <48b5854c-1715-b968-4a90-5d243c8994eb@oracle.com> References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> <48b5854c-1715-b968-4a90-5d243c8994eb@oracle.com> Message-ID: On 10/22/18 10:25 AM, Jiangli Zhou wrote: > Hi Ioi, > > Looks good. Please see comments below. > > - src/hotspot/share/classfile/javaClasses.cpp > > 4254???? assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, > 4255??????????? "Field offsets of well-known classes must be computed > in JVMTI_PHASE_PRIMORDIAL or before"); > > Maybe it is worth adding a function (for example, is_primordial()) in > jvmtiEnvBase.hpp, so we can avoid using JVMTI details here? > I'll add JvmtiExport::is_early_phase(), since the phase can be either JVMTI_PHASE_ONLOAD or? JVMTI_PHASE_PRIMORDIAL. > I'm not too sure if the assert is necessary. Why well known-classes' > field offsets must be computed in JVMTI_PHASE_PRIMORDIAL or before? > Currently they are, however that's because they are used early by the > VM. That doesn't directly relate to any JVMTI phase necessarily. With > the assert, we are explicitly making a connection to the JVMTI phases. > To me, that doesn't seem to be necessary. > JavaClasses::compute_offsets uses many different classes. I would need to check that each of them were in the well-known class list, so that we know the offsets stored in the CDS archive are still valid. However, I couldn't find a single place to make such a check, and it would be much easier to add the above assert, which means any shared class used inside compute_offsets cannot be replaced by JVMTI. How about this: void JavaClasses::compute_offsets() { ? if (UseSharedSpaces) { ??? assert(JvmtiEnvBase::is_early_phase() && !JvmtiExport::has_early_class_hook_env(), ?????????? "JavaClasses::compute_offsets() must be called in early JVMTI phase."); ??? // None of the classes used by the rest of this function can be replaced by ??? // JMVTI ClassFileLoadHook. ??? // We are safe to use the archived offsets, which have already been restored ??? // by JavaClasses::serialize_offsets, without computing the offsets again. ??? return; ? } > - src/hotspot/share/classfile/systemDictionary.cpp > > 2108?? if (UseSharedSpaces) { > 2109???? assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, > 2110??????????? "All well known classes must be resolved in > JVMTI_PHASE_PRIMORDIAL or before"); > 2111???? for (int i = FIRST_WKID; i < last; i++) { > 2112?????? InstanceKlass* k = _well_known_klasses[i]; > 2113?????? assert(k->is_shared(), "must not be replaced by JVMTI class > file load hook"); > 2114???? } > > Please include the above block under #ifdef ASSERT. > OK > -// preloading is actually performed by resolve_preloaded_classes. > +// class resolution is actually performed by resolve_well_known_classes. > > The original comment is more accurate. Maybe use 'eager loading' if > you want to avoid the confusion between 'preloading' and CDS's term? > I can see that "class resolution" could have different meanings, although resolve_well_known_classes does call SystemDictionary::resolve_or_fail, not any the SystemDictionary::load* functions. So using the word "resolve" would be more appropriate. How about changing the comments to the following to avoid ambiguity. #define WK_KLASS_ENUM_NAME(kname)??? kname##_knum // Certain classes, such as java.lang.Object and java.lang.String, // are "well-known", in the sense that no class loader is allowed // to provide a different definition. // // Each well-known class has a short klass name (like object_klass), // and a vmSymbol name (like java_lang_Object). // // The order of these definitions is significant: the classes are // resolved during early VM start-up by resolve_well_known_classes // in this order. Changing the order may require careful restructuring // of the VM start-up sequence. // #define WK_KLASSES_DO(do_klass) ...... Thanks - Ioi > The test looks good. Thanks for filling the gap in this area! > > Thanks, > Jiangli > > On 10/21/18 10:49 PM, Ioi Lam wrote: >> Hi David, >> >> Thanks for the review. Updated webrev: >> >> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ >> >> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ >> >> >> More comments below: >> >> >> >> On 10/21/18 6:57 PM, David Holmes wrote: >>> Hi Ioi, >>> >>> Generally seems okay. >>> >>> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>>> Re-sending to the correct mailing lists. Please disregard the other >>>> email. >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>>> >>>> Hi, >>>> >>>> CDS has various built-in assumptions that classes loaded by >>>> SystemDictionary::resolve_well_known_classes must not be replaced >>>> by JVMTI ClassFileLoadHook during run time, including >>>> >>>> - field offsets computed in JavaClasses::compute_offsets >>>> - the layout of the strings objects in the shared strings table >>>> >>>> The "well-known" classes can be replaced by ClassFileLoadHook only >>>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>>> fix is to disable CDS under this condition. >>> >>> I'm a little unclear why we have to iterate JvmtiEnv list when this >>> has to be checked during JVMTI_PHASE_PRIMORDIAL? >>> >> I think you are asking about this new function? I don't like the name >> "early_class_hook_env()". Maybe I should change it to >> "has_early_class_hook_env()"? >> >> >> bool JvmtiExport::early_class_hook_env() { >> ? JvmtiEnvIterator it; >> ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >> ??? if (env->early_class_hook_env()) { >> ????? return true; >> ??? } >> ? } >> ? return false; >> } >> >> This function matches condition in the existing code that would call >> into ClassFileLoadHook: >> >> class JvmtiClassFileLoadHookPoster { >> ?... >> ? void post_all_envs() { >> ??? JvmtiEnvIterator it; >> ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >> ? ? ??? .. >> ??????? post_to_env(env, true); >> ??? } >> ? } >> ... >> ? void post_to_env(JvmtiEnv* env, bool caching_needed) { >> ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && >> !env->early_class_hook_env()) { >> ????? return; >> ??? } >> >> >> post_all_envs() is called just before a class is about to be loaded >> in the JVM. So if *any* env->early_class_hook_env() returns true, >> there's a chance that it will replace a well-known class.So, as a >> preventive measure, CDS will be disabled. >> >> >> >>>> I have added a few test cases to try to replace shared classes, >>>> including well-known classes and other classes. See >>>> comments in ReplaceCriticalClasses.java for details. >>>> >>>> As a clean up, I also renamed all use of "preloaded" in >>>> the source code to "well-known". They refer to the same thing >>>> in HotSpot, so there's no need to use 2 terms. Also, The word >>>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>>> and could be confused with what CDS does during archive dump time. >>> >>> A few specific comments: >>> >>> src/hotspot/share/classfile/systemDictionary.cpp >>> >>> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >>> +?? for (int i = 0; ; i++) { >>> +???? int sid = wk_init_info[i]; >>> +???? if (sid == 0) { >>> +?????? break; >>> +???? } >>> >>> I take it a zero value is a guaranteed end-of-list sentinel? >>> >> >> Yes. The array is defined just a few lines above: >> >> static const short wk_init_info[] = { >> ? #define WK_KLASS_INIT_INFO(name, symbol) \ >> ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), >> >> ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) >> ? #undef WK_KLASS_INIT_INFO >> ? 0 >> }; >> >> Also, >> >> class vmSymbols: AllStatic { >> ? enum SID { >> ??? NO_SID = 0, >> ??? .... >> >> >> >>> + for (int i=FIRST_WKID; i>> >>> Style nit: need spaces around = and < >>> >> >> Fixed. >> >>> --- >>> >>> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >>> >>> >>> New file should have current copyright year only. >>> >> Fixed. >> >>> ?31? * @comment CDS should not be disabled -- these critical classes >>> will be replaced because JvmtiExport::early_class_hook_env() is true. >>> >>> Comment seems contradictory: if we replace critical classes then CDS >>> should be disabled right?? >>> >> Fixed. >> >>> I expected to see tests that checked for: >>> >>> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >>> >>> in the output. ?? >>> >> >> It would have been easy if jtreg lets you check the output of @run >> easily. Instead, your innocent suggestion has turned into 150+ lines >> of new code :-( Maybe "let's write all shell tests in Java" isn't >> such a great idea after all. >> >> >> Now the test checks that whether CDS is indeed disabled, whether the >> affected class is loaded from the shared archive, etc. >> >> Thanks >> - Ioi >> >>> Thanks, >>> David >>> >>> >>>> >>>> ?> In early e-mails Jiangli wrote: >>>> ?> >>>> ?> We should consider including more classes from the default >>>> classlist >>>> ?> in the test. Archived classes loaded during both 'early' phase >>>> and after >>>> ?> should be tested. >>>> >>>> Done. >>>> >>>> >>>> ?> For future optimizations, we might want to prevent loading >>>> additional >>>> ?> shared classes if any of the archived system classes is changed. >>>> >>>> What's the benefit of doing this? Today we already stop loading a >>>> shared >>>> class if its super class was not loaded from the archive. >>>> >>>> >>>> Thanks >>>> - Ioi >>>> >> > From jiangli.zhou at oracle.com Mon Oct 22 17:57:34 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 22 Oct 2018 10:57:34 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> Message-ID: <7d7399c8-a8e7-789e-641b-8140f5c51816@oracle.com> On 10/21/18 6:15 PM, Ioi Lam wrote: > Re-sending to the correct mailing lists. Please disregard the other > email. > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ > > https://bugs.openjdk.java.net/browse/JDK-8212200 > > Hi, > > CDS has various built-in assumptions that classes loaded by > SystemDictionary::resolve_well_known_classes must not be replaced > by JVMTI ClassFileLoadHook during run time, including > > - field offsets computed in JavaClasses::compute_offsets > - the layout of the strings objects in the shared strings table > > The "well-known" classes can be replaced by ClassFileLoadHook only > when JvmtiExport::early_class_hook_env() is true. Therefore, the > fix is to disable CDS under this condition. > > I have added a few test cases to try to replace shared classes, > including well-known classes and other classes. See > comments in ReplaceCriticalClasses.java for details. > > As a clean up, I also renamed all use of "preloaded" in > the source code to "well-known". They refer to the same thing > in HotSpot, so there's no need to use 2 terms. Also, The word > "preloaded" is ambiguous -- it's unclear when "preloading" happens, > and could be confused with what CDS does during archive dump time. > > > > In early e-mails Jiangli wrote: > > > > We should consider including more classes from the default classlist > > in the test. Archived classes loaded during both 'early' phase and > after > > should be tested. > > Done. > > > > For future optimizations, we might want to prevent loading additional > > shared classes if any of the archived system classes is changed. > > What's the benefit of doing this? Today we already stop loading a shared > class if its super class was not loaded from the archive. This is for pre-resolving more constant pool references (to system classes only). Thanks, Jiangli > > > Thanks > - Ioi > From chris.plummer at oracle.com Mon Oct 22 18:18:31 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 22 Oct 2018 11:18:31 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@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> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> Message-ID: <285b017b-497e-1ad1-6f83-6033ae1fdadb@oracle.com> Hi Daniil, Looks good. thanks, Chris On 10/19/18 4:01 PM, Daniil Titov wrote: > Hi Chris, > > Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete. > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Thanks! > --Daniil > > > ?On 10/19/18, 12:55 PM, "Chris Plummer" wrote: > > On 10/19/18 9:47 AM, Daniil Titov wrote: > > Hi Gary and Chris, > > > > I am resending the previous email since the table in that email got corrupted. > > > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: > > > > The current behavior. > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed > > SUSPEND_NONE: Prompt is not printed, location is not printed > > > > The fix changes this behavior as the following: > > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed > > SUSPEND_NONE: Prompt is printed ( "> "), location is printed > I'm still in favor of this fix. > > > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > Maybe we need a version of command() that takes a pattern to look for > other than the prompt. > > Chris > > > > > > Thanks! > > --Daniil > > > > ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: > > > > Hi Gary and Chris, > > > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: > > > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED > > --------------------------------------- |---------------------------|-------------------------- > > SUSPEND_ALL. | yes, e.g. "main[1]" | yes > > --------------------------------------- |-------------------------- |-------------------------- > > SUSPEND_EVENT_THREAD | no | no > > ----------------------------------------|------------------------ --|-------------------------- > > SUSPEND_ALL. | no | no > > > > > > The fix changes this behavior as the following: > > > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED > > --------------------------------------- |----------------------------|-------------------------- > > SUSPEND_ALL. | yes , e.g. "main[1]" | yes > > --------------------------------------- |----------------------------|-------------------------- > > SUSPEND_EVENT_THREAD | yes , ">" | yes > > ----------------------------------------|--------------------------- |-------------------------- > > SUSPEND_ALL. | yes, ">". | yes > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: > > > > It's not clear to me if the omitted location information for the non > > stopping > > cases was intentional or not. It may be sufficient to know that the > > event fired > > without the extra information. > > > > I don't think a settable prompt is required either. There are plenty of > > jdb commands that > > could be used with the wait for message in tests that need to > > synchronize at a specific > > point in the test sequence. > > > > I don't think we see wait for simple prompt in any of the tests, because it > > is not reliable enough. > > > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > > Hi Gary, > > > > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > > > > > Thanks! > > > > > > Best regards, > > > Daniil > > > > > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > > > > > I'm not certain that we should be printing locations or prompts for > > > events when the vm has not been suspended. This looks OK for the > > > simple test case we are working on here, but in real life there may > > > be a lot more output produced. > > > > > > The user has to select a specific thread before additional commands > > > can be performed in the correct context. e.g. threads, thread n, where, ... > > > So the information is available to the user. It doesn't have to be > > > produced at the time the event is processed. > > > > > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > > > because there is too great a chance of false positives on such a small > > > marker. > > > > > > > > > On 10/17/18, 8: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). > > > > >>> >> > > > > >>> >> 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 Mon Oct 22 18:29:54 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 22 Oct 2018 11:29:54 -0700 Subject: RFR (L) 8212770: Remove spaces before/after () for vmTestbase/jvmti/[s-u] Message-ID: Hi all, Here is the next webrev (second out of 3) to remove the spaces after/before () from vmTestbase. It is straightforward and I generated the webrev with white-space changes showing up of course: Webrev: http://cr.openjdk.java.net/~jcbeyler/8212770/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212770 Could I please get some reviews? Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Oct 22 18:30:49 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 22 Oct 2018 11:30:49 -0700 Subject: RFR (M) 8212771: Remove remaining spaces before/after () for vmTestbase Message-ID: Hi all, Here is the last webrev (3 out of 3) to remove the spaces after/before () from vmTestbase. It is straightforward and I generated the webrev with white-space changes showing up of course: Webrev: http://cr.openjdk.java.net/~jcbeyler/8212771/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212771 Could I please get some reviews? Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Oct 22 19:24:37 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 22 Oct 2018 12:24:37 -0700 Subject: RFR (M) 8212148: Remove remaining NSK_CPP_STUBs In-Reply-To: References: <7B89C6C0-A68D-4FA9-8111-CE560A37B923@amazon.com> <83288d99-9a28-57d4-af7a-a63f8d8d4d9d@oracle.com> Message-ID: Hi all, Igor actually finished cleaning up the closed tests, so I can go ahead and push webrev.00. Thanks all for your reviews and help :) Jc On Fri, Oct 19, 2018 at 9:05 PM Igor Ignatyev wrote: > LGTM > > -- Igor > > On Oct 19, 2018, at 7:40 PM, JC Beyler wrote: > > Hi all, > > I pushed the webrev into the submit repo and it failed to build due to > internal tests that have references to the NSK_CPP_STUB. Here is the new > webrev: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 > > The only difference is I reverted the changes of the nsk_tools.h file > which have the NSK_CPP_STUB. That file now contains the only references to > the NSK_CPP_STUB macros until internally there are no references to them. > Then we can remove the macros from the header file. > > Could I please get a new set of LGTM? > > (I've re-submitted this to the submit repo and am awaiting results) > > Thanks, > Jc > > On Fri, Oct 19, 2018 at 12:02 PM Alex Menkov > wrote: > >> +1 >> >> --alex >> >> On 10/19/2018 11:07, Hohensee, Paul wrote: >> > Looks good. >> > >> > Paul >> > >> > *From: *serviceability-dev >> >> > on behalf of JC Beyler >> > *Date: *Thursday, October 18, 2018 at 9:44 PM >> > *To: *"serviceability-dev at openjdk.java.net" >> > >> > *Subject: *RFR (M) 8212148: Remove remaining NSK_CPP_STUBs >> > >> > Hi all, >> > >> > Here is the final webrev to remove the NSK_CPP_STUB! Please review the >> > end of NSK_CPP_STUB. >> > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212148/webrev.00/ >> > >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8212148 >> > >> > I've tested the whole vmTestbase since this changed a few shared files. >> > The whole suite passed on my dev machine. >> > >> > 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 Mon Oct 22 19:44:35 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 22 Oct 2018 12:44:35 -0700 Subject: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* In-Reply-To: References: Message-ID: <68620d49-36c6-4ca3-a135-9c593cfb0fe2@oracle.com> Hi Jc, Looks good to me. Could you please update nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp : if (!NSK_JVMTI_VERIFY( - )) { + )) { => if (!NSK_JVMTI_VERIFY()) { As all s there are quite short. --alex On 10/19/2018 14:56, JC Beyler wrote: > Hi Chris, > > Done! > > Here is the newest version: > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.01/ > > > Thanks for the review! > Jc > > On Fri, Oct 19, 2018 at 2:24 PM Chris Plummer > wrote: > > Hi JC, > > iterinstcls006.cpp: Can you fix the indentation of the second line. > > ? 98???????????? NSK_COMPLAIN2("Local storage was corrupted: %s > ,\n\texpected value: %s\n", > ? 99????????????????????????????? (char *)storage_ptr, storage_data); > > iterobjreachobj004.cpp: Can you fix the indentation of the second line. > > ?123???????????? NSK_COMPLAIN2("Local storage was corrupted: %s > ,\n\texpected value: %s\n", > ?124????????????????????????????? (char *)storage_ptr, storage_data); > > iterreachobj002.cpp: You didn't align the arguments like you have > elsewhere. > > ?175 > stackReferenceCallbackForSecondObjectsIteration(jvmtiHeapRootKind > root_kind, > ?176????????????????????????? jlong???? class_tag, > ?177????????????????????????? jlong???? size, > ?178????????????????????????? jlong*??? tag_ptr, > ?179????????????????????????? jlong???? thread_tag, > ?180????????????????????????? jint????? depth, > ?181????????????????????????? jmethodID method, > ?182????????????????????????? jint????? slot, > ?183????????????????????????? void*???? user_data) { > > iterreachobj004.cpp: Can you fix the indentation of the second line. > > ? 75???????? NSK_COMPLAIN2("heapRootCallback: Local storage was > corrupted: %s ,\n\texpected value: %s\n", > ? 76????????????????????????? (char *)storage_ptr, storage_data); > > ?119???????? NSK_COMPLAIN2("stackReferenceCallback: Local storage > was corrupted: %s ,\n\texpected value: %s\n", > ?120????????????????????????? (char *)storage_ptr, storage_data); > > ?162???????? NSK_COMPLAIN2("objectReferenceCallback: Local storage > was corrupted: %s ,\n\texpected value: %s\n", > ?163????????????????????????? (char *)storage_ptr, storage_data); > > thanks, > > Chris > > On 10/19/18 1:49 PM, JC Beyler wrote: >> Hi all, >> >> Sorry about the spam; forgot to add the subject :) >> >> Here is the first of three webrevs to remove spaces around (); I >> also removed any space after !. >> >> When the change modified where future parameters should be >> indented, I changed those too (such as >> http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html >> ) >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 >> >> Thanks! >> Jc >> >> On Fri, Oct 19, 2018 at 1:47 PM JC Beyler > > wrote: >> >> Hi all, >> >> Here is the first of three webrevs to remove spaces around (); >> I also removed any space after !. >> >> When the change modified where future parameters should be >> indented, I changed those too (such as >> http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html >> ) >> >> Webrev: https://bugs.openjdk.java.net/browse/JDK-8212535 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 >> >> Let me know what you think, >> Jc >> >> > > > > -- > > Thanks, > Jc From jcbeyler at google.com Mon Oct 22 19:56:12 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 22 Oct 2018 12:56:12 -0700 Subject: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* In-Reply-To: <68620d49-36c6-4ca3-a135-9c593cfb0fe2@oracle.com> References: <68620d49-36c6-4ca3-a135-9c593cfb0fe2@oracle.com> Message-ID: Hi Alex, Done, I left this one: - if (!NSK_JVMTI_VERIFY( - jvmti->IterateOverHeap(JVMTI_HEAP_OBJECT_EITHER, heapObjectCallback, (void *)user_data))) { + if (!NSK_JVMTI_VERIFY(jvmti->IterateOverHeap( + JVMTI_HEAP_OBJECT_EITHER, heapObjectCallback, (void *)user_data))) { The whole length was at 126 characters, it seemed a bit long: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp.udiff.html The new webrev is here: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.02/ Thanks, Jc On Mon, Oct 22, 2018 at 12:44 PM Alex Menkov wrote: > Hi Jc, > > Looks good to me. > Could you please update > nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp : > > if (!NSK_JVMTI_VERIFY( > - )) { > + )) { > > => > if (!NSK_JVMTI_VERIFY()) { > > As all s there are quite short. > > --alex > > > On 10/19/2018 14:56, JC Beyler wrote: > > Hi Chris, > > > > Done! > > > > Here is the newest version: > > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.01/ > > > > > > Thanks for the review! > > Jc > > > > On Fri, Oct 19, 2018 at 2:24 PM Chris Plummer > > wrote: > > > > Hi JC, > > > > iterinstcls006.cpp: Can you fix the indentation of the second line. > > > > 98 NSK_COMPLAIN2("Local storage was corrupted: %s > > ,\n\texpected value: %s\n", > > 99 (char *)storage_ptr, > storage_data); > > > > iterobjreachobj004.cpp: Can you fix the indentation of the second > line. > > > > 123 NSK_COMPLAIN2("Local storage was corrupted: %s > > ,\n\texpected value: %s\n", > > 124 (char *)storage_ptr, > storage_data); > > > > iterreachobj002.cpp: You didn't align the arguments like you have > > elsewhere. > > > > 175 > > stackReferenceCallbackForSecondObjectsIteration(jvmtiHeapRootKind > > root_kind, > > 176 jlong class_tag, > > 177 jlong size, > > 178 jlong* tag_ptr, > > 179 jlong thread_tag, > > 180 jint depth, > > 181 jmethodID method, > > 182 jint slot, > > 183 void* user_data) { > > > > iterreachobj004.cpp: Can you fix the indentation of the second line. > > > > 75 NSK_COMPLAIN2("heapRootCallback: Local storage was > > corrupted: %s ,\n\texpected value: %s\n", > > 76 (char *)storage_ptr, storage_data); > > > > 119 NSK_COMPLAIN2("stackReferenceCallback: Local storage > > was corrupted: %s ,\n\texpected value: %s\n", > > 120 (char *)storage_ptr, storage_data); > > > > 162 NSK_COMPLAIN2("objectReferenceCallback: Local storage > > was corrupted: %s ,\n\texpected value: %s\n", > > 163 (char *)storage_ptr, storage_data); > > > > thanks, > > > > Chris > > > > On 10/19/18 1:49 PM, JC Beyler wrote: > >> Hi all, > >> > >> Sorry about the spam; forgot to add the subject :) > >> > >> Here is the first of three webrevs to remove spaces around (); I > >> also removed any space after !. > >> > >> When the change modified where future parameters should be > >> indented, I changed those too (such as > >> > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html > >> < > http://cr.openjdk.java.net/%7Ejcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html > >) > >> > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/ > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 > >> > >> Thanks! > >> Jc > >> > >> On Fri, Oct 19, 2018 at 1:47 PM JC Beyler >> > wrote: > >> > >> Hi all, > >> > >> Here is the first of three webrevs to remove spaces around (); > >> I also removed any space after !. > >> > >> When the change modified where future parameters should be > >> indented, I changed those too (such as > >> > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html > >> < > http://cr.openjdk.java.net/%7Ejcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html > >) > >> > >> Webrev: https://bugs.openjdk.java.net/browse/JDK-8212535 > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 > >> > >> 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 Mon Oct 22 20:01:06 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 22 Oct 2018 13:01:06 -0700 Subject: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* In-Reply-To: References: <68620d49-36c6-4ca3-a135-9c593cfb0fe2@oracle.com> Message-ID: <4f679831-d757-c293-ce36-fe60a5ca26d3@oracle.com> This line was not changed in webrev.01 :) Anyway looks good. --alex On 10/22/2018 12:56, JC Beyler wrote: > Hi Alex, > > Done, I left this one: > > -? ? ? ? ? ? if (!NSK_JVMTI_VERIFY( > -? ? ? ? ? ? ? ? ? ? jvmti->IterateOverHeap(JVMTI_HEAP_OBJECT_EITHER, > heapObjectCallback, (void *)user_data))) { > +? ? ? ? ? ? if (!NSK_JVMTI_VERIFY(jvmti->IterateOverHeap( > +? ? ? ? ? ? ? ? ? ? JVMTI_HEAP_OBJECT_EITHER, heapObjectCallback, (void > *)user_data))) { > > The whole length was at 126 characters, it seemed a bit long: > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp.udiff.html > > > The new webrev is here: > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.02/ > > > Thanks, > Jc > > On Mon, Oct 22, 2018 at 12:44 PM Alex Menkov > wrote: > > Hi Jc, > > Looks good to me. > Could you please update > nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp : > > ? ? ? if (!NSK_JVMTI_VERIFY( > -? ? ? ? ? ? )) { > +? ? ? ? ? ? )) { > > => > ? ? ? if (!NSK_JVMTI_VERIFY()) { > > As all s there are quite short. > > --alex > > > On 10/19/2018 14:56, JC Beyler wrote: > > Hi Chris, > > > > Done! > > > > Here is the newest version: > > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.01/ > > > > > > > Thanks for the review! > > Jc > > > > On Fri, Oct 19, 2018 at 2:24 PM Chris Plummer > > > >> wrote: > > > >? ? ?Hi JC, > > > >? ? ?iterinstcls006.cpp: Can you fix the indentation of the second > line. > > > >? ? ? ? 98???????????? NSK_COMPLAIN2("Local storage was corrupted: %s > >? ? ?,\n\texpected value: %s\n", > >? ? ? ? 99????????????????????????????? (char *)storage_ptr, > storage_data); > > > >? ? ?iterobjreachobj004.cpp: Can you fix the indentation of the > second line. > > > >? ? ? ?123???????????? NSK_COMPLAIN2("Local storage was corrupted: %s > >? ? ?,\n\texpected value: %s\n", > >? ? ? ?124????????????????????????????? (char *)storage_ptr, > storage_data); > > > >? ? ?iterreachobj002.cpp: You didn't align the arguments like you have > >? ? ?elsewhere. > > > >? ? ? ?175 > >? ? ?stackReferenceCallbackForSecondObjectsIteration(jvmtiHeapRootKind > >? ? ?root_kind, > >? ? ? ?176????????????????????????? jlong???? class_tag, > >? ? ? ?177????????????????????????? jlong???? size, > >? ? ? ?178????????????????????????? jlong*??? tag_ptr, > >? ? ? ?179????????????????????????? jlong???? thread_tag, > >? ? ? ?180????????????????????????? jint????? depth, > >? ? ? ?181????????????????????????? jmethodID method, > >? ? ? ?182????????????????????????? jint????? slot, > >? ? ? ?183????????????????????????? void*???? user_data) { > > > >? ? ?iterreachobj004.cpp: Can you fix the indentation of the > second line. > > > >? ? ? ? 75???????? NSK_COMPLAIN2("heapRootCallback: Local storage was > >? ? ?corrupted: %s ,\n\texpected value: %s\n", > >? ? ? ? 76????????????????????????? (char *)storage_ptr, > storage_data); > > > >? ? ? ?119???????? NSK_COMPLAIN2("stackReferenceCallback: Local > storage > >? ? ?was corrupted: %s ,\n\texpected value: %s\n", > >? ? ? ?120????????????????????????? (char *)storage_ptr, > storage_data); > > > >? ? ? ?162???????? NSK_COMPLAIN2("objectReferenceCallback: Local > storage > >? ? ?was corrupted: %s ,\n\texpected value: %s\n", > >? ? ? ?163????????????????????????? (char *)storage_ptr, > storage_data); > > > >? ? ?thanks, > > > >? ? ?Chris > > > >? ? ?On 10/19/18 1:49 PM, JC Beyler wrote: > >>? ? ?Hi all, > >> > >>? ? ?Sorry about the spam; forgot to add the subject :) > >> > >>? ? ?Here is the first of three webrevs to remove spaces around (); I > >>? ? ?also removed any space after !. > >> > >>? ? ?When the change modified where future parameters should be > >>? ? ?indented, I changed those too (such as > >> > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html > > >> > ?) > >> > >>? ? ?Webrev: > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/ > > >>? ? ? > >>? ? ?Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 > >> > >>? ? ?Thanks! > >>? ? ?Jc > >> > >>? ? ?On Fri, Oct 19, 2018 at 1:47 PM JC Beyler > > >>? ? ?>> > wrote: > >> > >>? ? ? ? ?Hi all, > >> > >>? ? ? ? ?Here is the first of three webrevs to remove spaces > around (); > >>? ? ? ? ?I also removed any space after !. > >> > >>? ? ? ? ?When the change modified where future parameters should be > >>? ? ? ? ?indented, I changed those too (such as > >> > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html > > >> > ?) > >> > >>? ? ? ? ?Webrev: https://bugs.openjdk.java.net/browse/JDK-8212535 > >>? ? ? ? ?Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 > >> > >>? ? ? ? ?Let me know what you think, > >>? ? ? ? ?Jc > >> > >> > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From serguei.spitsyn at oracle.com Mon Oct 22 20:10:35 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Oct 2018 13:10:35 -0700 Subject: =?UTF-8?Q?Re:_=d0=9a=d0=90=d0=9a_JDK-8212665:_com/sun/jdi/DeferredS?= =?UTF-8?Q?tepTest.java:_jj1_=28line_57=29_-_unexpected._lastLine=3d52=2c_mi?= =?UTF-8?Q?nLine=3d52=2c_maxLine=3d55?= In-Reply-To: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> References: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> Message-ID: <9309d2ce-b5b8-ad78-4854-f7a6b6099255@oracle.com> Hi Alex, The fix looks good. +1 for the Jc's suggestion to add spacing to the line: 176 for (int i=0; i<50; i++) { Thanks, Serguei On 10/18/18 15:42, Alex Menkov wrote: > Hi all, > > Please review small test fix for > https://bugs.openjdk.java.net/browse/JDK-8212665 > webrev: > http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/ > > The test verifies that after "next" command debugger always stops in > the position within loops. Each thread has maximum 40 stops (10 > iterations, 4 lines each), but with 50 "next" command it's possible > that one of the thread exits the loop. > The fix increments loops to make 15 iterations, so each thread has > more than 50 stops. > > --alex From alexey.menkov at oracle.com Mon Oct 22 20:37:33 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 22 Oct 2018 13:37:33 -0700 Subject: RFR (L) 8212770: Remove spaces before/after () for vmTestbase/jvmti/[s-u] In-Reply-To: References: Message-ID: LGTM. --alex On 10/22/2018 11:29, JC Beyler wrote: > Hi all, > > Here is the next webrev (second out of 3) to remove the spaces > after/before () from vmTestbase. It is straightforward and I generated > the webrev with white-space changes showing up of course: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212770/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212770 > > Could I please get some reviews? > > Thanks, > Jc From serguei.spitsyn at oracle.com Mon Oct 22 20:58:41 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Oct 2018 13:58:41 -0700 Subject: RFR JDK-8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 In-Reply-To: <523f6153-3376-edda-1786-41cfff3dbdd4@oracle.com> References: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> <523f6153-3376-edda-1786-41cfff3dbdd4@oracle.com> Message-ID: <8455f30d-2682-28e3-85e8-cff090fa13c2@oracle.com> Hi Alex, LGTM. Thanks, Serguei On 10/19/18 15:56, Alex Menkov wrote: > Hi Jc, > > Updated fix: > http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev.01/ > Moved shared code to new Debuggee class. > > --alex > > On 10/19/2018 10:34, JC Beyler wrote: >> Hi Alex, >> >> I remember seeing this same code so went looking for it and saw it in >> JdbTest.java (you added it here it seems: >> http://hg.openjdk.java.net/jdk/jdk/rev/083e731da31a). >> >> I have two few questions: >> ?? - Does it make sense to put this code in a helper method? >> ?? - The code you added in JdbTest.java does not do the adjusted time >> for 30 it seems, is that normal? >> >> Thanks, >> Jc >> >> On Fri, Oct 19, 2018 at 9:59 AM Alex Menkov > > wrote: >> >> ??? Hi all, >> >> ??? jira: https://bugs.openjdk.java.net/browse/JDK-8212151 >> ??? webrev: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/ >> >> >> ??? The fix updates the test to allow debuggee to select available port >> ??? instead of using error-prone "getFreePort" approach. >> >> ??? --alex >> >> >> >> -- >> >> Thanks, >> Jc From serguei.spitsyn at oracle.com Mon Oct 22 21:09:58 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Oct 2018 14:09:58 -0700 Subject: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* In-Reply-To: References: <68620d49-36c6-4ca3-a135-9c593cfb0fe2@oracle.com> Message-ID: <6aac2588-0eb5-bd01-be60-0565474ab5ba@oracle.com> An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Oct 22 21:38:25 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 22 Oct 2018 14:38:25 -0700 Subject: =?UTF-8?Q?Re:_=d0=9a=d0=90=d0=9a_JDK-8212665:_com/sun/jdi/DeferredS?= =?UTF-8?Q?tepTest.java:_jj1_=28line_57=29_-_unexpected._lastLine=3d52=2c_mi?= =?UTF-8?Q?nLine=3d52=2c_maxLine=3d55?= In-Reply-To: <9309d2ce-b5b8-ad78-4854-f7a6b6099255@oracle.com> References: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> <9309d2ce-b5b8-ad78-4854-f7a6b6099255@oracle.com> Message-ID: Hi Jc, Gary, Serguei, Just for the record, updated webrev: http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev.01 (spaces are added, "steps" in the comment is replaced with "stops") --alex On 10/22/2018 13:10, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > The fix looks good. > +1 for the Jc's suggestion to add spacing to the line: > > ?176???????? for (int i=0; i<50; i++) { > > Thanks, > Serguei > > > On 10/18/18 15:42, Alex Menkov wrote: >> Hi all, >> >> Please review small test fix for >> https://bugs.openjdk.java.net/browse/JDK-8212665 >> webrev: >> http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/ >> >> The test verifies that after "next" command debugger always stops in >> the position within loops. Each thread has maximum 40 stops (10 >> iterations, 4 lines each), but with 50 "next" command it's possible >> that one of the thread exits the loop. >> The fix increments loops to make 15 iterations, so each thread has >> more than 50 stops. >> >> --alex > From serguei.spitsyn at oracle.com Mon Oct 22 21:40:00 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Oct 2018 14:40:00 -0700 Subject: =?UTF-8?Q?Re:_=d0=9a=d0=90=d0=9a_JDK-8212665:_com/sun/jdi/DeferredS?= =?UTF-8?Q?tepTest.java:_jj1_=28line_57=29_-_unexpected._lastLine=3d52=2c_mi?= =?UTF-8?Q?nLine=3d52=2c_maxLine=3d55?= In-Reply-To: References: <3880edac-c667-162a-be5a-36227e66df57@oracle.com> <9309d2ce-b5b8-ad78-4854-f7a6b6099255@oracle.com> Message-ID: <89dbf562-0221-5ced-a6c3-544047d41b4c@oracle.com> LGTM Thanks, Serguei On 10/22/18 14:38, Alex Menkov wrote: > Hi Jc, Gary, Serguei, > > Just for the record, updated webrev: > http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev.01 > > (spaces are added, "steps" in the comment is replaced with "stops") > > --alex > > On 10/22/2018 13:10, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> The fix looks good. >> +1 for the Jc's suggestion to add spacing to the line: >> >> ??176???????? for (int i=0; i<50; i++) { >> >> Thanks, >> Serguei >> >> >> On 10/18/18 15:42, Alex Menkov wrote: >>> Hi all, >>> >>> Please review small test fix for >>> https://bugs.openjdk.java.net/browse/JDK-8212665 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/ >>> >>> The test verifies that after "next" command debugger always stops in >>> the position within loops. Each thread has maximum 40 stops (10 >>> iterations, 4 lines each), but with 50 "next" command it's possible >>> that one of the thread exits the loop. >>> The fix increments loops to make 15 iterations, so each thread has >>> more than 50 stops. >>> >>> --alex >> From daniil.x.titov at oracle.com Mon Oct 22 21:54:01 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 22 Oct 2018 14:54:01 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <5BCDBA31.6050300@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> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> <5BCDBA31.6050300@oracle.com> Message-ID: <1CE64BD7-ECD1-43A8-B8C9-CE2EFA31BAEA@oracle.com> Hi Gary, As I see currently multiple tests already use the patterns that in fact are localized messages, e.g. for 'Breakpoint hit' the following tests expect to find this message in the JDB output. grep -rn 'Breakpoint hit' open/test/jdk/com/sun/jdi/ open/test/jdk/com/sun/jdi//JdbMissStep.java:82: .shouldContain("Breakpoint hit"); open/test/jdk/com/sun/jdi//JdbExprTest.java:73: .shouldContain("Breakpoint hit"); open/test/jdk/com/sun/jdi//JdbVarargsTest.java:98: .shouldMatch("Breakpoint hit:.*varString\\(\\)"); open/test/jdk/com/sun/jdi//lib/jdb/Jdb.java:81: public static final String BREAKPOINT_HIT = "Breakpoint hit:"; open/test/jdk/com/sun/jdi//JdbMethodExitTest.java:204: .shouldContain("Breakpoint hit"); open/test/jdk/com/sun/jdi//JdbMethodExitTest.java:303: .shouldContain("Breakpoint hit"); ? If we really want to get rid of this (e.g. for the cases when these tests are run with non-default English locale), I would suggest to file a separate issue for that rather than addressing it in the current fix. Best regards, Daniil On 10/22/18, 4:50 AM, "Gary Adams" wrote: Thanks for making the extra effort to avoid dependency on the simple prompt matching. One thing to check with the large reply matches - make sure the locale translated messages do not interfere with the compiled pattern matching. See MessageOutput.format(). On 10/19/18, 7:01 PM, Daniil Titov wrote: > Hi Chris, > > Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete. > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Thanks! > --Daniil > > > ?On 10/19/18, 12:55 PM, "Chris Plummer" wrote: > > On 10/19/18 9:47 AM, Daniil Titov wrote: > > Hi Gary and Chris, > > > > I am resending the previous email since the table in that email got corrupted. > > > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: > > > > The current behavior. > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed > > SUSPEND_NONE: Prompt is not printed, location is not printed > > > > The fix changes this behavior as the following: > > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed > > SUSPEND_NONE: Prompt is printed ( "> "), location is printed > I'm still in favor of this fix. > > > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > Maybe we need a version of command() that takes a pattern to look for > other than the prompt. > > Chris > > > > > > Thanks! > > --Daniil > > > > ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: > > > > Hi Gary and Chris, > > > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: > > > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED > > --------------------------------------- |---------------------------|-------------------------- > > SUSPEND_ALL. | yes, e.g. "main[1]" | yes > > --------------------------------------- |-------------------------- |-------------------------- > > SUSPEND_EVENT_THREAD | no | no > > ----------------------------------------|------------------------ --|-------------------------- > > SUSPEND_ALL. | no | no > > > > > > The fix changes this behavior as the following: > > > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED > > --------------------------------------- |----------------------------|-------------------------- > > SUSPEND_ALL. | yes , e.g. "main[1]" | yes > > --------------------------------------- |----------------------------|-------------------------- > > SUSPEND_EVENT_THREAD | yes , ">" | yes > > ----------------------------------------|--------------------------- |-------------------------- > > SUSPEND_ALL. | yes, ">". | yes > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: > > > > It's not clear to me if the omitted location information for the non > > stopping > > cases was intentional or not. It may be sufficient to know that the > > event fired > > without the extra information. > > > > I don't think a settable prompt is required either. There are plenty of > > jdb commands that > > could be used with the wait for message in tests that need to > > synchronize at a specific > > point in the test sequence. > > > > I don't think we see wait for simple prompt in any of the tests, because it > > is not reliable enough. > > > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > > Hi Gary, > > > > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > > > > > Thanks! > > > > > > Best regards, > > > Daniil > > > > > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > > > > > I'm not certain that we should be printing locations or prompts for > > > events when the vm has not been suspended. This looks OK for the > > > simple test case we are working on here, but in real life there may > > > be a lot more output produced. > > > > > > The user has to select a specific thread before additional commands > > > can be performed in the correct context. e.g. threads, thread n, where, ... > > > So the information is available to the user. It doesn't have to be > > > produced at the time the event is processed. > > > > > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > > > because there is too great a chance of false positives on such a small > > > marker. > > > > > > > > > On 10/17/18, 8: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). > > > > >>> >> > > > > >>> >> 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 Mon Oct 22 21:57:12 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Oct 2018 14:57:12 -0700 Subject: RFR (M) 8212771: Remove remaining spaces before/after () for vmTestbase In-Reply-To: References: Message-ID: <39560b3f-41b5-bd64-4acf-7e81cf196953@oracle.com> An HTML attachment was scrubbed... URL: From jiangli.zhou at oracle.com Mon Oct 22 22:06:06 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 22 Oct 2018 15:06:06 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> <48b5854c-1715-b968-4a90-5d243c8994eb@oracle.com> Message-ID: <68e6b46e-6a7c-0343-d956-f3e5da3d6bcd@oracle.com> On 10/22/18 10:56 AM, Ioi Lam wrote: > > > On 10/22/18 10:25 AM, Jiangli Zhou wrote: >> Hi Ioi, >> >> Looks good. Please see comments below. >> >> - src/hotspot/share/classfile/javaClasses.cpp >> >> 4254???? assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, >> 4255??????????? "Field offsets of well-known classes must be computed >> in JVMTI_PHASE_PRIMORDIAL or before"); >> >> Maybe it is worth adding a function (for example, is_primordial()) in >> jvmtiEnvBase.hpp, so we can avoid using JVMTI details here? >> > I'll add JvmtiExport::is_early_phase(), since the phase can be either > JVMTI_PHASE_ONLOAD or? JVMTI_PHASE_PRIMORDIAL. > >> I'm not too sure if the assert is necessary. Why well known-classes' >> field offsets must be computed in JVMTI_PHASE_PRIMORDIAL or before? >> Currently they are, however that's because they are used early by the >> VM. That doesn't directly relate to any JVMTI phase necessarily. With >> the assert, we are explicitly making a connection to the JVMTI >> phases. To me, that doesn't seem to be necessary. >> > > JavaClasses::compute_offsets uses many different classes. I would need > to check that each of them were in the well-known class list, so that > we know the offsets stored in the CDS archive are still valid. > However, I couldn't find a single place to make such a check, and it > would be much easier to add the above assert, which means any shared > class used inside compute_offsets cannot be replaced by JVMTI. > > How about this: > > void JavaClasses::compute_offsets() { > ? if (UseSharedSpaces) { > ??? assert(JvmtiEnvBase::is_early_phase() && > !JvmtiExport::has_early_class_hook_env(), > ?????????? "JavaClasses::compute_offsets() must be called in early > JVMTI phase."); > ??? // None of the classes used by the rest of this function can be > replaced by > ??? // JMVTI ClassFileLoadHook. > ??? // We are safe to use the archived offsets, which have already > been restored > ??? // by JavaClasses::serialize_offsets, without computing the > offsets again. > ??? return; > ? } You could do assert(k->is_shared() || !UseSharedSpaces) in the DO_SERIALIZE_OFFSETS macro to make sure the expected shared classes are used when UseSharedSpaces is enabled during loading the archived field offsets. The extra !UseSharedSpaces here is because serialize_offsets() function is used for both dump time and runtime. It could be removed because the 'is_shared' flag is probably already set when we writing out data at dump time, but please double check that. #define DO_SERIALIZE_OFFSETS(k) k::serialize_offsets(soc); If JvmtiExport::early_class_hook_env is requested by a JVMTI agent, UseSharedSpaces should already be disabled at runtime, otherwise a shared class should be used in this case. > > >> - src/hotspot/share/classfile/systemDictionary.cpp >> >> 2108?? if (UseSharedSpaces) { >> 2109???? assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, >> 2110??????????? "All well known classes must be resolved in >> JVMTI_PHASE_PRIMORDIAL or before"); >> 2111???? for (int i = FIRST_WKID; i < last; i++) { >> 2112?????? InstanceKlass* k = _well_known_klasses[i]; >> 2113?????? assert(k->is_shared(), "must not be replaced by JVMTI >> class file load hook"); >> 2114???? } >> >> Please include the above block under #ifdef ASSERT. >> > OK > >> -// preloading is actually performed by resolve_preloaded_classes. >> +// class resolution is actually performed by >> resolve_well_known_classes. >> >> The original comment is more accurate. Maybe use 'eager loading' if >> you want to avoid the confusion between 'preloading' and CDS's term? >> > I can see that "class resolution" could have different meanings, > although resolve_well_known_classes does call > SystemDictionary::resolve_or_fail, not any the SystemDictionary::load* > functions. So using the word "resolve" would be more appropriate. > > How about changing the comments to the following to avoid ambiguity. > > #define WK_KLASS_ENUM_NAME(kname)??? kname##_knum > > // Certain classes, such as java.lang.Object and java.lang.String, > // are "well-known", in the sense that no class loader is allowed > // to provide a different definition. > // > // Each well-known class has a short klass name (like object_klass), > // and a vmSymbol name (like java_lang_Object). > // > // The order of these definitions is significant: the classes are > // resolved during early VM start-up by resolve_well_known_classes > // in this order. Changing the order may require careful restructuring > // of the VM start-up sequence. > // > #define WK_KLASSES_DO(do_klass) ...... Looks ok. Thanks, Jiangli > > > Thanks > - Ioi >> The test looks good. Thanks for filling the gap in this area! >> >> Thanks, >> Jiangli >> >> On 10/21/18 10:49 PM, Ioi Lam wrote: >>> Hi David, >>> >>> Thanks for the review. Updated webrev: >>> >>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ >>> >>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ >>> >>> >>> More comments below: >>> >>> >>> >>> On 10/21/18 6:57 PM, David Holmes wrote: >>>> Hi Ioi, >>>> >>>> Generally seems okay. >>>> >>>> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>>>> Re-sending to the correct mailing lists. Please disregard the >>>>> other email. >>>>> >>>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>>>> >>>>> Hi, >>>>> >>>>> CDS has various built-in assumptions that classes loaded by >>>>> SystemDictionary::resolve_well_known_classes must not be replaced >>>>> by JVMTI ClassFileLoadHook during run time, including >>>>> >>>>> - field offsets computed in JavaClasses::compute_offsets >>>>> - the layout of the strings objects in the shared strings table >>>>> >>>>> The "well-known" classes can be replaced by ClassFileLoadHook only >>>>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>>>> fix is to disable CDS under this condition. >>>> >>>> I'm a little unclear why we have to iterate JvmtiEnv list when this >>>> has to be checked during JVMTI_PHASE_PRIMORDIAL? >>>> >>> I think you are asking about this new function? I don't like the >>> name "early_class_hook_env()". Maybe I should change it to >>> "has_early_class_hook_env()"? >>> >>> >>> bool JvmtiExport::early_class_hook_env() { >>> ? JvmtiEnvIterator it; >>> ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >>> ??? if (env->early_class_hook_env()) { >>> ????? return true; >>> ??? } >>> ? } >>> ? return false; >>> } >>> >>> This function matches condition in the existing code that would call >>> into ClassFileLoadHook: >>> >>> class JvmtiClassFileLoadHookPoster { >>> ?... >>> ? void post_all_envs() { >>> ??? JvmtiEnvIterator it; >>> ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >>> ? ? ??? .. >>> ??????? post_to_env(env, true); >>> ??? } >>> ? } >>> ... >>> ? void post_to_env(JvmtiEnv* env, bool caching_needed) { >>> ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && >>> !env->early_class_hook_env()) { >>> ????? return; >>> ??? } >>> >>> >>> post_all_envs() is called just before a class is about to be loaded >>> in the JVM. So if *any* env->early_class_hook_env() returns true, >>> there's a chance that it will replace a well-known class.So, as a >>> preventive measure, CDS will be disabled. >>> >>> >>> >>>>> I have added a few test cases to try to replace shared classes, >>>>> including well-known classes and other classes. See >>>>> comments in ReplaceCriticalClasses.java for details. >>>>> >>>>> As a clean up, I also renamed all use of "preloaded" in >>>>> the source code to "well-known". They refer to the same thing >>>>> in HotSpot, so there's no need to use 2 terms. Also, The word >>>>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>>>> and could be confused with what CDS does during archive dump time. >>>> >>>> A few specific comments: >>>> >>>> src/hotspot/share/classfile/systemDictionary.cpp >>>> >>>> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >>>> +?? for (int i = 0; ; i++) { >>>> +???? int sid = wk_init_info[i]; >>>> +???? if (sid == 0) { >>>> +?????? break; >>>> +???? } >>>> >>>> I take it a zero value is a guaranteed end-of-list sentinel? >>>> >>> >>> Yes. The array is defined just a few lines above: >>> >>> static const short wk_init_info[] = { >>> ? #define WK_KLASS_INIT_INFO(name, symbol) \ >>> ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), >>> >>> ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) >>> ? #undef WK_KLASS_INIT_INFO >>> ? 0 >>> }; >>> >>> Also, >>> >>> class vmSymbols: AllStatic { >>> ? enum SID { >>> ??? NO_SID = 0, >>> ??? .... >>> >>> >>> >>>> + for (int i=FIRST_WKID; i>>> >>>> Style nit: need spaces around = and < >>>> >>> >>> Fixed. >>> >>>> --- >>>> >>>> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >>>> >>>> >>>> New file should have current copyright year only. >>>> >>> Fixed. >>> >>>> ?31? * @comment CDS should not be disabled -- these critical >>>> classes will be replaced because >>>> JvmtiExport::early_class_hook_env() is true. >>>> >>>> Comment seems contradictory: if we replace critical classes then >>>> CDS should be disabled right?? >>>> >>> Fixed. >>> >>>> I expected to see tests that checked for: >>>> >>>> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >>>> >>>> in the output. ?? >>>> >>> >>> It would have been easy if jtreg lets you check the output of @run >>> easily. Instead, your innocent suggestion has turned into 150+ lines >>> of new code :-( Maybe "let's write all shell tests in Java" isn't >>> such a great idea after all. >>> >>> >>> Now the test checks that whether CDS is indeed disabled, whether the >>> affected class is loaded from the shared archive, etc. >>> >>> Thanks >>> - Ioi >>> >>>> Thanks, >>>> David >>>> >>>> >>>>> >>>>> ?> In early e-mails Jiangli wrote: >>>>> ?> >>>>> ?> We should consider including more classes from the default >>>>> classlist >>>>> ?> in the test. Archived classes loaded during both 'early' phase >>>>> and after >>>>> ?> should be tested. >>>>> >>>>> Done. >>>>> >>>>> >>>>> ?> For future optimizations, we might want to prevent loading >>>>> additional >>>>> ?> shared classes if any of the archived system classes is changed. >>>>> >>>>> What's the benefit of doing this? Today we already stop loading a >>>>> shared >>>>> class if its super class was not loaded from the archive. >>>>> >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>> >> > From david.holmes at oracle.com Mon Oct 22 22:31:10 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Oct 2018 08:31:10 +1000 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> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> Message-ID: Sorry Dean I'm concerned about a thread termination bottleneck with this. A simple microbenchmark that creates 500,000 threads that have to run and terminate, shows a 15+% slowdown on my Linux box. I tried to find some kind of real benchmarks that covers thread termination but couldn't see anything specific. Can you at least run this through our performance system to see if any of the regular benchmarks are affected. Thanks, David On 20/10/2018 1:28 PM, dean.long at oracle.com wrote: > On 10/18/18 6:12 PM, Mandy Chung wrote: >> >> >> On 10/18/18 12:27 AM, David Holmes wrote: >>> Hi Dean, >>> >>> On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: >>>> >>>> You're right, I missed that.? I think the right thing to do is call >>>> current_thread_exiting while holding the Threads_lock. >>>> Then we can get rid of the parallel atomic counters.? So, here's one >>>> more try: >>>> >>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ >>> >>> Okay that is the simple and obvious solution that doesn't require >>> split counts. So I have to ask Mandy if she recalls why this approach >>> wasn't taken 15 years ago when the exit counts were added as part of: >>> >> >> It has been so long.? I think it's likely an oversight. >>> https://bugs.openjdk.java.net/browse/JDK-4530538 ? >>> >>> Does taking the Threads_lock here cost too much and cause a thread >>> termination bottleneck? >> >> If the contention on Threads_lock is not high (that seems to me), it >> should be okay. ? I'm not close to the VM implementation (lot of >> changes since then) and I don't have a definitive answer unless I >> study the code closely.?? You and others have a better judgement on this. >> >> AFAICT the change is okay. >> > > Thanks Mandy.? David, OK to push? > > dl > >> Mandy >> >> > From serguei.spitsyn at oracle.com Tue Oct 23 00:09:04 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Oct 2018 17:09:04 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> Message-ID: <84e95bbf-7e94-2554-a049-f67044dd7767@oracle.com> An HTML attachment was scrubbed... URL: From hohensee at amazon.com Tue Oct 23 00:10:09 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Oct 2018 00:10:09 +0000 Subject: RFR (M) 8212771: Remove remaining spaces before/after () for vmTestbase In-Reply-To: <39560b3f-41b5-bd64-4acf-7e81cf196953@oracle.com> References: <39560b3f-41b5-bd64-4acf-7e81cf196953@oracle.com> Message-ID: Lgtm. There?s a similar issue with ?{??}? you might want to fix separately, except in the opposite direction :), e.g., in test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp, +#define JVMTI_ERROR_CHECK(str,res) if (res != JVMTI_ERROR_NONE) { printf(str); printf("%d\n",res); return res;} +#define JVMTI_ERROR_CHECK_EXPECTED_ERROR(str,res,err) if (res != err) { printf(str); printf("unexpected error %d\n",res); return res;} => +#define JVMTI_ERROR_CHECK(str,res) if (res != JVMTI_ERROR_NONE) { printf(str); printf("%d\n",res); return res; } +#define JVMTI_ERROR_CHECK_EXPECTED_ERROR(str,res,err) if (res != err) { printf(str); printf("unexpected error %d\n",res); return res; } And somewhat different in test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp + (threadConstructor = NSK_CPP_STUB4(GetMethodID, jni, klass, "", "()V")) != NULL)) { => + (threadConstructor = NSK_CPP_STUB4(GetMethodID, jni, klass, "", "()V")) != NULL)) { Paul From: serviceability-dev on behalf of "serguei.spitsyn at oracle.com" Date: Monday, October 22, 2018 at 3:15 PM To: JC Beyler , "serviceability-dev at openjdk.java.net" Subject: Re: RFR (M) 8212771: Remove remaining spaces before/after () for vmTestbase Hi Jc, It looks good. Thanks! Serguei On 10/22/18 11:30, JC Beyler wrote: Hi all, Here is the last webrev (3 out of 3) to remove the spaces after/before () from vmTestbase. It is straightforward and I generated the webrev with white-space changes showing up of course: Webrev: http://cr.openjdk.java.net/~jcbeyler/8212771/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212771 Could I please get some reviews? Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Tue Oct 23 00:23:30 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Oct 2018 00:23:30 +0000 Subject: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* In-Reply-To: <6aac2588-0eb5-bd01-be60-0565474ab5ba@oracle.com> References: <68620d49-36c6-4ca3-a135-9c593cfb0fe2@oracle.com> <6aac2588-0eb5-bd01-be60-0565474ab5ba@oracle.com> Message-ID: Lgtm. One nit in libnativeGC01.cpp - * A C function that takes a reference to java Object( a circular Linked list) + * A C function that takes a reference to java Object(a circular Linked list) => + * A C function that takes a reference to java Object (a circular Linked list) No need for a new webrev. Paul From: serviceability-dev on behalf of "serguei.spitsyn at oracle.com" Date: Monday, October 22, 2018 at 2:40 PM To: JC Beyler , "alexey.menkov at oracle.com" Cc: "serviceability-dev at openjdk.java.net" Subject: Re: RFR (M) 8212535: Remove spaces before/after () for vmTestbase/[a-s]* Hi Alex, It looks good. Thanks! Serguei On 10/22/18 12:56, JC Beyler wrote: Hi Alex, Done, I left this one: - if (!NSK_JVMTI_VERIFY( - jvmti->IterateOverHeap(JVMTI_HEAP_OBJECT_EITHER, heapObjectCallback, (void *)user_data))) { + if (!NSK_JVMTI_VERIFY(jvmti->IterateOverHeap( + JVMTI_HEAP_OBJECT_EITHER, heapObjectCallback, (void *)user_data))) { The whole length was at 126 characters, it seemed a bit long: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp.udiff.html The new webrev is here: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.02/ Thanks, Jc On Mon, Oct 22, 2018 at 12:44 PM Alex Menkov > wrote: Hi Jc, Looks good to me. Could you please update nsk/jvmti/IterateOverHeap/iterheap007/iterheap007.cpp : if (!NSK_JVMTI_VERIFY( - )) { + )) { => if (!NSK_JVMTI_VERIFY()) { As all s there are quite short. --alex On 10/19/2018 14:56, JC Beyler wrote: > Hi Chris, > > Done! > > Here is the newest version: > http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.01/ > > > Thanks for the review! > Jc > > On Fri, Oct 19, 2018 at 2:24 PM Chris Plummer > >> wrote: > > Hi JC, > > iterinstcls006.cpp: Can you fix the indentation of the second line. > > 98 NSK_COMPLAIN2("Local storage was corrupted: %s > ,\n\texpected value: %s\n", > 99 (char *)storage_ptr, storage_data); > > iterobjreachobj004.cpp: Can you fix the indentation of the second line. > > 123 NSK_COMPLAIN2("Local storage was corrupted: %s > ,\n\texpected value: %s\n", > 124 (char *)storage_ptr, storage_data); > > iterreachobj002.cpp: You didn't align the arguments like you have > elsewhere. > > 175 > stackReferenceCallbackForSecondObjectsIteration(jvmtiHeapRootKind > root_kind, > 176 jlong class_tag, > 177 jlong size, > 178 jlong* tag_ptr, > 179 jlong thread_tag, > 180 jint depth, > 181 jmethodID method, > 182 jint slot, > 183 void* user_data) { > > iterreachobj004.cpp: Can you fix the indentation of the second line. > > 75 NSK_COMPLAIN2("heapRootCallback: Local storage was > corrupted: %s ,\n\texpected value: %s\n", > 76 (char *)storage_ptr, storage_data); > > 119 NSK_COMPLAIN2("stackReferenceCallback: Local storage > was corrupted: %s ,\n\texpected value: %s\n", > 120 (char *)storage_ptr, storage_data); > > 162 NSK_COMPLAIN2("objectReferenceCallback: Local storage > was corrupted: %s ,\n\texpected value: %s\n", > 163 (char *)storage_ptr, storage_data); > > thanks, > > Chris > > On 10/19/18 1:49 PM, JC Beyler wrote: >> Hi all, >> >> Sorry about the spam; forgot to add the subject :) >> >> Here is the first of three webrevs to remove spaces around (); I >> also removed any space after !. >> >> When the change modified where future parameters should be >> indented, I changed those too (such as >> http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html >> ) >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 >> >> Thanks! >> Jc >> >> On Fri, Oct 19, 2018 at 1:47 PM JC Beyler >> >> wrote: >> >> Hi all, >> >> Here is the first of three webrevs to remove spaces around (); >> I also removed any space after !. >> >> When the change modified where future parameters should be >> indented, I changed those too (such as >> http://cr.openjdk.java.net/~jcbeyler/8212535/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/IterateOverObjectsReachableFromObject/iterobjreachobj002/iterobjreachobj002.cpp.udiff.html >> ) >> >> Webrev: https://bugs.openjdk.java.net/browse/JDK-8212535 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212535 >> >> 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 Tue Oct 23 00:24:38 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 22 Oct 2018 17:24:38 -0700 Subject: RFR JDK-8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 In-Reply-To: References: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> <523f6153-3376-edda-1786-41cfff3dbdd4@oracle.com> Message-ID: <958d7054-4b22-7fbb-bac1-87dd0c083f69@oracle.com> Hi Jc, new webrev: http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev.02/ --alex On 10/20/2018 20:29, JC Beyler wrote: > Hi Alex, > > It looks really good to me now. The test and JdbTest are now easier to > read because we do not have the noise of the debuggee trying to attach. > > A few nits: > ? - Small nit really is the fact that the javadoc for Debuggee states > two usages and JdbTest does not use either :) > ? - You put a few get methods in Debuggee that are seemingly not used > anywhere, we could add them later if need be and not have them now? > > Thanks for this, I think it's really better in the long run to have this > in one centralized spot, > Jc > > On Fri, Oct 19, 2018 at 3:56 PM Alex Menkov > wrote: > > Hi Jc, > > Updated fix: > http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev.01/ > > Moved shared code to new Debuggee class. > > --alex > > On 10/19/2018 10:34, JC Beyler wrote: > > Hi Alex, > > > > I remember seeing this same code so went looking for it and saw > it in > > JdbTest.java (you added it here it seems: > > http://hg.openjdk.java.net/jdk/jdk/rev/083e731da31a). > > > > I have two few questions: > >? ? - Does it make sense to put this code in a helper method? > >? ? - The code you added in JdbTest.java does not do the adjusted > time > > for 30 it seems, is that normal? > > > > Thanks, > > Jc > > > > On Fri, Oct 19, 2018 at 9:59 AM Alex Menkov > > > >> wrote: > > > >? ? ?Hi all, > > > >? ? ?jira: https://bugs.openjdk.java.net/browse/JDK-8212151 > >? ? ?webrev: > http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/ > > >? ? ? > > > >? ? ?The fix updates the test to allow debuggee to select > available port > >? ? ?instead of using error-prone "getFreePort" approach. > > > >? ? ?--alex > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From daniil.x.titov at oracle.com Tue Oct 23 00:26:17 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 22 Oct 2018 17:26:17 -0700 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <285b017b-497e-1ad1-6f83-6033ae1fdadb@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> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> <285b017b-497e-1ad1-6f83-6033ae1fdadb@oracle.com> Message-ID: Thank you, Chris for reviewing this change! Alex, JC, Garry could you please say are you OK with this version of the webrev? Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 Best regards, Daniil ?On 10/22/18, 11:18 AM, "Chris Plummer" wrote: Hi Daniil, Looks good. thanks, Chris On 10/19/18 4:01 PM, Daniil Titov wrote: > Hi Chris, > > Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete. > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Thanks! > --Daniil > > > ?On 10/19/18, 12:55 PM, "Chris Plummer" wrote: > > On 10/19/18 9:47 AM, Daniil Titov wrote: > > Hi Gary and Chris, > > > > I am resending the previous email since the table in that email got corrupted. > > > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: > > > > The current behavior. > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed > > SUSPEND_NONE: Prompt is not printed, location is not printed > > > > The fix changes this behavior as the following: > > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed > > SUSPEND_NONE: Prompt is printed ( "> "), location is printed > I'm still in favor of this fix. > > > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > Maybe we need a version of command() that takes a pattern to look for > other than the prompt. > > Chris > > > > > > Thanks! > > --Daniil > > > > ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: > > > > Hi Gary and Chris, > > > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: > > > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED > > --------------------------------------- |---------------------------|-------------------------- > > SUSPEND_ALL. | yes, e.g. "main[1]" | yes > > --------------------------------------- |-------------------------- |-------------------------- > > SUSPEND_EVENT_THREAD | no | no > > ----------------------------------------|------------------------ --|-------------------------- > > SUSPEND_ALL. | no | no > > > > > > The fix changes this behavior as the following: > > > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED > > --------------------------------------- |----------------------------|-------------------------- > > SUSPEND_ALL. | yes , e.g. "main[1]" | yes > > --------------------------------------- |----------------------------|-------------------------- > > SUSPEND_EVENT_THREAD | yes , ">" | yes > > ----------------------------------------|--------------------------- |-------------------------- > > SUSPEND_ALL. | yes, ">". | yes > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > > > > > Thanks! > > > > Best regards, > > Daniil > > > > > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: > > > > It's not clear to me if the omitted location information for the non > > stopping > > cases was intentional or not. It may be sufficient to know that the > > event fired > > without the extra information. > > > > I don't think a settable prompt is required either. There are plenty of > > jdb commands that > > could be used with the wait for message in tests that need to > > synchronize at a specific > > point in the test sequence. > > > > I don't think we see wait for simple prompt in any of the tests, because it > > is not reliable enough. > > > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > > Hi Gary, > > > > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > > > > > Thanks! > > > > > > Best regards, > > > Daniil > > > > > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > > > > > I'm not certain that we should be printing locations or prompts for > > > events when the vm has not been suspended. This looks OK for the > > > simple test case we are working on here, but in real life there may > > > be a lot more output produced. > > > > > > The user has to select a specific thread before additional commands > > > can be performed in the correct context. e.g. threads, thread n, where, ... > > > So the information is available to the user. It doesn't have to be > > > produced at the time the event is processed. > > > > > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > > > because there is too great a chance of false positives on such a small > > > marker. > > > > > > > > > On 10/17/18, 8: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). > > > > >>> >> > > > > >>> >> 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 gary.adams at oracle.com Tue Oct 23 00:46:41 2018 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 22 Oct 2018 20:46:41 -0400 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> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> <285b017b-497e-1ad1-6f83-6033ae1fdadb@oracle.com> Message-ID: <1C60E71D-02E3-49B7-8519-6D47F228F3CB@oracle.com> Ok by me Sent from my iPad > On Oct 22, 2018, at 8:26 PM, Daniil Titov wrote: > > Thank you, Chris for reviewing this change! > > Alex, JC, Garry could you please say are you OK with this version of the webrev? > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Best regards, > Daniil > > ?On 10/22/18, 11:18 AM, "Chris Plummer" wrote: > > Hi Daniil, > > Looks good. > > thanks, > > Chris > >> On 10/19/18 4:01 PM, Daniil Titov wrote: >> Hi Chris, >> >> Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 >> >> Thanks! >> --Daniil >> >> >> ?On 10/19/18, 12:55 PM, "Chris Plummer" wrote: >> >>> On 10/19/18 9:47 AM, Daniil Titov wrote: >>> Hi Gary and Chris, >>> >>> I am resending the previous email since the table in that email got corrupted. >>> >>> Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: >>> >>> The current behavior. >>> SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed >>> SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed >>> SUSPEND_NONE: Prompt is not printed, location is not printed >>> >>> The fix changes this behavior as the following: >>> >>> SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed >>> SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed >>> SUSPEND_NONE: Prompt is printed ( "> "), location is printed >> I'm still in favor of this fix. >>> >>> >>> Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? >>> >>> Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... >> Maybe we need a version of command() that takes a pattern to look for >> other than the prompt. >> >> Chris >>> >>> >>> Thanks! >>> --Daniil >>> >>> ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: >>> >>> Hi Gary and Chris, >>> >>> Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: >>> >>> SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED >>> --------------------------------------- |---------------------------|-------------------------- >>> SUSPEND_ALL. | yes, e.g. "main[1]" | yes >>> --------------------------------------- |-------------------------- |-------------------------- >>> SUSPEND_EVENT_THREAD | no | no >>> ----------------------------------------|------------------------ --|-------------------------- >>> SUSPEND_ALL. | no | no >>> >>> >>> The fix changes this behavior as the following: >>> >>> SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED >>> --------------------------------------- |----------------------------|-------------------------- >>> SUSPEND_ALL. | yes , e.g. "main[1]" | yes >>> --------------------------------------- |----------------------------|-------------------------- >>> SUSPEND_EVENT_THREAD | yes , ">" | yes >>> ----------------------------------------|--------------------------- |-------------------------- >>> SUSPEND_ALL. | yes, ">". | yes >>> >>> Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? >>> >>> Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... >>> >>> >>> Thanks! >>> >>> Best regards, >>> Daniil >>> >>> >>> >>> ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: >>> >>> It's not clear to me if the omitted location information for the non >>> stopping >>> cases was intentional or not. It may be sufficient to know that the >>> event fired >>> without the extra information. >>> >>> I don't think a settable prompt is required either. There are plenty of >>> jdb commands that >>> could be used with the wait for message in tests that need to >>> synchronize at a specific >>> point in the test sequence. >>> >>> I don't think we see wait for simple prompt in any of the tests, because it >>> is not reliable enough. >>> >>>> On 10/18/18 11:53 AM, Daniil Titov wrote: >>>> Hi Gary, >>>> >>>> Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? >>>> >>>> Thanks! >>>> >>>> Best regards, >>>> Daniil >>>> >>>> >>>> >>>> ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: >>>> >>>> I'm not certain that we should be printing locations or prompts for >>>> events when the vm has not been suspended. This looks OK for the >>>> simple test case we are working on here, but in real life there may >>>> be a lot more output produced. >>>> >>>> The user has to select a specific thread before additional commands >>>> can be performed in the correct context. e.g. threads, thread n, where, ... >>>> So the information is available to the user. It doesn't have to be >>>> produced at the time the event is processed. >>>> >>>> I'm uncomfortable putting too much trust in waiting for the simple prompt, >>>> because there is too great a chance of false positives on such a small >>>> marker. >>>> >>>> >>>>> On 10/17/18, 8: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). >>>>>>>>>> >>>>>>>>>> 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 Tue Oct 23 00:47:48 2018 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 22 Oct 2018 17:47:48 -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> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> <285b017b-497e-1ad1-6f83-6033ae1fdadb@oracle.com> Message-ID: I'm fine with it --alex On 10/22/2018 17:26, Daniil Titov wrote: > Thank you, Chris for reviewing this change! > > Alex, JC, Garry could you please say are you OK with this version of the webrev? > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > Best regards, > Daniil > > ?On 10/22/18, 11:18 AM, "Chris Plummer" wrote: > > Hi Daniil, > > Looks good. > > thanks, > > Chris > > On 10/19/18 4:01 PM, Daniil Titov wrote: > > Hi Chris, > > > > Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > > > Thanks! > > --Daniil > > > > > > ?On 10/19/18, 12:55 PM, "Chris Plummer" wrote: > > > > On 10/19/18 9:47 AM, Daniil Titov wrote: > > > Hi Gary and Chris, > > > > > > I am resending the previous email since the table in that email got corrupted. > > > > > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: > > > > > > The current behavior. > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed > > > SUSPEND_NONE: Prompt is not printed, location is not printed > > > > > > The fix changes this behavior as the following: > > > > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed > > > SUSPEND_NONE: Prompt is printed ( "> "), location is printed > > I'm still in favor of this fix. > > > > > > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > Maybe we need a version of command() that takes a pattern to look for > > other than the prompt. > > > > Chris > > > > > > > > > Thanks! > > > --Daniil > > > > > > ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: > > > > > > Hi Gary and Chris, > > > > > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: > > > > > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED > > > --------------------------------------- |---------------------------|-------------------------- > > > SUSPEND_ALL. | yes, e.g. "main[1]" | yes > > > --------------------------------------- |-------------------------- |-------------------------- > > > SUSPEND_EVENT_THREAD | no | no > > > ----------------------------------------|------------------------ --|-------------------------- > > > SUSPEND_ALL. | no | no > > > > > > > > > The fix changes this behavior as the following: > > > > > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED > > > --------------------------------------- |----------------------------|-------------------------- > > > SUSPEND_ALL. | yes , e.g. "main[1]" | yes > > > --------------------------------------- |----------------------------|-------------------------- > > > SUSPEND_EVENT_THREAD | yes , ">" | yes > > > ----------------------------------------|--------------------------- |-------------------------- > > > SUSPEND_ALL. | yes, ">". | yes > > > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt " > " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > > > > > > > > Thanks! > > > > > > Best regards, > > > Daniil > > > > > > > > > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: > > > > > > It's not clear to me if the omitted location information for the non > > > stopping > > > cases was intentional or not. It may be sufficient to know that the > > > event fired > > > without the extra information. > > > > > > I don't think a settable prompt is required either. There are plenty of > > > jdb commands that > > > could be used with the wait for message in tests that need to > > > synchronize at a specific > > > point in the test sequence. > > > > > > I don't think we see wait for simple prompt in any of the tests, because it > > > is not reliable enough. > > > > > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > > > Hi Gary, > > > > > > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > > > > > > > Thanks! > > > > > > > > Best regards, > > > > Daniil > > > > > > > > > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > > > > > > > I'm not certain that we should be printing locations or prompts for > > > > events when the vm has not been suspended. This looks OK for the > > > > simple test case we are working on here, but in real life there may > > > > be a lot more output produced. > > > > > > > > The user has to select a specific thread before additional commands > > > > can be performed in the correct context. e.g. threads, thread n, where, ... > > > > So the information is available to the user. It doesn't have to be > > > > produced at the time the event is processed. > > > > > > > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > > > > because there is too great a chance of false positives on such a small > > > > marker. > > > > > > > > > > > > On 10/17/18, 8: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). > > > > > >>> >> > > > > > >>> >> 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 ioi.lam at oracle.com Tue Oct 23 01:43:22 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 22 Oct 2018 18:43:22 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: <68e6b46e-6a7c-0343-d956-f3e5da3d6bcd@oracle.com> References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> <48b5854c-1715-b968-4a90-5d243c8994eb@oracle.com> <68e6b46e-6a7c-0343-d956-f3e5da3d6bcd@oracle.com> Message-ID: On 10/22/18 3:06 PM, Jiangli Zhou wrote: > On 10/22/18 10:56 AM, Ioi Lam wrote: > >> >> >> On 10/22/18 10:25 AM, Jiangli Zhou wrote: >>> Hi Ioi, >>> >>> Looks good. Please see comments below. >>> >>> - src/hotspot/share/classfile/javaClasses.cpp >>> >>> 4254???? assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, >>> 4255??????????? "Field offsets of well-known classes must be >>> computed in JVMTI_PHASE_PRIMORDIAL or before"); >>> >>> Maybe it is worth adding a function (for example, is_primordial()) >>> in jvmtiEnvBase.hpp, so we can avoid using JVMTI details here? >>> >> I'll add JvmtiExport::is_early_phase(), since the phase can be either >> JVMTI_PHASE_ONLOAD or? JVMTI_PHASE_PRIMORDIAL. >> >>> I'm not too sure if the assert is necessary. Why well known-classes' >>> field offsets must be computed in JVMTI_PHASE_PRIMORDIAL or before? >>> Currently they are, however that's because they are used early by >>> the VM. That doesn't directly relate to any JVMTI phase necessarily. >>> With the assert, we are explicitly making a connection to the JVMTI >>> phases. To me, that doesn't seem to be necessary. >>> >> >> JavaClasses::compute_offsets uses many different classes. I would >> need to check that each of them were in the well-known class list, so >> that we know the offsets stored in the CDS archive are still valid. >> However, I couldn't find a single place to make such a check, and it >> would be much easier to add the above assert, which means any shared >> class used inside compute_offsets cannot be replaced by JVMTI. >> >> How about this: >> >> void JavaClasses::compute_offsets() { >> ? if (UseSharedSpaces) { >> ??? assert(JvmtiEnvBase::is_early_phase() && >> !JvmtiExport::has_early_class_hook_env(), >> ?????????? "JavaClasses::compute_offsets() must be called in early >> JVMTI phase."); >> ??? // None of the classes used by the rest of this function can be >> replaced by >> ??? // JMVTI ClassFileLoadHook. >> ??? // We are safe to use the archived offsets, which have already >> been restored >> ??? // by JavaClasses::serialize_offsets, without computing the >> offsets again. >> ??? return; >> ? } > > You could do assert(k->is_shared() || !UseSharedSpaces) in the > DO_SERIALIZE_OFFSETS macro to make sure the expected shared classes > are used when UseSharedSpaces is enabled during loading the archived > field offsets. The extra !UseSharedSpaces here is because > serialize_offsets() function is used for both dump time and runtime. > It could be removed because the 'is_shared' flag is probably already > set when we writing out data at dump time, but please double check that. > > #define DO_SERIALIZE_OFFSETS(k) k::serialize_offsets(soc); > > If JvmtiExport::early_class_hook_env is requested by a JVMTI agent, > UseSharedSpaces should already be disabled at runtime, otherwise a > shared class should be used in this case. > Hi Jiangli, Thanks for the suggestion. I tried this, but The "k" parameter to this macro is not an InstanceKlass. Instead, it's these guys #define BASIC_JAVA_CLASSES_DO_PART2(f) \ ? f(java_lang_System) \ ? f(java_lang_ClassLoader) \ ? f(java_lang_Throwable) \ ? f(java_lang_Thread) \ ? f(java_lang_ThreadGroup) \ ? f(java_lang_AssertionStatusDirectives) \ ? f(java_lang_ref_SoftReference) \ ? f(java_lang_invoke_MethodHandle) \ ? f(java_lang_invoke_DirectMethodHandle) \ ? f(java_lang_invoke_MemberName) \ ? f(java_lang_invoke_ResolvedMethodName) \ ? f(java_lang_invoke_LambdaForm) \ ? f(java_lang_invoke_MethodType) \ ? f(java_lang_invoke_CallSite) \ ? f(java_lang_invoke_MethodHandleNatives_CallSiteContext) \ ? f(java_security_AccessControlContext) \ ? f(java_lang_reflect_AccessibleObject) \ ? f(java_lang_reflect_Method) \ ? f(java_lang_reflect_Constructor) \ ? f(java_lang_reflect_Field) \ ? f(java_nio_Buffer) \ ? f(reflect_ConstantPool) \ ? f(reflect_UnsafeStaticFieldAccessorImpl) \ ? f(java_lang_reflect_Parameter) \ ? f(java_lang_Module) \ ? f(java_lang_StackTraceElement) \ ? f(java_lang_StackFrameInfo) \ ? f(java_lang_LiveStackFrameInfo) \ ? f(java_util_concurrent_locks_AbstractOwnableSynchronizer) \ ? //end I can somehow force this to work by reworking all macros related to BASIC_JAVA_CLASSES_DO, but that doesn't seem to be worth it. I think my current assert is stronger than necessary so it's safe and simple. Thanks - Ioi >> >> >>> - src/hotspot/share/classfile/systemDictionary.cpp >>> >>> 2108?? if (UseSharedSpaces) { >>> 2109???? assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, >>> 2110??????????? "All well known classes must be resolved in >>> JVMTI_PHASE_PRIMORDIAL or before"); >>> 2111???? for (int i = FIRST_WKID; i < last; i++) { >>> 2112?????? InstanceKlass* k = _well_known_klasses[i]; >>> 2113?????? assert(k->is_shared(), "must not be replaced by JVMTI >>> class file load hook"); >>> 2114???? } >>> >>> Please include the above block under #ifdef ASSERT. >>> >> OK >> >>> -// preloading is actually performed by resolve_preloaded_classes. >>> +// class resolution is actually performed by >>> resolve_well_known_classes. >>> >>> The original comment is more accurate. Maybe use 'eager loading' if >>> you want to avoid the confusion between 'preloading' and CDS's term? >>> >> I can see that "class resolution" could have different meanings, >> although resolve_well_known_classes does call >> SystemDictionary::resolve_or_fail, not any the >> SystemDictionary::load* functions. So using the word "resolve" would >> be more appropriate. >> >> How about changing the comments to the following to avoid ambiguity. >> >> #define WK_KLASS_ENUM_NAME(kname)??? kname##_knum >> >> // Certain classes, such as java.lang.Object and java.lang.String, >> // are "well-known", in the sense that no class loader is allowed >> // to provide a different definition. >> // >> // Each well-known class has a short klass name (like object_klass), >> // and a vmSymbol name (like java_lang_Object). >> // >> // The order of these definitions is significant: the classes are >> // resolved during early VM start-up by resolve_well_known_classes >> // in this order. Changing the order may require careful restructuring >> // of the VM start-up sequence. >> // >> #define WK_KLASSES_DO(do_klass) ...... > > Looks ok. > > Thanks, > Jiangli >> >> >> Thanks >> - Ioi >>> The test looks good. Thanks for filling the gap in this area! >>> >>> Thanks, >>> Jiangli >>> >>> On 10/21/18 10:49 PM, Ioi Lam wrote: >>>> Hi David, >>>> >>>> Thanks for the review. Updated webrev: >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ >>>> >>>> >>>> More comments below: >>>> >>>> >>>> >>>> On 10/21/18 6:57 PM, David Holmes wrote: >>>>> Hi Ioi, >>>>> >>>>> Generally seems okay. >>>>> >>>>> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>>>>> Re-sending to the correct mailing lists. Please disregard the >>>>>> other email. >>>>>> >>>>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>>>>> >>>>>> Hi, >>>>>> >>>>>> CDS has various built-in assumptions that classes loaded by >>>>>> SystemDictionary::resolve_well_known_classes must not be replaced >>>>>> by JVMTI ClassFileLoadHook during run time, including >>>>>> >>>>>> - field offsets computed in JavaClasses::compute_offsets >>>>>> - the layout of the strings objects in the shared strings table >>>>>> >>>>>> The "well-known" classes can be replaced by ClassFileLoadHook only >>>>>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>>>>> fix is to disable CDS under this condition. >>>>> >>>>> I'm a little unclear why we have to iterate JvmtiEnv list when >>>>> this has to be checked during JVMTI_PHASE_PRIMORDIAL? >>>>> >>>> I think you are asking about this new function? I don't like the >>>> name "early_class_hook_env()". Maybe I should change it to >>>> "has_early_class_hook_env()"? >>>> >>>> >>>> bool JvmtiExport::early_class_hook_env() { >>>> ? JvmtiEnvIterator it; >>>> ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >>>> ??? if (env->early_class_hook_env()) { >>>> ????? return true; >>>> ??? } >>>> ? } >>>> ? return false; >>>> } >>>> >>>> This function matches condition in the existing code that would >>>> call into ClassFileLoadHook: >>>> >>>> class JvmtiClassFileLoadHookPoster { >>>> ?... >>>> ? void post_all_envs() { >>>> ??? JvmtiEnvIterator it; >>>> ??? for (JvmtiEnv* env = it.first(); env != NULL; env = >>>> it.next(env)) { >>>> ? ? ??? .. >>>> ??????? post_to_env(env, true); >>>> ??? } >>>> ? } >>>> ... >>>> ? void post_to_env(JvmtiEnv* env, bool caching_needed) { >>>> ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && >>>> !env->early_class_hook_env()) { >>>> ????? return; >>>> ??? } >>>> >>>> >>>> post_all_envs() is called just before a class is about to be loaded >>>> in the JVM. So if *any* env->early_class_hook_env() returns true, >>>> there's a chance that it will replace a well-known class.So, as a >>>> preventive measure, CDS will be disabled. >>>> >>>> >>>> >>>>>> I have added a few test cases to try to replace shared classes, >>>>>> including well-known classes and other classes. See >>>>>> comments in ReplaceCriticalClasses.java for details. >>>>>> >>>>>> As a clean up, I also renamed all use of "preloaded" in >>>>>> the source code to "well-known". They refer to the same thing >>>>>> in HotSpot, so there's no need to use 2 terms. Also, The word >>>>>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>>>>> and could be confused with what CDS does during archive dump time. >>>>> >>>>> A few specific comments: >>>>> >>>>> src/hotspot/share/classfile/systemDictionary.cpp >>>>> >>>>> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >>>>> +?? for (int i = 0; ; i++) { >>>>> +???? int sid = wk_init_info[i]; >>>>> +???? if (sid == 0) { >>>>> +?????? break; >>>>> +???? } >>>>> >>>>> I take it a zero value is a guaranteed end-of-list sentinel? >>>>> >>>> >>>> Yes. The array is defined just a few lines above: >>>> >>>> static const short wk_init_info[] = { >>>> ? #define WK_KLASS_INIT_INFO(name, symbol) \ >>>> ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), >>>> >>>> ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) >>>> ? #undef WK_KLASS_INIT_INFO >>>> ? 0 >>>> }; >>>> >>>> Also, >>>> >>>> class vmSymbols: AllStatic { >>>> ? enum SID { >>>> ??? NO_SID = 0, >>>> ??? .... >>>> >>>> >>>> >>>>> + for (int i=FIRST_WKID; i>>>> >>>>> Style nit: need spaces around = and < >>>>> >>>> >>>> Fixed. >>>> >>>>> --- >>>>> >>>>> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >>>>> >>>>> >>>>> New file should have current copyright year only. >>>>> >>>> Fixed. >>>> >>>>> ?31? * @comment CDS should not be disabled -- these critical >>>>> classes will be replaced because >>>>> JvmtiExport::early_class_hook_env() is true. >>>>> >>>>> Comment seems contradictory: if we replace critical classes then >>>>> CDS should be disabled right?? >>>>> >>>> Fixed. >>>> >>>>> I expected to see tests that checked for: >>>>> >>>>> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >>>>> >>>>> in the output. ?? >>>>> >>>> >>>> It would have been easy if jtreg lets you check the output of @run >>>> easily. Instead, your innocent suggestion has turned into 150+ >>>> lines of new code :-( Maybe "let's write all shell tests in Java" >>>> isn't such a great idea after all. >>>> >>>> >>>> Now the test checks that whether CDS is indeed disabled, whether >>>> the affected class is loaded from the shared archive, etc. >>>> >>>> Thanks >>>> - Ioi >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> >>>>>> ?> In early e-mails Jiangli wrote: >>>>>> ?> >>>>>> ?> We should consider including more classes from the default >>>>>> classlist >>>>>> ?> in the test. Archived classes loaded during both 'early' phase >>>>>> and after >>>>>> ?> should be tested. >>>>>> >>>>>> Done. >>>>>> >>>>>> >>>>>> ?> For future optimizations, we might want to prevent loading >>>>>> additional >>>>>> ?> shared classes if any of the archived system classes is changed. >>>>>> >>>>>> What's the benefit of doing this? Today we already stop loading a >>>>>> shared >>>>>> class if its super class was not loaded from the archive. >>>>>> >>>>>> >>>>>> Thanks >>>>>> - Ioi >>>>>> >>>> >>> >> > From jiangli.zhou at oracle.com Tue Oct 23 01:46:46 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 22 Oct 2018 18:46:46 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> <48b5854c-1715-b968-4a90-5d243c8994eb@oracle.com> <68e6b46e-6a7c-0343-d956-f3e5da3d6bcd@oracle.com> Message-ID: Sounds good. Thanks for trying that. Thanks, Jiangli > On Oct 22, 2018, at 6:43 PM, Ioi Lam wrote: > > > >> On 10/22/18 3:06 PM, Jiangli Zhou wrote: >>> On 10/22/18 10:56 AM, Ioi Lam wrote: >>> >>> >>> >>>> On 10/22/18 10:25 AM, Jiangli Zhou wrote: >>>> Hi Ioi, >>>> >>>> Looks good. Please see comments below. >>>> >>>> - src/hotspot/share/classfile/javaClasses.cpp >>>> >>>> 4254 assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, >>>> 4255 "Field offsets of well-known classes must be computed in JVMTI_PHASE_PRIMORDIAL or before"); >>>> >>>> Maybe it is worth adding a function (for example, is_primordial()) in jvmtiEnvBase.hpp, so we can avoid using JVMTI details here? >>>> >>> I'll add JvmtiExport::is_early_phase(), since the phase can be either JVMTI_PHASE_ONLOAD or JVMTI_PHASE_PRIMORDIAL. >>> >>>> I'm not too sure if the assert is necessary. Why well known-classes' field offsets must be computed in JVMTI_PHASE_PRIMORDIAL or before? Currently they are, however that's because they are used early by the VM. That doesn't directly relate to any JVMTI phase necessarily. With the assert, we are explicitly making a connection to the JVMTI phases. To me, that doesn't seem to be necessary. >>>> >>> >>> JavaClasses::compute_offsets uses many different classes. I would need to check that each of them were in the well-known class list, so that we know the offsets stored in the CDS archive are still valid. However, I couldn't find a single place to make such a check, and it would be much easier to add the above assert, which means any shared class used inside compute_offsets cannot be replaced by JVMTI. >>> >>> How about this: >>> >>> void JavaClasses::compute_offsets() { >>> if (UseSharedSpaces) { >>> assert(JvmtiEnvBase::is_early_phase() && !JvmtiExport::has_early_class_hook_env(), >>> "JavaClasses::compute_offsets() must be called in early JVMTI phase."); >>> // None of the classes used by the rest of this function can be replaced by >>> // JMVTI ClassFileLoadHook. >>> // We are safe to use the archived offsets, which have already been restored >>> // by JavaClasses::serialize_offsets, without computing the offsets again. >>> return; >>> } >> >> You could do assert(k->is_shared() || !UseSharedSpaces) in the DO_SERIALIZE_OFFSETS macro to make sure the expected shared classes are used when UseSharedSpaces is enabled during loading the archived field offsets. The extra !UseSharedSpaces here is because serialize_offsets() function is used for both dump time and runtime. It could be removed because the 'is_shared' flag is probably already set when we writing out data at dump time, but please double check that. >> >> #define DO_SERIALIZE_OFFSETS(k) k::serialize_offsets(soc); >> >> If JvmtiExport::early_class_hook_env is requested by a JVMTI agent, UseSharedSpaces should already be disabled at runtime, otherwise a shared class should be used in this case. >> > Hi Jiangli, > > Thanks for the suggestion. > > I tried this, but The "k" parameter to this macro is not an InstanceKlass. Instead, it's these guys > > #define BASIC_JAVA_CLASSES_DO_PART2(f) \ > f(java_lang_System) \ > f(java_lang_ClassLoader) \ > f(java_lang_Throwable) \ > f(java_lang_Thread) \ > f(java_lang_ThreadGroup) \ > f(java_lang_AssertionStatusDirectives) \ > f(java_lang_ref_SoftReference) \ > f(java_lang_invoke_MethodHandle) \ > f(java_lang_invoke_DirectMethodHandle) \ > f(java_lang_invoke_MemberName) \ > f(java_lang_invoke_ResolvedMethodName) \ > f(java_lang_invoke_LambdaForm) \ > f(java_lang_invoke_MethodType) \ > f(java_lang_invoke_CallSite) \ > f(java_lang_invoke_MethodHandleNatives_CallSiteContext) \ > f(java_security_AccessControlContext) \ > f(java_lang_reflect_AccessibleObject) \ > f(java_lang_reflect_Method) \ > f(java_lang_reflect_Constructor) \ > f(java_lang_reflect_Field) \ > f(java_nio_Buffer) \ > f(reflect_ConstantPool) \ > f(reflect_UnsafeStaticFieldAccessorImpl) \ > f(java_lang_reflect_Parameter) \ > f(java_lang_Module) \ > f(java_lang_StackTraceElement) \ > f(java_lang_StackFrameInfo) \ > f(java_lang_LiveStackFrameInfo) \ > f(java_util_concurrent_locks_AbstractOwnableSynchronizer) \ > //end > > > I can somehow force this to work by reworking all macros related to BASIC_JAVA_CLASSES_DO, but that doesn't seem to be worth it. I think my current assert is stronger than necessary so it's safe and simple. > > Thanks > - Ioi > > >>> >>> >>>> - src/hotspot/share/classfile/systemDictionary.cpp >>>> >>>> 2108 if (UseSharedSpaces) { >>>> 2109 assert(JvmtiEnvBase::get_phase() <= JVMTI_PHASE_PRIMORDIAL, >>>> 2110 "All well known classes must be resolved in JVMTI_PHASE_PRIMORDIAL or before"); >>>> 2111 for (int i = FIRST_WKID; i < last; i++) { >>>> 2112 InstanceKlass* k = _well_known_klasses[i]; >>>> 2113 assert(k->is_shared(), "must not be replaced by JVMTI class file load hook"); >>>> 2114 } >>>> >>>> Please include the above block under #ifdef ASSERT. >>>> >>> OK >>> >>>> -// preloading is actually performed by resolve_preloaded_classes. >>>> +// class resolution is actually performed by resolve_well_known_classes. >>>> >>>> The original comment is more accurate. Maybe use 'eager loading' if you want to avoid the confusion between 'preloading' and CDS's term? >>>> >>> I can see that "class resolution" could have different meanings, although resolve_well_known_classes does call SystemDictionary::resolve_or_fail, not any the SystemDictionary::load* functions. So using the word "resolve" would be more appropriate. >>> >>> How about changing the comments to the following to avoid ambiguity. >>> >>> #define WK_KLASS_ENUM_NAME(kname) kname##_knum >>> >>> // Certain classes, such as java.lang.Object and java.lang.String, >>> // are "well-known", in the sense that no class loader is allowed >>> // to provide a different definition. >>> // >>> // Each well-known class has a short klass name (like object_klass), >>> // and a vmSymbol name (like java_lang_Object). >>> // >>> // The order of these definitions is significant: the classes are >>> // resolved during early VM start-up by resolve_well_known_classes >>> // in this order. Changing the order may require careful restructuring >>> // of the VM start-up sequence. >>> // >>> #define WK_KLASSES_DO(do_klass) ...... >> >> Looks ok. >> >> Thanks, >> Jiangli >>> >>> >>> Thanks >>> - Ioi >>>> The test looks good. Thanks for filling the gap in this area! >>>> >>>> Thanks, >>>> Jiangli >>>> >>>>> On 10/21/18 10:49 PM, Ioi Lam wrote: >>>>> Hi David, >>>>> >>>>> Thanks for the review. Updated webrev: >>>>> >>>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ >>>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ >>>>> >>>>> More comments below: >>>>> >>>>> >>>>> >>>>>> On 10/21/18 6:57 PM, David Holmes wrote: >>>>>> Hi Ioi, >>>>>> >>>>>> Generally seems okay. >>>>>> >>>>>>> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>>>>>> Re-sending to the correct mailing lists. Please disregard the other email. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> CDS has various built-in assumptions that classes loaded by >>>>>>> SystemDictionary::resolve_well_known_classes must not be replaced >>>>>>> by JVMTI ClassFileLoadHook during run time, including >>>>>>> >>>>>>> - field offsets computed in JavaClasses::compute_offsets >>>>>>> - the layout of the strings objects in the shared strings table >>>>>>> >>>>>>> The "well-known" classes can be replaced by ClassFileLoadHook only >>>>>>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>>>>>> fix is to disable CDS under this condition. >>>>>> >>>>>> I'm a little unclear why we have to iterate JvmtiEnv list when this has to be checked during JVMTI_PHASE_PRIMORDIAL? >>>>>> >>>>> I think you are asking about this new function? I don't like the name "early_class_hook_env()". Maybe I should change it to "has_early_class_hook_env()"? >>>>> >>>>> >>>>> bool JvmtiExport::early_class_hook_env() { >>>>> JvmtiEnvIterator it; >>>>> for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >>>>> if (env->early_class_hook_env()) { >>>>> return true; >>>>> } >>>>> } >>>>> return false; >>>>> } >>>>> >>>>> This function matches condition in the existing code that would call into ClassFileLoadHook: >>>>> >>>>> class JvmtiClassFileLoadHookPoster { >>>>> ... >>>>> void post_all_envs() { >>>>> JvmtiEnvIterator it; >>>>> for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >>>>> .. >>>>> post_to_env(env, true); >>>>> } >>>>> } >>>>> ... >>>>> void post_to_env(JvmtiEnv* env, bool caching_needed) { >>>>> if (env->phase() == JVMTI_PHASE_PRIMORDIAL && !env->early_class_hook_env()) { >>>>> return; >>>>> } >>>>> >>>>> >>>>> post_all_envs() is called just before a class is about to be loaded in the JVM. So if *any* env->early_class_hook_env() returns true, there's a chance that it will replace a well-known class.So, as a preventive measure, CDS will be disabled. >>>>> >>>>> >>>>> >>>>>>> I have added a few test cases to try to replace shared classes, >>>>>>> including well-known classes and other classes. See >>>>>>> comments in ReplaceCriticalClasses.java for details. >>>>>>> >>>>>>> As a clean up, I also renamed all use of "preloaded" in >>>>>>> the source code to "well-known". They refer to the same thing >>>>>>> in HotSpot, so there's no need to use 2 terms. Also, The word >>>>>>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>>>>>> and could be confused with what CDS does during archive dump time. >>>>>> >>>>>> A few specific comments: >>>>>> >>>>>> src/hotspot/share/classfile/systemDictionary.cpp >>>>>> >>>>>> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >>>>>> + for (int i = 0; ; i++) { >>>>>> + int sid = wk_init_info[i]; >>>>>> + if (sid == 0) { >>>>>> + break; >>>>>> + } >>>>>> >>>>>> I take it a zero value is a guaranteed end-of-list sentinel? >>>>>> >>>>> >>>>> Yes. The array is defined just a few lines above: >>>>> >>>>> static const short wk_init_info[] = { >>>>> #define WK_KLASS_INIT_INFO(name, symbol) \ >>>>> ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), >>>>> >>>>> WK_KLASSES_DO(WK_KLASS_INIT_INFO) >>>>> #undef WK_KLASS_INIT_INFO >>>>> 0 >>>>> }; >>>>> >>>>> Also, >>>>> >>>>> class vmSymbols: AllStatic { >>>>> enum SID { >>>>> NO_SID = 0, >>>>> .... >>>>> >>>>> >>>>> >>>>>> + for (int i=FIRST_WKID; i>>>>> >>>>>> Style nit: need spaces around = and < >>>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> --- >>>>>> >>>>>> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >>>>>> >>>>>> New file should have current copyright year only. >>>>>> >>>>> Fixed. >>>>> >>>>>> 31 * @comment CDS should not be disabled -- these critical classes will be replaced because JvmtiExport::early_class_hook_env() is true. >>>>>> >>>>>> Comment seems contradictory: if we replace critical classes then CDS should be disabled right?? >>>>>> >>>>> Fixed. >>>>> >>>>>> I expected to see tests that checked for: >>>>>> >>>>>> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >>>>>> >>>>>> in the output. ?? >>>>>> >>>>> >>>>> It would have been easy if jtreg lets you check the output of @run easily. Instead, your innocent suggestion has turned into 150+ lines of new code :-( Maybe "let's write all shell tests in Java" isn't such a great idea after all. >>>>> >>>>> >>>>> Now the test checks that whether CDS is indeed disabled, whether the affected class is loaded from the shared archive, etc. >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> >>>>>>> > In early e-mails Jiangli wrote: >>>>>>> > >>>>>>> > We should consider including more classes from the default classlist >>>>>>> > in the test. Archived classes loaded during both 'early' phase and after >>>>>>> > should be tested. >>>>>>> >>>>>>> Done. >>>>>>> >>>>>>> >>>>>>> > For future optimizations, we might want to prevent loading additional >>>>>>> > shared classes if any of the archived system classes is changed. >>>>>>> >>>>>>> What's the benefit of doing this? Today we already stop loading a shared >>>>>>> class if its super class was not loaded from the archive. >>>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> - Ioi >>>>>>> >>>>> >>>> >>> >> > From ioi.lam at oracle.com Tue Oct 23 01:49:30 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 22 Oct 2018 18:49:30 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: <84e95bbf-7e94-2554-a049-f67044dd7767@oracle.com> References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> <84e95bbf-7e94-2554-a049-f67044dd7767@oracle.com> Message-ID: Hi Serguei, Thanks for the review! On 10/22/18 5:09 PM, serguei.spitsyn at oracle.com wrote: > Hi Ioi, > > It looks good to me. > Some minor questions below. > > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/src/hotspot/share/classfile/systemDictionary.hpp.frames.html > 706 // Resolve well_known classes so they can be used like > SystemDictionary::String_klass() > ? Q1 (really minor): Did you want to spell well_known as well-known as > in the javaClasses.cpp? > > Fixed > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/src/hotspot/share/memory/heapShared.cpp.frames.html > 420 assert(!SystemDictionary::is_well_known_klass(resolved_k), > 421 "shared well-known classes must not be replaced by JVMTI > ClassFileLoadHook"); > 422 ResourceMark rm; > 423 log_info(cds, heap)("Failed to load subgraph because %s was not > loaded from archive", > 424 resolved_k->external_name()); > ?Q2: Would it make sense to move the assert after the log_info? > > Actually, the assert checks for a condition that should never happen, and the log_info can happen in normal execution (when the class being replaced is not a well-known klass). > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java.html > 160 if (checkSubgraph && false) { > ?Q3: Could you explain false a little bit? > Good catch. I left it there by mistake. I will remove the "&& false". Thanks - Ioi > Thanks, > Serguei > > > On 10/21/18 22:49, Ioi Lam wrote: >> Hi David, >> >> Thanks for the review. Updated webrev: >> >> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ >> >> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ >> >> >> More comments below: >> >> >> >> On 10/21/18 6:57 PM, David Holmes wrote: >>> Hi Ioi, >>> >>> Generally seems okay. >>> >>> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>>> Re-sending to the correct mailing lists. Please disregard the other >>>> email. >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>>> >>>> Hi, >>>> >>>> CDS has various built-in assumptions that classes loaded by >>>> SystemDictionary::resolve_well_known_classes must not be replaced >>>> by JVMTI ClassFileLoadHook during run time, including >>>> >>>> - field offsets computed in JavaClasses::compute_offsets >>>> - the layout of the strings objects in the shared strings table >>>> >>>> The "well-known" classes can be replaced by ClassFileLoadHook only >>>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>>> fix is to disable CDS under this condition. >>> >>> I'm a little unclear why we have to iterate JvmtiEnv list when this >>> has to be checked during JVMTI_PHASE_PRIMORDIAL? >>> >> I think you are asking about this new function? I don't like the name >> "early_class_hook_env()". Maybe I should change it to >> "has_early_class_hook_env()"? >> >> >> bool JvmtiExport::early_class_hook_env() { >> ? JvmtiEnvIterator it; >> ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >> ??? if (env->early_class_hook_env()) { >> ????? return true; >> ??? } >> ? } >> ? return false; >> } >> >> This function matches condition in the existing code that would call >> into ClassFileLoadHook: >> >> class JvmtiClassFileLoadHookPoster { >> ?... >> ? void post_all_envs() { >> ??? JvmtiEnvIterator it; >> ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >> ? ? ??? .. >> ??????? post_to_env(env, true); >> ??? } >> ? } >> ... >> ? void post_to_env(JvmtiEnv* env, bool caching_needed) { >> ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && >> !env->early_class_hook_env()) { >> ????? return; >> ??? } >> >> >> post_all_envs() is called just before a class is about to be loaded >> in the JVM. So if *any* env->early_class_hook_env() returns true, >> there's a chance that it will replace a well-known class.So, as a >> preventive measure, CDS will be disabled. >> >> >> >>>> I have added a few test cases to try to replace shared classes, >>>> including well-known classes and other classes. See >>>> comments in ReplaceCriticalClasses.java for details. >>>> >>>> As a clean up, I also renamed all use of "preloaded" in >>>> the source code to "well-known". They refer to the same thing >>>> in HotSpot, so there's no need to use 2 terms. Also, The word >>>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>>> and could be confused with what CDS does during archive dump time. >>> >>> A few specific comments: >>> >>> src/hotspot/share/classfile/systemDictionary.cpp >>> >>> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >>> +?? for (int i = 0; ; i++) { >>> +???? int sid = wk_init_info[i]; >>> +???? if (sid == 0) { >>> +?????? break; >>> +???? } >>> >>> I take it a zero value is a guaranteed end-of-list sentinel? >>> >> >> Yes. The array is defined just a few lines above: >> >> static const short wk_init_info[] = { >> ? #define WK_KLASS_INIT_INFO(name, symbol) \ >> ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), >> >> ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) >> ? #undef WK_KLASS_INIT_INFO >> ? 0 >> }; >> >> Also, >> >> class vmSymbols: AllStatic { >> ? enum SID { >> ??? NO_SID = 0, >> ??? .... >> >> >> >>> + for (int i=FIRST_WKID; i>> >>> Style nit: need spaces around = and < >>> >> >> Fixed. >> >>> --- >>> >>> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >>> >>> >>> New file should have current copyright year only. >>> >> Fixed. >> >>> ?31? * @comment CDS should not be disabled -- these critical classes >>> will be replaced because JvmtiExport::early_class_hook_env() is true. >>> >>> Comment seems contradictory: if we replace critical classes then CDS >>> should be disabled right?? >>> >> Fixed. >> >>> I expected to see tests that checked for: >>> >>> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >>> >>> in the output. ?? >>> >> >> It would have been easy if jtreg lets you check the output of @run >> easily. Instead, your innocent suggestion has turned into 150+ lines >> of new code :-( Maybe "let's write all shell tests in Java" isn't >> such a great idea after all. >> >> >> Now the test checks that whether CDS is indeed disabled, whether the >> affected class is loaded from the shared archive, etc. >> >> Thanks >> - Ioi >> >>> Thanks, >>> David >>> >>> >>>> >>>> ?> In early e-mails Jiangli wrote: >>>> ?> >>>> ?> We should consider including more classes from the default >>>> classlist >>>> ?> in the test. Archived classes loaded during both 'early' phase >>>> and after >>>> ?> should be tested. >>>> >>>> Done. >>>> >>>> >>>> ?> For future optimizations, we might want to prevent loading >>>> additional >>>> ?> shared classes if any of the archived system classes is changed. >>>> >>>> What's the benefit of doing this? Today we already stop loading a >>>> shared >>>> class if its super class was not loaded from the archive. >>>> >>>> >>>> Thanks >>>> - Ioi >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Oct 23 01:53:25 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 22 Oct 2018 18:53:25 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> <84e95bbf-7e94-2554-a049-f67044dd7767@oracle.com> Message-ID: <7d5e0076-faed-d4f6-fefd-db5a6ec003c4@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Oct 23 02:11:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Oct 2018 12:11:19 +1000 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> Message-ID: <2754e93f-9ae5-0dc7-977a-02f35564c00b@oracle.com> Hi Ioi, Sorry for all the extra work in the test. ;-) The updates look good to me (and I've seen follow up comments). Thanks, David On 22/10/2018 3:49 PM, Ioi Lam wrote: > Hi David, > > Thanks for the review. Updated webrev: > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ > > http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ > > > More comments below: > > > > On 10/21/18 6:57 PM, David Holmes wrote: >> Hi Ioi, >> >> Generally seems okay. >> >> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>> Re-sending to the correct mailing lists. Please disregard the other >>> email. >>> >>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>> >>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>> >>> Hi, >>> >>> CDS has various built-in assumptions that classes loaded by >>> SystemDictionary::resolve_well_known_classes must not be replaced >>> by JVMTI ClassFileLoadHook during run time, including >>> >>> - field offsets computed in JavaClasses::compute_offsets >>> - the layout of the strings objects in the shared strings table >>> >>> The "well-known" classes can be replaced by ClassFileLoadHook only >>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>> fix is to disable CDS under this condition. >> >> I'm a little unclear why we have to iterate JvmtiEnv list when this >> has to be checked during JVMTI_PHASE_PRIMORDIAL? >> > I think you are asking about this new function? I don't like the name > "early_class_hook_env()". Maybe I should change it to > "has_early_class_hook_env()"? > > > bool JvmtiExport::early_class_hook_env() { > ? JvmtiEnvIterator it; > ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { > ??? if (env->early_class_hook_env()) { > ????? return true; > ??? } > ? } > ? return false; > } > > This function matches condition in the existing code that would call > into ClassFileLoadHook: > > class JvmtiClassFileLoadHookPoster { > ?... > ? void post_all_envs() { > ??? JvmtiEnvIterator it; > ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { > ? ? ??? .. > ??????? post_to_env(env, true); > ??? } > ? } > ... > ? void post_to_env(JvmtiEnv* env, bool caching_needed) { > ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && > !env->early_class_hook_env()) { > ????? return; > ??? } > > > post_all_envs() is called just before a class is about to be loaded in > the JVM. So if *any* env->early_class_hook_env() returns true, there's a > chance that it will replace a well-known class.So, as a preventive > measure, CDS will be disabled. > > > >>> I have added a few test cases to try to replace shared classes, >>> including well-known classes and other classes. See >>> comments in ReplaceCriticalClasses.java for details. >>> >>> As a clean up, I also renamed all use of "preloaded" in >>> the source code to "well-known". They refer to the same thing >>> in HotSpot, so there's no need to use 2 terms. Also, The word >>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>> and could be confused with what CDS does during archive dump time. >> >> A few specific comments: >> >> src/hotspot/share/classfile/systemDictionary.cpp >> >> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >> +?? for (int i = 0; ; i++) { >> +???? int sid = wk_init_info[i]; >> +???? if (sid == 0) { >> +?????? break; >> +???? } >> >> I take it a zero value is a guaranteed end-of-list sentinel? >> > > Yes. The array is defined just a few lines above: > > static const short wk_init_info[] = { > ? #define WK_KLASS_INIT_INFO(name, symbol) \ > ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), > > ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) > ? #undef WK_KLASS_INIT_INFO > ? 0 > }; > > Also, > > class vmSymbols: AllStatic { > ? enum SID { > ??? NO_SID = 0, > ??? .... > > > >> + for (int i=FIRST_WKID; i> >> Style nit: need spaces around = and < >> > > Fixed. > >> --- >> >> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >> >> >> New file should have current copyright year only. >> > Fixed. > >> ?31? * @comment CDS should not be disabled -- these critical classes >> will be replaced because JvmtiExport::early_class_hook_env() is true. >> >> Comment seems contradictory: if we replace critical classes then CDS >> should be disabled right?? >> > Fixed. > >> I expected to see tests that checked for: >> >> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >> >> in the output. ?? >> > > It would have been easy if jtreg lets you check the output of @run > easily. Instead, your innocent suggestion has turned into 150+ lines of > new code :-( Maybe "let's write all shell tests in Java" isn't such a > great idea after all. > > > Now the test checks that whether CDS is indeed disabled, whether the > affected class is loaded from the shared archive, etc. > > Thanks > - Ioi > >> Thanks, >> David >> >> >>> >>> ?> In early e-mails Jiangli wrote: >>> ?> >>> ?> We should consider including more classes from the default classlist >>> ?> in the test. Archived classes loaded during both 'early' phase and >>> after >>> ?> should be tested. >>> >>> Done. >>> >>> >>> ?> For future optimizations, we might want to prevent loading additional >>> ?> shared classes if any of the archived system classes is changed. >>> >>> What's the benefit of doing this? Today we already stop loading a shared >>> class if its super class was not loaded from the archive. >>> >>> >>> Thanks >>> - Ioi >>> > From jcbeyler at google.com Tue Oct 23 02:49:29 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 22 Oct 2018 19:49:29 -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> <082701C2-3FE1-4646-936F-5BC22A5356C4@oracle.com> <2D074468-CE07-4EDA-8EEA-0A8CDC6768CA@oracle.com> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> <285b017b-497e-1ad1-6f83-6033ae1fdadb@oracle.com> Message-ID: LGTM as well, Jc On Mon, Oct 22, 2018 at 5:47 PM Alex Menkov wrote: > I'm fine with it > > --alex > > On 10/22/2018 17:26, Daniil Titov wrote: > > Thank you, Chris for reviewing this change! > > > > Alex, JC, Garry could you please say are you OK with this version of the > webrev? > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > > > Best regards, > > Daniil > > > > ?On 10/22/18, 11:18 AM, "Chris Plummer" > wrote: > > > > Hi Daniil, > > > > Looks good. > > > > thanks, > > > > Chris > > > > On 10/19/18 4:01 PM, Daniil Titov wrote: > > > Hi Chris, > > > > > > Please review an updated version of the fix that makes the tests > to use a custom pattern while waiting for the command to complete. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > > > > > Thanks! > > > --Daniil > > > > > > > > > ?On 10/19/18, 12:55 PM, "Chris Plummer" > wrote: > > > > > > On 10/19/18 9:47 AM, Daniil Titov wrote: > > > > Hi Gary and Chris, > > > > > > > > I am resending the previous email since the table in that > email got corrupted. > > > > > > > > Below is what output jdb prints when a breakpoint is hit > depending on what suspended policy is used: > > > > > > > > The current behavior. > > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), > location is printed > > > > SUSPEND_EVENT_THREAD: Prompt is not printed, location > is not printed > > > > SUSPEND_NONE: Prompt is not printed, location is not > printed > > > > > > > > The fix changes this behavior as the following: > > > > > > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), > location is printed > > > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), > location is printed > > > > SUSPEND_NONE: Prompt is printed ( "> "), location is > printed > > > I'm still in favor of this fix. > > > > > > > > > > > > Could you please say is it OK for you or you want that the > location was printed only for SUSPEND_ALL case? Or probably just leave all > behavior unchanged and close the bug as "not an issue"? > > > > > > > > Regarding settable prompt... As I understand Gary's > original concern was that waiting in tests for a simple prompt " > " > (>  ) could be unreliable if this substring somehow appears in the > output of the test program and the suggestion was to use more specific > patterns for the cases when the full prompt (thread_name[frame_index]) is > not printed ( e.g. when the current thread is not set). However, we need > somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it > would keep waiting for the full prompt and fail with the timeout. Probably > I am missing something here... > > > Maybe we need a version of command() that takes a pattern to > look for > > > other than the prompt. > > > > > > Chris > > > > > > > > > > > > Thanks! > > > > --Daniil > > > > > > > > ?On 10/19/18, 9:27 AM, "Daniil Titov" < > daniil.x.titov at oracle.com> wrote: > > > > > > > > Hi Gary and Chris, > > > > > > > > Below is the table that shows what jdb output is > printed when a breakpoint is hit depending on what suspended policy is used: > > > > > > > > SUSPEND POLICY | PROMPT > PRINTED | LOCATION PRINTED > > > > --------------------------------------- > |---------------------------|-------------------------- > > > > SUSPEND_ALL. | yes, e.g. > "main[1]" | yes > > > > --------------------------------------- > |-------------------------- |-------------------------- > > > > SUSPEND_EVENT_THREAD | no | > no > > > > > ----------------------------------------|------------------------ > --|-------------------------- > > > > SUSPEND_ALL. | no > | no > > > > > > > > > > > > The fix changes this behavior as the following: > > > > > > > > SUSPEND POLICY | PROMPT > PRINTED. | LOCATION PRINTED > > > > --------------------------------------- > |----------------------------|-------------------------- > > > > SUSPEND_ALL. | yes , e.g. > "main[1]" | yes > > > > --------------------------------------- > |----------------------------|-------------------------- > > > > SUSPEND_EVENT_THREAD | yes , ">" > | yes > > > > > ----------------------------------------|--------------------------- > |-------------------------- > > > > SUSPEND_ALL. | yes, ">". > | yes > > > > > > > > Could you please say is it OK for you or you want > that the location was printed only for SUSPEND_ALL case? Or probably just > leave all behavior unchanged and close the bug as "not an issue"? > > > > > > > > Regarding settable prompt... As I understand Gary's > original concern was that waiting in tests for a simple prompt " > " > (>  ) could be unreliable if this substring somehow appears in the > output of the test program and the suggestion was to use more specific > patterns for the cases when the full prompt (thread_name[frame_index]) is > not printed ( e.g. when the current thread is not set). However, we need > somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it > would keep waiting for the full prompt and fail with the timeout. Probably > I am missing something here... > > > > > > > > > > > > Thanks! > > > > > > > > Best regards, > > > > Daniil > > > > > > > > > > > > > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" < > gary.adams at oracle.com> wrote: > > > > > > > > It's not clear to me if the omitted location > information for the non > > > > stopping > > > > cases was intentional or not. It may be > sufficient to know that the > > > > event fired > > > > without the extra information. > > > > > > > > I don't think a settable prompt is required > either. There are plenty of > > > > jdb commands that > > > > could be used with the wait for message in tests > that need to > > > > synchronize at a specific > > > > point in the test sequence. > > > > > > > > I don't think we see wait for simple prompt in > any of the tests, because it > > > > is not reliable enough. > > > > > > > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > > > > Hi Gary, > > > > > > > > > > Currently when a breakpoint is hit the message > "Breakpoint hit:" is printed in the debugger output. What we do in this fix > we just add more information about what exact breakpoint is hit. Do you > suggest we should not print this line at all if suspend policy is > SUSPEND_NONE? If so then it is not clear what is the use of the command > "stop go ..." would be. Regarding waiting for the simple prompt, we could > change JDbCommand to have a field to store a prompt pattern and use this > pattern (if it was set) when waiting for command to complete. In tests when > required we would set the pattern in JdbCommand to more complicated one > matching a specific output we are expecting at this particular step. Do you > think it would be a better approach? > > > > > > > > > > Thanks! > > > > > > > > > > Best regards, > > > > > Daniil > > > > > > > > > > > > > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" < > gary.adams at oracle.com> wrote: > > > > > > > > > > I'm not certain that we should be printing > locations or prompts for > > > > > events when the vm has not been suspended. > This looks OK for the > > > > > simple test case we are working on here, > but in real life there may > > > > > be a lot more output produced. > > > > > > > > > > The user has to select a specific thread > before additional commands > > > > > can be performed in the correct context. > e.g. threads, thread n, where, ... > > > > > So the information is available to the > user. It doesn't have to be > > > > > produced at the time the event is > processed. > > > > > > > > > > I'm uncomfortable putting too much trust > in waiting for the simple prompt, > > > > > because there is too great a chance of > false positives on such a small > > > > > marker. > > > > > > > > > > > > > > > On 10/17/18, 8: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"< > daniil.x.titov at oracle.com> 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/ > > > > > > >>> >> < > http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.02/> > > > > > > >>> >> > > > > > > >>> >> Issue: > https://bugs.openjdk.java.net/browse/JDK-8211736 > > > > > > >>> >> > > > > > > >>> >> Best regards, > > > > > > >>> >> > > > > > > >>> >> --Daniil > > > > > > >>> >> > > > > > > >>> >> *From: *JC Beyler< > jcbeyler at google.com> > > > > > > >>> >> *Date: *Thursday, > October 11, 2018 at 7:17 PM > > > > > > >>> >> *To: *< > daniil.x.titov at oracle.com> > > > > > > >>> >> *Cc: *< > serviceability-dev at openjdk.java.net> > > > > > > >>> >> *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 > > > > > > >>> > > > > > > >>> >> > > > > > > >>> < > http://cr.openjdk.java.net/%7Edtitov/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 > > > > > > >>> >> < > daniil.x.titov at oracle.com > > > > > > >>> daniil.x.titov at oracle.com>> 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 > > > > > > >>> >> < > http://cr.openjdk.java.net/%7Edtitov/8211736/webrev.01> > > > > > > >>> >> Issue: > https://bugs.openjdk.java.net/browse/JDK-8211736 > > > > > > >>> >> > > > > > > >>> >> Thanks! > > > > > > >>> >> --Daniil > > > > > > >>> >> > > > > > > >>> >> > > > > > > >>> >> > > > > > > >>> >> -- > > > > > > >>> >> > > > > > > >>> >> Thanks, > > > > > > >>> >> > > > > > > >>> >> Jc > > > > > > >>> >> > > > > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Oct 23 02:52:51 2018 From: jcbeyler at google.com (JC Beyler) Date: Mon, 22 Oct 2018 19:52:51 -0700 Subject: RFR JDK-8212151: jdi/ExclusiveBind.java times out due to "bind failed: Address already in use" on Solaris-X64 In-Reply-To: <958d7054-4b22-7fbb-bac1-87dd0c083f69@oracle.com> References: <0209ac5a-911d-3272-166d-af727a98a2c0@oracle.com> <523f6153-3376-edda-1786-41cfff3dbdd4@oracle.com> <958d7054-4b22-7fbb-bac1-87dd0c083f69@oracle.com> Message-ID: LGTM Alex, thanks! Jc On Mon, Oct 22, 2018 at 5:24 PM Alex Menkov wrote: > Hi Jc, > > new webrev: > http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev.02/ > > --alex > > On 10/20/2018 20:29, JC Beyler wrote: > > Hi Alex, > > > > It looks really good to me now. The test and JdbTest are now easier to > > read because we do not have the noise of the debuggee trying to attach. > > > > A few nits: > > - Small nit really is the fact that the javadoc for Debuggee states > > two usages and JdbTest does not use either :) > > - You put a few get methods in Debuggee that are seemingly not used > > anywhere, we could add them later if need be and not have them now? > > > > Thanks for this, I think it's really better in the long run to have this > > in one centralized spot, > > Jc > > > > On Fri, Oct 19, 2018 at 3:56 PM Alex Menkov > > wrote: > > > > Hi Jc, > > > > Updated fix: > > http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev.01/ > > > > Moved shared code to new Debuggee class. > > > > --alex > > > > On 10/19/2018 10:34, JC Beyler wrote: > > > Hi Alex, > > > > > > I remember seeing this same code so went looking for it and saw > > it in > > > JdbTest.java (you added it here it seems: > > > http://hg.openjdk.java.net/jdk/jdk/rev/083e731da31a). > > > > > > I have two few questions: > > > - Does it make sense to put this code in a helper method? > > > - The code you added in JdbTest.java does not do the adjusted > > time > > > for 30 it seems, is that normal? > > > > > > Thanks, > > > Jc > > > > > > On Fri, Oct 19, 2018 at 9:59 AM Alex Menkov > > > > > > >> wrote: > > > > > > Hi all, > > > > > > jira: https://bugs.openjdk.java.net/browse/JDK-8212151 > > > webrev: > > http://cr.openjdk.java.net/~amenkov/exclusiveBind/webrev/ > > > > > > > > > > > The fix updates the test to allow debuggee to select > > available port > > > instead of using error-prone "getFreePort" approach. > > > > > > --alex > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From ioi.lam at oracle.com Tue Oct 23 04:09:41 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 22 Oct 2018 21:09:41 -0700 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: <75b95743-86be-860d-89b8-7e0b5f64ed43@oracle.com> References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> <75b95743-86be-860d-89b8-7e0b5f64ed43@oracle.com> Message-ID: On 10/22/18 10:25 AM, Lois Foltan wrote: > On 10/22/2018 1:49 AM, Ioi Lam wrote: > >> Hi David, >> >> Thanks for the review. Updated webrev: >> >> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ >> >> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ >> > > Hi Ioi, > > Looks good.? A couple of comments: > > classfile/systemDictionary.cpp > - line#1975 - My preference is to declare the variable sid outside the > for statement and compare sid == 0 within the for loop conditional. Do you mean this? bool SystemDictionary::is_well_known_klass(Symbol* class_name) { ? int sid; ? for (int i = 0; (sid = wk_init_info[i]) != 0; i++) { ??? Symbol* symbol = vmSymbols::symbol_at((vmSymbols::SID)sid); ??? if (class_name == symbol) { ????? return true; ??? } ? } ? return false; } > - line#1981 - can you use class_name->fast_compare(symbol) for the > equality check? > The comments around fast_compare says it's for vtable sorting only. > memory/heapShared.cpp > - line#422 could be a ResourceMark rm(THREAD); > Fixed. Thanks - Ioi > Thanks, > Lois > >> >> More comments below: >> >> >> >> On 10/21/18 6:57 PM, David Holmes wrote: >>> Hi Ioi, >>> >>> Generally seems okay. >>> >>> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>>> Re-sending to the correct mailing lists. Please disregard the other >>>> email. >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>>> >>>> Hi, >>>> >>>> CDS has various built-in assumptions that classes loaded by >>>> SystemDictionary::resolve_well_known_classes must not be replaced >>>> by JVMTI ClassFileLoadHook during run time, including >>>> >>>> - field offsets computed in JavaClasses::compute_offsets >>>> - the layout of the strings objects in the shared strings table >>>> >>>> The "well-known" classes can be replaced by ClassFileLoadHook only >>>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>>> fix is to disable CDS under this condition. >>> >>> I'm a little unclear why we have to iterate JvmtiEnv list when this >>> has to be checked during JVMTI_PHASE_PRIMORDIAL? >>> >> I think you are asking about this new function? I don't like the name >> "early_class_hook_env()". Maybe I should change it to >> "has_early_class_hook_env()"? >> >> >> bool JvmtiExport::early_class_hook_env() { >> ? JvmtiEnvIterator it; >> ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >> ??? if (env->early_class_hook_env()) { >> ????? return true; >> ??? } >> ? } >> ? return false; >> } >> >> This function matches condition in the existing code that would call >> into ClassFileLoadHook: >> >> class JvmtiClassFileLoadHookPoster { >> ?... >> ? void post_all_envs() { >> ??? JvmtiEnvIterator it; >> ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >> ? ? ??? .. >> ??????? post_to_env(env, true); >> ??? } >> ? } >> ... >> ? void post_to_env(JvmtiEnv* env, bool caching_needed) { >> ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && >> !env->early_class_hook_env()) { >> ????? return; >> ??? } >> >> >> post_all_envs() is called just before a class is about to be loaded >> in the JVM. So if *any* env->early_class_hook_env() returns true, >> there's a chance that it will replace a well-known class.So, as a >> preventive measure, CDS will be disabled. >> >> >> >>>> I have added a few test cases to try to replace shared classes, >>>> including well-known classes and other classes. See >>>> comments in ReplaceCriticalClasses.java for details. >>>> >>>> As a clean up, I also renamed all use of "preloaded" in >>>> the source code to "well-known". They refer to the same thing >>>> in HotSpot, so there's no need to use 2 terms. Also, The word >>>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>>> and could be confused with what CDS does during archive dump time. >>> >>> A few specific comments: >>> >>> src/hotspot/share/classfile/systemDictionary.cpp >>> >>> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >>> +?? for (int i = 0; ; i++) { >>> +???? int sid = wk_init_info[i]; >>> +???? if (sid == 0) { >>> +?????? break; >>> +???? } >>> >>> I take it a zero value is a guaranteed end-of-list sentinel? >>> >> >> Yes. The array is defined just a few lines above: >> >> static const short wk_init_info[] = { >> ? #define WK_KLASS_INIT_INFO(name, symbol) \ >> ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), >> >> ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) >> ? #undef WK_KLASS_INIT_INFO >> ? 0 >> }; >> >> Also, >> >> class vmSymbols: AllStatic { >> ? enum SID { >> ??? NO_SID = 0, >> ??? .... >> >> >> >>> + for (int i=FIRST_WKID; i>> >>> Style nit: need spaces around = and < >>> >> >> Fixed. >> >>> --- >>> >>> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >>> >>> >>> New file should have current copyright year only. >>> >> Fixed. >> >>> ?31? * @comment CDS should not be disabled -- these critical classes >>> will be replaced because JvmtiExport::early_class_hook_env() is true. >>> >>> Comment seems contradictory: if we replace critical classes then CDS >>> should be disabled right?? >>> >> Fixed. >> >>> I expected to see tests that checked for: >>> >>> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >>> >>> in the output. ?? >>> >> >> It would have been easy if jtreg lets you check the output of @run >> easily. Instead, your innocent suggestion has turned into 150+ lines >> of new code :-( Maybe "let's write all shell tests in Java" isn't >> such a great idea after all. >> >> >> Now the test checks that whether CDS is indeed disabled, whether the >> affected class is loaded from the shared archive, etc. >> >> Thanks >> - Ioi >> >>> Thanks, >>> David >>> >>> >>>> >>>> ?> In early e-mails Jiangli wrote: >>>> ?> >>>> ?> We should consider including more classes from the default >>>> classlist >>>> ?> in the test. Archived classes loaded during both 'early' phase >>>> and after >>>> ?> should be tested. >>>> >>>> Done. >>>> >>>> >>>> ?> For future optimizations, we might want to prevent loading >>>> additional >>>> ?> shared classes if any of the archived system classes is changed. >>>> >>>> What's the benefit of doing this? Today we already stop loading a >>>> shared >>>> class if its super class was not loaded from the archive. >>>> >>>> >>>> Thanks >>>> - Ioi >>>> >> > From mandy.chung at oracle.com Tue Oct 23 05:34:05 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 22 Oct 2018 22:34:05 -0700 Subject: OpenDataException thrown when constructing CompositeData for ThreadInfo In-Reply-To: References: Message-ID: <60adbb17-e1e5-5223-099c-68f064d03838@oracle.com> Hi Sven, I created https://bugs.openjdk.java.net/browse/JDK-8212795 to track this issue.?? NB is using the internal API that is unused in JDK and hence no test uncovers this regression. I have a patch that passes a map of key to values to CompositeDataSupport rather than passing two synchronized arrays which is error prone. ? Can you help verify if this patch properly fixes NB issue: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/ I will also work on a test in the meantime. Mandy On 10/21/18 5:38 PM, Sven Reimers wrote: > Hi, > > one more problem to go > > After applying the proposed fix for the > ThreadINfoCompositeData.compositeTyoe() the following exception is raised: > > java.lang.reflect.InvocationTargetException > 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 > org.netbeans.modules.sampler.SamplesOutputStream.toCompositeData(SamplesOutputStream.java:178) > at > org.netbeans.modules.sampler.SamplesOutputStream.access$400(SamplesOutputStream.java:44) > at > org.netbeans.modules.sampler.SamplesOutputStream$Sample.writeToStream(SamplesOutputStream.java:285) > at > org.netbeans.modules.sampler.SamplesOutputStream$Sample.access$300(SamplesOutputStream.java:253) > at > org.netbeans.modules.sampler.SamplesOutputStream.close(SamplesOutputStream.java:202) > at org.netbeans.modules.sampler.Sampler.stopSampling(Sampler.java:231) > at org.netbeans.modules.sampler.Sampler.stop(Sampler.java:207) > at > org.netbeans.core.ui.sampler.SelfSamplerAction$1.doInBackground(SelfSamplerAction.java:90) > at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:835) > Caused by: java.lang.AssertionError: > javax.management.openmbean.OpenDataException: Argument value of wrong > type for item lockInfo: value false, type > javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) > at > java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:135) > at > java.management/sun.management.ThreadInfoCompositeData.toCompositeData(ThreadInfoCompositeData.java:72) > ... 18 more > Caused by: javax.management.openmbean.OpenDataException: Argument > value of wrong type for item lockInfo: value false, type > javax.management.openmbean.CompositeType(name=java.lang.management.LockInfo,items=((itemName=className,itemType=javax.management.openmbean.SimpleType(name=java.lang.String)),(itemName=identityHashCode,itemType=javax.management.openmbean.SimpleType(name=java.lang.Integer)))) > at > java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:235) > at > java.management/javax.management.openmbean.CompositeDataSupport.(CompositeDataSupport.java:118) > at > java.management/sun.management.ThreadInfoCompositeData.getCompositeData(ThreadInfoCompositeData.java:130) > ... 19 more > > Seems the sequence of values is broken for ThreadInfoCompoositeData also. > > Changing the sequence so that lockInfoData is after isNative fixes the > problem: > > ? ? ? ?final Object[] threadInfoItemValues = { > ? ? ? ? ? ? threadInfo.getThreadId(), > ? ? ? ? ? ? threadInfo.getThreadName(), > ? ? ? ? ? ? threadInfo.getThreadState().name(), > ? ? ? ? ? ? threadInfo.getBlockedTime(), > ? ? ? ? ? ? threadInfo.getBlockedCount(), > ? ? ? ? ? ? threadInfo.getWaitedTime(), > ? ? ? ? ? ? threadInfo.getWaitedCount(), > ? ? ? ? ? ? threadInfo.getLockName(), > ? ? ? ? ? ? threadInfo.getLockOwnerId(), > ? ? ? ? ? ? threadInfo.getLockOwnerName(), > ? ? ? ? ? ? stackTraceData, > ? ? ? ? ? ? threadInfo.isSuspended(), > ? ? ? ? ? ? threadInfo.isInNative(), > ? ? ? ? ? ? lockInfoData, > ? ? ? ? ? ? lockedMonitorsData, > ? ? ? ? ? ? lockedSyncsData, > ? ? ? ? ? ? threadInfo.isDaemon(), > ? ? ? ? ? ? threadInfo.getPriority(), > ? ? ? ? }; > > With both of this fixes in place I can finally get the self sampling > in NetBeans to work on JDK 12.. (and 11) > > Thanks for looking into this > > -Sven > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Oct 23 07:21:14 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Oct 2018 00:21:14 -0700 Subject: The failure In-Reply-To: <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> Message-ID: <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Oct 23 07:43:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Oct 2018 17:43:16 +1000 Subject: The failure In-Reply-To: <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> Message-ID: <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> Hi Serguei, The JvmtiThreadState_lock is always acquired with safepoint checks enabled, so all JavaThreads blocked trying to acquire it will be _thread_blocked and so safepoint-safe and so won't be holding up the safepoint. David On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: > Hi, > > I've added the seviceability-dev mailing list. > It can be interesting for the SVC folks. :) > > > On 10/22/18 22:14, Leonid Mesnik wrote: >> Hi >> >> Seems last version also crashes with 2 other different symptoms. >> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >> >> >> >> Also it might hangs with ?stack attached. ?Seems that test might be >> blocked because it invoke 2 jvmti methods. Can jvmti agent invoke >> jvmti methods from different threads? > > Yes, in general. > However, you have to be careful when using debugging features. > Below, one thread is enabling single stepping while another thread is > being suspended. > Both are blocked at a safepoint which is Okay in general but not Okay if > they hold any lock. > For instance, the thread #152 is holding the monitor JvmtiThreadState. > > Also, I see a couple of more threads that are interesting as well: > > Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): > #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1? 0x00002ae393ba8d63 in os::PlatformEvent::park > (this=this at entry=0x2ae3984c9100) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 > #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984c7800, > this=0x2ae398024f10) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 > #5? Monitor::lock (this=this at entry=0x2ae398024f10) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 > #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, > this=) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 > #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 > #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method > (task=task at entry=0x2ae48800ff40) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 > #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 > #10 0x00002ae393d7338a in JavaThread::thread_main_inner > (this=this at entry=0x2ae3984c7800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 > #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 > #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c7800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 > #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 > #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 > > Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): > #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1? 0x00002ae393ba8d63 in os::PlatformEvent::park > (this=this at entry=0x2ae3984cbb00) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 > #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, > this=0x2ae398024f10) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 > #5? Monitor::lock (this=this at entry=0x2ae398024f10) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 > #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, > this=) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 > #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 > #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method > (task=task at entry=0x2ae49c00a670) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 > #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 > #10 0x00002ae393d7338a in JavaThread::thread_main_inner > (this=this at entry=0x2ae3984ca800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 > #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 > #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984ca800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 > #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 > #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 > > Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): > #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1? 0x00002ae393ba8d63 in os::PlatformEvent::park > (this=this at entry=0x2ae460061c00) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 > #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, > this=0x2ae398024f10) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 > #5? Monitor::lock (this=this at entry=0x2ae398024f10) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 > #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, > this=) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 > #7? thread_started (thread=0x2ae4600c2800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 > #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 > #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start > (thread=thread at entry=0x2ae4600c2800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 > #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 > #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c2800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 > #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 > #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 > > > These two thread are blocked on the monitor JvmtiThreadState_lock in the > function ciEnv::cache_jvmti_state(). > Also, there are many threads (like #51) that are executing > JvmtiExport::post_thread_start and blocked on the same monitor. > > > Now, the question is why this safepoint can not start? > What thread is blocking it? Or in reverse, what thread this safepoint is > waiting for? > > I think, this safepoint operation is waiting for all threads that are > blocked on the JvmtiThreadState_lock. > > Conclusion: > > The deadlock is: > > Thread #152: > ? - grabbed the monitor JvmtiThreadState_lock > ? - blocked in the VM_GetCurrentLocation in the function > JvmtiEnvThreadState::reset_current_location() > > Many other threads: > ? - blocked on the monitor JvmtiThreadState_lock > ? - can not reach the blocked at a safepoint state (all threads have to > reach this state for this safepoint to happen) > > It seems to me, this is a bug which has to be filed. > > My guess is that this will stop to reproduce after if you turn off the > single stepping for thread #152. > Please, let me know about the results. > > >> Assuming that crashes look like VM bugs I think it make sense to >> integrate jvmti changes but *don't* enabled jvmti module by default. > > This one is a deadlock. > However, the root cause is a race condition that can potentially result > in both deadlocks and crashes. > So, I'm curious if you observed crashes as well. > > >> And add to more tests with jvmti enabled. >> So anyone could easily run them to reproduce crashes. ?This test would >> be out of CI to don't introduce any bugs. Does it make sense? >> >> Consider hang - I think that it might be product bug since I don't see >> any locking on my monitors. But I am not sure. Is it possible that any >> my code jvmti agent prevent VM to get into safepoint? >> Could we discuss it tomorrow or his week when you have a time? > > Yes, of course. > Let's find some time tomorrow. > > >> Any suggestion how to diagnose deadlock would be great. > > Analysis of stack traces is needed. > It is non-trivial in this particular case as there are so many threads > executed at the same time. > > >> Part of stack trace with 2 my threads only: >> >> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >> (this=this at entry=0x2ae454005800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >> 8 >> #4 ?0x00002ae393b51f2e in Monitor::wait >> (this=this at entry=0x2ae398023c10, no_safepoint_check=, >> timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at en\ >> try=false) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >> #5 ?0x00002ae393de7867 in VMThread::execute >> (op=op at entry=0x2ae4940ffb10) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >> (this=this at entry=0x2ae3985f2000) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >> (java_thread=java_thread at entry=0x2ae3985f2000) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >> 47 >> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >> nv.cpp:955 >> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >> thread=0x2ae49929fdf8) at >> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >> /jvmtiEnter.cpp:527 >> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >> env=, p=) at >> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >> hensink/process/stress/modules/libJvmtiStressModule.c:274 >> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >> #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, >> __the_thread__=) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >> (this=this at entry=0x2ae454004800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >> #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) >> at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >> >> >> >> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >> (this=this at entry=0x2ae3985e7400) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >> 8 >> #4 ?0x00002ae393b51f2e in Monitor::wait >> (this=this at entry=0x2ae398023c10, no_safepoint_check=, >> timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at en\ >> try=false) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >> #6 ?0x00002ae3939965f3 in JvmtiEnvThreadState::reset_current_location >> (this=this at entry=0x2ae6bc000d80, >> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >> enabled=enabled at entry=tr\ >> ue) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >> r.cpp:490 >> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >> (state=state at entry=0x2ae6bc000cd0) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >> :523 >> #9 ?0x00002ae393998168 in >> JvmtiEventControllerPrivate::recompute_enabled () at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >> re/prims/jvmtiEventController.cpp:818 >> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >> hotspot/share/prims/jvmtiEventController.cpp:963 >> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >> nt_thread=event_thread at entry=0x0) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, event_thread=event_\ >> thread at entry=0x0) at >> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >> #14 0x00002ae394d97989 in enable_events () at >> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >> #15 0x00002ae394d98070 in >> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >> (env=, this=) at /scratch/lmesnik/ws/h\ >> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >> #16 0x00002ae3a43ef257 in ?? () >> #17 0x00002ae3a43eede1 in ?? () >> #18 0x00002ae42705f878 in ?? () >> #19 0x00002ae40ad334e0 in ?? () >> #20 0x00002ae42705f8e0 in ?? () >> #21 0x00002ae40ad33c68 in ?? () >> #22 0x0000000000000000 in ?? () > > Thanks, > Serguei > >> >> >> >> Leonid >> >> >>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>> wrote: >>> >>> Hi Leonid, >>> >>> There is an existing bug: >>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>> Hi >>>> >>>> During fixing kitchensink I get >>>> assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth >>>> out of sync >>>> >>>> Do you know if i might be bug in my jvmti agent? >>>> >>>> Leonid >>>> >>>> >>>> # >>>> # A fatal error has been detected by the Java Runtime Environment: >>>> # >>>> # ?Internal Error >>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>> pid=13926, tid=13962 >>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>> cur_stack_depth out of sync >>>> # >>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug >>>> build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, >>>> tiered, compressed oops, g1 gc, linux-amd64) >>>> # Core dump will be written. Default location: Core dumps may be >>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P >>>> %I %h" (or dumping to >>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>> # >>>> # If you would like to submit a bug report, please visit: >>>> # http://bugreport.java.com/bugreport/crash.jsp >>>> # >>>> >>>> --------------- ?S U M M A R Y ------------ >>>> >>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false >>>> -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal -XX:+StartAttachListener >>>> -XX:NativeMemoryTracking=detail -XX:+FlightRecorder >>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>> applications.kitchensink.process.stress.Main >>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>> >>>> Host: scaaa118.us.oracle.com , >>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >>>> Linux Server release 7.3 >>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d 0h >>>> 0m 31s) >>>> >>>> --------------- ?T H R E A D ?--------------- >>>> >>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" [stack: >>>> 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>> _threads_hazard_ptr=0x00002af4ac090eb0, _nested_threads_hazard_ptr_cnt=0 >>>> >>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>> ?sp=0x00002af44f208720, ?free space=1017k >>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>> j=interpreted, Vv=VM code, C=native code) >>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char const*, >>>> char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, >>>> char const*, int, unsigned long)+0x2c3 >>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, void*, >>>> char const*, int, char const*, char const*, __va_list_tag*)+0x2f >>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>> const*, char const*, ...)+0x100 >>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>> V ?[libjvm.so+0x11f3257] >>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>> V ?[libjvm.so+0x19040be] >>>> ?VMThread::evaluate_operation(VM_Operation*) [clone .constprop.51]+0x18e >>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>> >>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>> safepoint, requested by thread 0x00002af4dc008800 >>> >>> >> > From serguei.spitsyn at oracle.com Tue Oct 23 07:58:11 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Oct 2018 00:58:11 -0700 Subject: The failure In-Reply-To: <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> Message-ID: <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> Hi David, You are right, thanks. It means, this deadlock needs more analysis. For completeness, the stack traces are in attachments. Thanks, Serguei On 10/23/18 00:43, David Holmes wrote: > Hi Serguei, > > The JvmtiThreadState_lock is always acquired with safepoint checks > enabled, so all JavaThreads blocked trying to acquire it will be > _thread_blocked and so safepoint-safe and so won't be holding up the > safepoint. > > David > > On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >> Hi, >> >> I've added the seviceability-dev mailing list. >> It can be interesting for the SVC folks. :) >> >> >> On 10/22/18 22:14, Leonid Mesnik wrote: >>> Hi >>> >>> Seems last version also crashes with 2 other different symptoms. >>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>> >>> >>> >>> >>> Also it might hangs with ?stack attached. ?Seems that test might be >>> blocked because it invoke 2 jvmti methods. Can jvmti agent invoke >>> jvmti methods from different threads? >> >> Yes, in general. >> However, you have to be careful when using debugging features. >> Below, one thread is enabling single stepping while another thread is >> being suspended. >> Both are blocked at a safepoint which is Okay in general but not Okay >> if they hold any lock. >> For instance, the thread #152 is holding the monitor JvmtiThreadState. >> >> Also, I see a couple of more threads that are interesting as well: >> >> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >> (this=this at entry=0x2ae3984c9100) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >> >> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984c7800, >> this=0x2ae398024f10) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >> this=) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >> (task=task at entry=0x2ae48800ff40) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >> (this=this at entry=0x2ae3984c7800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c7800) >> at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >> >> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >> (this=this at entry=0x2ae3984cbb00) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >> >> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >> this=0x2ae398024f10) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >> this=) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >> (task=task at entry=0x2ae49c00a670) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >> (this=this at entry=0x2ae3984ca800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984ca800) >> at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >> >> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >> (this=this at entry=0x2ae460061c00) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >> >> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >> this=0x2ae398024f10) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >> this=) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >> #7? thread_started (thread=0x2ae4600c2800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >> (thread=thread at entry=0x2ae4600c2800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >> #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c2800) >> at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >> >> >> These two thread are blocked on the monitor JvmtiThreadState_lock in >> the function ciEnv::cache_jvmti_state(). >> Also, there are many threads (like #51) that are executing >> JvmtiExport::post_thread_start and blocked on the same monitor. >> >> >> Now, the question is why this safepoint can not start? >> What thread is blocking it? Or in reverse, what thread this safepoint >> is waiting for? >> >> I think, this safepoint operation is waiting for all threads that are >> blocked on the JvmtiThreadState_lock. >> >> Conclusion: >> >> The deadlock is: >> >> Thread #152: >> ?? - grabbed the monitor JvmtiThreadState_lock >> ?? - blocked in the VM_GetCurrentLocation in the function >> JvmtiEnvThreadState::reset_current_location() >> >> Many other threads: >> ?? - blocked on the monitor JvmtiThreadState_lock >> ?? - can not reach the blocked at a safepoint state (all threads have >> to reach this state for this safepoint to happen) >> >> It seems to me, this is a bug which has to be filed. >> >> My guess is that this will stop to reproduce after if you turn off >> the single stepping for thread #152. >> Please, let me know about the results. >> >> >>> Assuming that crashes look like VM bugs I think it make sense to >>> integrate jvmti changes but *don't* enabled jvmti module by default. >> >> This one is a deadlock. >> However, the root cause is a race condition that can potentially >> result in both deadlocks and crashes. >> So, I'm curious if you observed crashes as well. >> >> >>> And add to more tests with jvmti enabled. >>> So anyone could easily run them to reproduce crashes. ?This test >>> would be out of CI to don't introduce any bugs. Does it make sense? >>> >>> Consider hang - I think that it might be product bug since I don't >>> see any locking on my monitors. But I am not sure. Is it possible >>> that any my code jvmti agent prevent VM to get into safepoint? >>> Could we discuss it tomorrow or his week when you have a time? >> >> Yes, of course. >> Let's find some time tomorrow. >> >> >>> Any suggestion how to diagnose deadlock would be great. >> >> Analysis of stack traces is needed. >> It is non-trivial in this particular case as there are so many >> threads executed at the same time. >> >> >>> Part of stack trace with 2 my threads only: >>> >>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>> (this=this at entry=0x2ae454005800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>> 8 >>> #4 ?0x00002ae393b51f2e in Monitor::wait >>> (this=this at entry=0x2ae398023c10, no_safepoint_check=, >>> timeout=timeout at entry=0, >>> as_suspend_equivalent=as_suspend_equivalent at en\ >>> try=false) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>> #5 ?0x00002ae393de7867 in VMThread::execute >>> (op=op at entry=0x2ae4940ffb10) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>> (this=this at entry=0x2ae3985f2000) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>> 47 >>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>> nv.cpp:955 >>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >>> thread=0x2ae49929fdf8) at >>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>> /jvmtiEnter.cpp:527 >>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>> env=, p=) at >>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) >>> at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>> #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, >>> __the_thread__=) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>> (this=this at entry=0x2ae454004800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>> #15 0x00002ae393ba0070 in thread_native_entry >>> (thread=0x2ae454004800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>> >>> >>> >>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>> (this=this at entry=0x2ae3985e7400) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>> 8 >>> #4 ?0x00002ae393b51f2e in Monitor::wait >>> (this=this at entry=0x2ae398023c10, no_safepoint_check=, >>> timeout=timeout at entry=0, >>> as_suspend_equivalent=as_suspend_equivalent at en\ >>> try=false) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>> #6 ?0x00002ae3939965f3 in >>> JvmtiEnvThreadState::reset_current_location >>> (this=this at entry=0x2ae6bc000d80, >>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>> enabled=enabled at entry=tr\ >>> ue) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>> r.cpp:490 >>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>> (state=state at entry=0x2ae6bc000cd0) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>> :523 >>> #9 ?0x00002ae393998168 in >>> JvmtiEventControllerPrivate::recompute_enabled () at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) >>> at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>> re/prims/jvmtiEventController.cpp:818 >>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>> hotspot/share/prims/jvmtiEventController.cpp:963 >>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>> nt_thread=event_thread at entry=0x0) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>> event_thread=event_\ >>> thread at entry=0x0) at >>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>> #14 0x00002ae394d97989 in enable_events () at >>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>> #15 0x00002ae394d98070 in >>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>> (env=, this=) at /scratch/lmesnik/ws/h\ >>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>> >>> #16 0x00002ae3a43ef257 in ?? () >>> #17 0x00002ae3a43eede1 in ?? () >>> #18 0x00002ae42705f878 in ?? () >>> #19 0x00002ae40ad334e0 in ?? () >>> #20 0x00002ae42705f8e0 in ?? () >>> #21 0x00002ae40ad33c68 in ?? () >>> #22 0x0000000000000000 in ?? () >> >> Thanks, >> Serguei >> >>> >>> >>> >>> Leonid >>> >>> >>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>> wrote: >>>> >>>> Hi Leonid, >>>> >>>> There is an existing bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> During fixing kitchensink I get >>>>> assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth >>>>> out of sync >>>>> >>>>> Do you know if i might be bug in my jvmti agent? >>>>> >>>>> Leonid >>>>> >>>>> >>>>> # >>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>> # >>>>> # ?Internal Error >>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>> pid=13926, tid=13962 >>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>> cur_stack_depth out of sync >>>>> # >>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug >>>>> build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, >>>>> tiered, compressed oops, g1 gc, linux-amd64) >>>>> # Core dump will be written. Default location: Core dumps may be >>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P >>>>> %I %h" (or dumping to >>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>> # >>>>> # If you would like to submit a bug report, please visit: >>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>> # >>>>> >>>>> --------------- ?S U M M A R Y ------------ >>>>> >>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false >>>>> -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>> -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED >>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>> applications.kitchensink.process.stress.Main >>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>> >>>>> Host: scaaa118.us.oracle.com , >>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >>>>> Linux Server release 7.3 >>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d 0h >>>>> 0m 31s) >>>>> >>>>> --------------- ?T H R E A D ?--------------- >>>>> >>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" [stack: >>>>> 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>> _nested_threads_hazard_ptr_cnt=0 >>>>> >>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>> j=interpreted, Vv=VM code, C=native code) >>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, void*, >>>>> char const*, int, char const*, char const*, __va_list_tag*)+0x2f >>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>> const*, char const*, ...)+0x100 >>>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>> V ?[libjvm.so+0x11f3257] >>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>> V ?[libjvm.so+0x19040be] >>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>> .constprop.51]+0x18e >>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>> >>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>> safepoint, requested by thread 0x00002af4dc008800 >>>> >>>> >>> >> -------------- next part -------------- [New LWP 29727] [New LWP 29726] [New LWP 29725] [New LWP 29724] [New LWP 29723] [New LWP 29722] [New LWP 29721] [New LWP 29720] [New LWP 29719] [New LWP 29718] [New LWP 29717] [New LWP 29716] [New LWP 29715] [New LWP 29714] [New LWP 29713] [New LWP 29712] [New LWP 29711] [New LWP 29710] [New LWP 29709] [New LWP 29708] [New LWP 29707] [New LWP 29706] [New LWP 29705] [New LWP 29704] [New LWP 29703] [New LWP 29702] [New LWP 29701] [New LWP 29700] [New LWP 29699] [New LWP 29698] [New LWP 29697] [New LWP 29696] [New LWP 29695] [New LWP 29694] [New LWP 29693] [New LWP 29692] [New LWP 29691] [New LWP 29690] [New LWP 29689] [New LWP 29688] [New LWP 29687] [New LWP 29686] [New LWP 29685] [New LWP 29684] [New LWP 29683] [New LWP 29682] [New LWP 29681] [New LWP 29680] [New LWP 29679] [New LWP 29678] [New LWP 29654] [New LWP 29653] [New LWP 29652] [New LWP 29651] [New LWP 29650] [New LWP 29649] [New LWP 29648] [New LWP 29647] [New LWP 29646] [New LWP 29645] [New LWP 29644] [New LWP 29643] [New LWP 29642] [New LWP 29641] [New LWP 29640] [New LWP 29639] [New LWP 29638] [New LWP 29637] [New LWP 29636] [New LWP 29635] [New LWP 29634] [New LWP 29633] [New LWP 29632] [New LWP 29631] [New LWP 29630] [New LWP 29629] [New LWP 29628] [New LWP 29627] [New LWP 29626] [New LWP 29625] [New LWP 29624] [New LWP 29623] [New LWP 29622] [New LWP 29621] [New LWP 29620] [New LWP 29619] [New LWP 29618] [New LWP 29617] [New LWP 29616] [New LWP 29615] [New LWP 29614] [New LWP 29613] [New LWP 29612] [New LWP 29611] [New LWP 29609] [New LWP 29608] [New LWP 29607] [New LWP 29606] [New LWP 29605] [New LWP 29604] [New LWP 29270] [New LWP 29026] [New LWP 29024] [New LWP 28995] [New LWP 28989] [New LWP 28912] [New LWP 28910] [New LWP 28899] [New LWP 28428] [New LWP 28427] [New LWP 28426] [New LWP 28412] [New LWP 28411] [New LWP 28410] [New LWP 28409] [New LWP 28408] [New LWP 28407] [New LWP 28406] [New LWP 28405] [New LWP 28404] [New LWP 28403] [New LWP 28402] [New LWP 28401] [New LWP 28400] [New LWP 28399] [New LWP 28398] [New LWP 28397] [New LWP 28396] [New LWP 28395] [New LWP 28394] [New LWP 28393] [New LWP 28392] [New LWP 28391] [New LWP 28389] [New LWP 28023] [New LWP 28010] [New LWP 28009] [New LWP 28008] [New LWP 28007] [New LWP 28006] [New LWP 28005] [New LWP 28004] [New LWP 28003] [New LWP 28002] [New LWP 28001] [New LWP 28000] [New LWP 27999] [New LWP 27998] [New LWP 27997] [New LWP 27996] [New LWP 27995] [New LWP 27994] [New LWP 27983] [New LWP 27982] [New LWP 27981] [New LWP 27966] [New LWP 27963] [New LWP 27962] [New LWP 27961] [New LWP 27960] [New LWP 27951] [New LWP 27950] [New LWP 27948] [New LWP 27934] [New LWP 27933] [New LWP 27932] [New LWP 27931] [New LWP 27930] [New LWP 27916] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00002ae3927b2f57 in pthread_join () from /lib64/libpthread.so.0 Thread 170 (Thread 0x2ae3922b0700 (LWP 27916)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae398029c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae41c008f00, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae398028800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae398028800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae3922af800, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00000000985e6001 in ?? () #7 0x00002ae398028800 in ?? () #8 0x0000000000000000 in ?? () Thread 169 (Thread 0x2ae3969e2700 (LWP 27930)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae39805d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae39805d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae39805d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 168 (Thread 0x2ae3b3b89700 (LWP 27931)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3980d3500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3980d3500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398020710, Self=Self at entry=0x2ae3980d2000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x2ae398020710, no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393719ce4 in sleep_before_next_cycle (this=0x2ae3980d2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp:416 #6 G1ConcurrentMarkThread::run_service (this=0x2ae3980d2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp:256 #7 0x00002ae3935eb8da in ConcurrentGCThread::run (this=0x2ae3980d2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/concurrentGCThread.cpp:81 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3980d2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 167 (Thread 0x2ae3b3c8a700 (LWP 27932)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae3980d3f98) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae3980d3ef0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae3980d4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae3980d4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3980d4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 166 (Thread 0x2ae40a807700 (LWP 27933)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae398458400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae398458400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398021210, Self=Self at entry=0x2ae398457000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x2ae398021210, no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae39371cc1a in wait_for_completed_buffers (this=0x2ae398457000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp:63 #6 G1ConcurrentRefineThread::run_service (this=0x2ae398457000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp:98 #7 0x00002ae3935eb8da in ConcurrentGCThread::run (this=0x2ae398457000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/concurrentGCThread.cpp:81 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae398457000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 165 (Thread 0x2ae40a908700 (LWP 27934)): #0 0x00002ae3927b5cf2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8efe in os::PlatformEvent::park (this=this at entry=0x2ae39845a600, millis=millis at entry=300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1947 #2 0x00002ae393b50c4b in ParkCommon (timo=300, ev=0x2ae39845a600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:401 #3 Monitor::IWait (this=this at entry=0x2ae398459318, Self=Self at entry=0x2ae398459000, timo=timo at entry=300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=this at entry=0x2ae398459318, no_safepoint_check=no_safepoint_check at entry=true, timeout=300, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393764317 in sleep_before_next_cycle (this=0x2ae398459000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp:49 #6 G1YoungRemSetSamplingThread::run_service (this=0x2ae398459000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1YoungRemSetSamplingThread.cpp:65 #7 0x00002ae3935eb8da in ConcurrentGCThread::run (this=0x2ae398459000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/concurrentGCThread.cpp:81 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae398459000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 164 (Thread 0x2ae40b28a700 (LWP 27948)): #0 0x00002ae3937ac6aa in thread_at (i=, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.hpp:188 #1 next (this=0x2ae40b289a70) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.hpp:365 #2 VM_HandshakeAllThreads::doit (this=0x2ae40b990c60) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/handshake.cpp:214 #3 0x00002ae393dea578 in VM_Operation::evaluate (this=this at entry=0x2ae40b990c60) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vm_operations.cpp:67 #4 0x00002ae393de7e0f in VMThread::evaluate_operation (op=0x2ae40b990c60, this=0x2ae40b990c60) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:370 #5 0x00002ae393de853a in VMThread::loop (this=this at entry=0x2ae3984b5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:552 #6 0x00002ae393de871b in VMThread::run (this=0x2ae3984b5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:267 #7 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984b5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #8 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #9 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 163 (Thread 0x2ae40b38b700 (LWP 27950)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3984ba700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3984ba700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398024710, Self=Self at entry=0x2ae3984b9000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398024710, no_safepoint_check=no_safepoint_check at entry=false, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae3938c9c9e in wait (as_suspend_equivalent=false, timeout=0, no_safepoint_check=false, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:268 #6 JVM_WaitForReferencePendingList (env=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:3318 #7 0x00002ae3a43ef257 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae40b38a8c8 in ?? () #10 0x000000080052c590 in ?? () #11 0x00002ae40b38a928 in ?? () #12 0x000000080000ad20 in ?? () #13 0x0000000000000000 in ?? () Thread 162 (Thread 0x2ae40b48c700 (LWP 27951)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae3984bcb00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae41c002e00, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae3984bb800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae3984bb800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae40b48b880, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae40b48b850 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae40b48b808 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae40b48b880 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 161 (Thread 0x2ae40b58d700 (LWP 27960)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae398018ff8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393b99aa5 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 check_pending_signals () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:2519 #6 os::signal_wait () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:2537 #7 0x00002ae393b8dfce in signal_thread_entry (thread=, __the_thread__=0x2ae3984c2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/os.cpp:353 #8 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae3984c2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #9 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #10 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #11 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #12 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 160 (Thread 0x2ae40b68e700 (LWP 27961)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3984c5f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3984c5f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae3984c4800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae393de7867 in VMThread::execute (op=0x2ae40b68db40) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 #6 0x00002ae393b09a00 in metaspace::MetaspaceDCmd::execute (this=0x2ae3984c5050, source=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/memory/metaspace/metaspaceDCmd.cpp:99 #7 0x00002ae3936b10dd in DCmd::parse_and_execute (source=source at entry=DCmd_Source_AttachAPI, out=out at entry=0x2ae40b68dce0, cmdline=cmdline at entry=0x2ae42c000b99 "VM.metaspace", delim=delim at entry=32 ' ', __the_thread__=__the_thread__ at entry=0x2ae3984c4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/services/diagnosticFramework.cpp:409 #8 0x00002ae3933e413f in jcmd (op=0x2ae42c000b80, out=0x2ae40b68dce0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/services/attachListener.cpp:204 #9 0x00002ae3933e50f1 in attach_listener_thread_entry (thread=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/services/attachListener.cpp:391 #10 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae3984c4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3984c9100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae3984c7800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 #8 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method (task=task at entry=0x2ae48800ff40) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 #9 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 #10 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae3984c7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3984cbb00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 #8 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method (task=task at entry=0x2ae49c00a670) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 #9 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 #10 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae3984ca800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984ca800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 157 (Thread 0x2ae40b991700 (LWP 27966)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3984d6500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3984d6500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae3984d5000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae393de7867 in VMThread::execute (op=op at entry=0x2ae40b990c60) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 #6 0x00002ae3937ab5e8 in Handshake::execute (thread_cl=thread_cl at entry=0x2ae40b990cd0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/handshake.cpp:275 #7 0x00002ae393d0600c in do_stack_scanning () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/sweeper.cpp:332 #8 NMethodSweeper::possibly_sweep () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/sweeper.cpp:455 #9 0x00002ae393d062ed in NMethodSweeper::sweeper_loop () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/sweeper.cpp:351 #10 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae3984d5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984d5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984d5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 156 (Thread 0x2ae40bc94700 (LWP 27981)): #0 0x00002ae3927b5cf2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8efe in os::PlatformEvent::park (this=0x2ae39851b000, millis=millis at entry=60000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1947 #2 0x00002ae393b76103 in ObjectMonitor::wait (this=this at entry=0x2ae41c004a00, millis=millis at entry=60000, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae39851a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1273 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=60000, __the_thread__=__the_thread__ at entry=0x2ae39851a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae40bc937b0, ms=60000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3ac023b7b in ?? () #6 0x0000000082008d28 in ?? () #7 0x00002ae3ac025a7f in ?? () #8 0x00002ae40bc93818 in ?? () #9 0x0000000000000094 in ?? () #10 0x0000000000000000 in ?? () Thread 155 (Thread 0x2ae40bd95700 (LWP 27982)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae39851fd00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae39851fd00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398022510, Self=Self at entry=0x2ae39851e800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x2ae398022510, no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393c7376c in ServiceThread::service_thread_entry (jt=0x2ae39851e800, __the_thread__=0x2ae39851e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/serviceThread.cpp:120 #6 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae39851e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #7 0x00002ae393d736c6 in JavaThread::run (this=0x2ae39851e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae39851e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 154 (Thread 0x2ae40be96700 (LWP 27983)): #0 0x00002ae3927b5cf2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8efe in os::PlatformEvent::park (this=this at entry=0x2ae398523a00, millis=millis at entry=50) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1947 #2 0x00002ae393b50c4b in ParkCommon (timo=50, ev=0x2ae398523a00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:401 #3 Monitor::IWait (this=this at entry=0x2ae398025810, Self=Self at entry=0x2ae398523000, timo=timo at entry=50) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x2ae398025810, no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=50, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d69a03 in WatcherThread::sleep (this=this at entry=0x2ae398523000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1340 #6 0x00002ae393d6f0d1 in WatcherThread::run (this=0x2ae398523000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1386 #7 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae398523000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #8 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #9 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 153 (Thread 0x2ae40bf97700 (LWP 27994)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985e5600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3985e5600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae3985e4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae3985e4800, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=262144) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae39370607f in attempt_allocation (actual_word_size=0x2ae40bf964a0, desired_word_size=262144, min_word_size=256, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::allocate_new_tlab (this=0x2ae39804f9c0, min_size=256, requested_size=262144, actual_size=0x2ae40bf964a0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:395 #10 0x00002ae393ae42c8 in MemAllocator::allocate_inside_tlab_slow (this=0x2ae40bf964f0, allocation=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:316 #11 0x00002ae393ae45e1 in allocate_inside_tlab (allocation=..., this=0x2ae40bf964f0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:278 #12 mem_allocate (allocation=..., this=0x2ae40bf964f0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:348 #13 MemAllocator::allocate (this=this at entry=0x2ae40bf964f0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #14 0x00002ae39359859d in CollectedHeap::obj_allocate (this=, klass=, size=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:466 #15 0x00002ae3937f0c09 in InstanceKlass::allocate_instance (this=, __the_thread__=0x2ae3985e4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1233 #16 0x00002ae3938a127a in jni_NewObject (env=0x2ae3985e4b30, clazz=0x2ae3984bf2c8, methodID=0x2ae3985343c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jni.cpp:1274 #17 0x00002ae42674b31a in NET_SockaddrToInetAddress (env=env at entry=0x2ae3985e4b30, sa=sa at entry=0x2ae40bf96760, port=port at entry=0x2ae40bf96758) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/share/native/libnet/net_util.c:216 #18 0x00002ae426747f36 in Java_java_net_PlainSocketImpl_socketAccept (env=0x2ae3985e4b30, this=0x2ae40bf96848, socket=0x2ae40bf96840) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/unix/native/libnet/PlainSocketImpl.c:715 #19 0x00002ae3a43ef257 in ?? () #20 0x00002ae40bf96820 in ?? () #21 0x00002ae3a43eecbe in ?? () #22 0x00002ae3a43eec76 in ?? () #23 0x00002ae40bf967d8 in ?? () #24 0x00002ae40aa952e8 in ?? () #25 0x00002ae40bf96848 in ?? () #26 0x00002ae40aa9d1c8 in ?? () #27 0x0000000000000000 in ?? () Thread 152 (Thread 0x2ae427060700 (LWP 27995)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985e7400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 #6 0x00002ae3939965f3 in JvmtiEnvThreadState::reset_current_location (this=this at entry=0x2ae6bc000d80, event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, enabled=enabled at entry=true) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 #7 0x00002ae393997acf in recompute_env_thread_enabled (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:490 #8 JvmtiEventControllerPrivate::recompute_thread_enabled (state=state at entry=0x2ae6bc000cd0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:523 #9 0x00002ae393998168 in JvmtiEventControllerPrivate::recompute_enabled () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 #10 0x00002ae39399a244 in set_user_enabled (enabled=true, event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:818 #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:963 #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, event_thread=event_thread at entry=0x0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, event_thread=event_thread at entry=0x0) at /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 #14 0x00002ae394d97989 in enable_events () at /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 #15 0x00002ae394d98070 in Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration (env=, this=) at /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 #16 0x00002ae3a43ef257 in ?? () #17 0x00002ae3a43eede1 in ?? () #18 0x00002ae42705f878 in ?? () #19 0x00002ae40ad334e0 in ?? () #20 0x00002ae42705f8e0 in ?? () #21 0x00002ae40ad33c68 in ?? () #22 0x0000000000000000 in ?? () Thread 151 (Thread 0x2ae427161700 (LWP 27996)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985e9200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3985e9200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae3985e8000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae3985e8000, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=262144) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae39370607f in attempt_allocation (actual_word_size=0x2ae42715e830, desired_word_size=262144, min_word_size=256, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::allocate_new_tlab (this=0x2ae39804f9c0, min_size=256, requested_size=262144, actual_size=0x2ae42715e830) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:395 #10 0x00002ae393ae42c8 in MemAllocator::allocate_inside_tlab_slow (this=0x2ae42715e880, allocation=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:316 #11 0x00002ae393ae45e1 in allocate_inside_tlab (allocation=..., this=0x2ae42715e880) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:278 #12 mem_allocate (allocation=..., this=0x2ae42715e880) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:348 #13 MemAllocator::allocate (this=this at entry=0x2ae42715e880) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #14 0x00002ae3935985e4 in CollectedHeap::array_allocate (this=, klass=, size=, length=, do_zero=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:471 #15 0x00002ae39382e1f8 in allocate (__the_thread__=0x2ae3985e8000, length=32, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/typeArrayKlass.hpp:69 #16 new_intArray (__the_thread__=0x2ae3985e8000, length=32) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/memory/oopFactory.hpp:50 #17 BacktraceBuilder::expand (this=this at entry=0x2ae42715ea50, __the_thread__=__the_thread__ at entry=0x2ae3985e8000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/javaClasses.cpp:2048 #18 0x00002ae39382e3e5 in BacktraceBuilder::BacktraceBuilder (this=0x2ae42715ea50, __the_thread__=0x2ae3985e8000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/javaClasses.cpp:2017 #19 0x00002ae39382b606 in java_lang_Throwable::fill_in_stack_trace (throwable=..., throwable at entry=..., method=..., __the_thread__=0x2ae3985e8000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/javaClasses.cpp:2323 #20 0x00002ae39382bf63 in java_lang_Throwable::fill_in_stack_trace (throwable=..., method=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/javaClasses.cpp:2460 #21 0x00002ae3938c70bd in JVM_FillInStackTrace (env=, receiver=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:515 #22 0x00002ae394b7f9c1 in Java_java_lang_Throwable_fillInStackTrace (env=, throwable=0x2ae42715fdd0, dummy=) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/share/native/libjava/Throwable.c:49 #23 0x00002ae3ac003b7b in ?? () #24 0x00000000b5e00500 in ?? () #25 0x00002ae42715fe10 in ?? () #26 0x00002ae42715fe28 in ?? () #27 0x00002ae3937ee6a3 in InstanceKlass::find_method_index (methods=0x2ae42715fec8, name=0x2ae42715fe10, signature=0x2ae3985e8000, overpass_mode=(unknown: 10980), private_mode=Klass::find_private, static_mode=Klass::find_static) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1699 #28 0x00002ae3ac0171ec in ?? () #29 0x00000000b5e00500 in ?? () #30 0x00002ae42715fe60 in ?? () #31 0x00002ae3937eea68 in find_method_impl (private_mode=(unknown: 5024064), static_mode=Klass::find_static, overpass_mode=, signature=0x1985e8000, name=0x80036a2f0, methods=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1656 #32 find_method_impl (private_mode=(unknown: 5024064), static_mode=Klass::find_static, overpass_mode=, signature=0x1985e8000, name=0x80036a2f0, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1574 #33 InstanceKlass::uncached_lookup_method (this=, name=0x80036a2f0, signature=0x1985e8000, overpass_mode=, private_mode=(unknown: 5024064)) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1769 Thread 150 (Thread 0x2ae427262700 (LWP 27997)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985eb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3985eb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae3985ea000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae3985ea000, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=118636) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae39370607f in attempt_allocation (actual_word_size=0x2ae427261840, desired_word_size=118636, min_word_size=256, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::allocate_new_tlab (this=0x2ae39804f9c0, min_size=256, requested_size=118636, actual_size=0x2ae427261840) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:395 #10 0x00002ae393ae42c8 in MemAllocator::allocate_inside_tlab_slow (this=0x2ae427261890, allocation=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:316 #11 0x00002ae393ae45e1 in allocate_inside_tlab (allocation=..., this=0x2ae427261890) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:278 #12 mem_allocate (allocation=..., this=0x2ae427261890) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:348 #13 MemAllocator::allocate (this=this at entry=0x2ae427261890) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #14 0x00002ae39359859d in CollectedHeap::obj_allocate (this=, klass=, size=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:466 #15 0x00002ae3937f0c09 in InstanceKlass::allocate_instance (this=this at entry=0x800003478, __the_thread__=__the_thread__ at entry=0x2ae3985ea000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1233 #16 0x00002ae393c62c0c in OptoRuntime::new_instance_C (klass=0x800003478, thread=0x2ae3985ea000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/opto/runtime.cpp:215 #17 0x00002ae3a44e08a5 in ?? () #18 0x00000000e7967920 in ?? () #19 0x00002ae3ac01cf94 in ?? () #20 0x00000008000003e8 in ?? () #21 0x0000000800003478 in ?? () #22 0x0000000000014523 in ?? () #23 0x0000000000000007 in ?? () #24 0x00000000820025c0 in ?? () #25 0x0000000101b8f888 in ?? () #26 0x00000166949a8e5f in ?? () #27 0x0000000101b8f888 in ?? () #28 0x0000000000000003 in ?? () #29 0xdeaddeaf00000000 in ?? () #30 0x00002ae4272619e0 in ?? () #31 0x00002ae3a43e5d28 in ?? () #32 0x00000000820025c0 in ?? () #33 0x00002ae427261998 in ?? () #34 0x00002ae40ad30cd8 in ?? () #35 0x00002ae427261a08 in ?? () #36 0x00002ae40ad31c60 in ?? () #37 0x0000000000000000 in ?? () Thread 149 (Thread 0x2ae427363700 (LWP 27998)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985ece00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3985ece00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398025110, Self=0x2ae3985ec000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b50fe1 in Monitor::lock (this=this at entry=0x2ae398025110, Self=Self at entry=0x2ae3985ec000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 0x00002ae393d20a50 in MutexLocker (thread=0x2ae3985ec000, mutex=0x2ae398025110, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:190 #6 SystemDictionary::parse_stream (class_name=class_name at entry=0x0, class_loader=..., protection_domain=..., st=st at entry=0x2ae427361410, unsafe_anonymous_host=unsafe_anonymous_host at entry=0x8003a1628, cp_patches=cp_patches at entry=0x2ae434000bb0, __the_thread__=0x2ae3985ec000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/systemDictionary.cpp:1034 #7 0x00002ae393da4887 in Unsafe_DefineAnonymousClass_impl (env=0x2ae3985ec330, __the_thread__=0x2ae3985ec000, temp_alloc=, cp_patches_jh=, data=, host_class=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/unsafe.cpp:822 #8 Unsafe_DefineAnonymousClass0 (env=0x2ae3985ec330, unsafe=, host_class=, data=, cp_patches_jh=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/unsafe.cpp:836 #9 0x00002ae3a43ef257 in ?? () #10 0x00002ae427361490 in ?? () #11 0x00002ae3985ec000 in ?? () #12 0x00002ae4273614b0 in ?? () #13 0x00002ae3938c7e65 in trans_and_fence (to=_thread_in_native, from=_thread_in_vm, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:178 #14 ~ThreadInVMfromNative (this=, __in_chrg=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:262 #15 JVM_IsPrimitiveClass (env=, cls=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:1415 #16 0x00002ae3a43e58c8 in ?? () #17 0x0000000000000000 in ?? () Thread 148 (Thread 0x2ae427464700 (LWP 27999)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae3985eec00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae48c005c80, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae3985ed800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae3985ed800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae427463850, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae427463820 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae4274637d8 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae427463850 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 147 (Thread 0x2ae427565700 (LWP 28000)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985f1200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3985f1200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae3985f0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae3985f0000, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=262144) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae39370607f in attempt_allocation (actual_word_size=0x2ae4275642d0, desired_word_size=262144, min_word_size=256, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::allocate_new_tlab (this=0x2ae39804f9c0, min_size=256, requested_size=262144, actual_size=0x2ae4275642d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:395 #10 0x00002ae393ae42c8 in MemAllocator::allocate_inside_tlab_slow (this=0x2ae427564320, allocation=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:316 #11 0x00002ae393ae45e1 in allocate_inside_tlab (allocation=..., this=0x2ae427564320) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:278 #12 mem_allocate (allocation=..., this=0x2ae427564320) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:348 #13 MemAllocator::allocate (this=this at entry=0x2ae427564320) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #14 0x00002ae39359859d in CollectedHeap::obj_allocate (this=, klass=, size=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:466 #15 0x00002ae3937f0c09 in InstanceKlass::allocate_instance (this=this at entry=0x80032dd68, __the_thread__=__the_thread__ at entry=0x2ae3985f0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1233 #16 0x00002ae3934c9416 in Runtime1::new_instance (thread=0x2ae3985f0000, klass=0x80032dd68) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/c1/c1_Runtime1.cpp:356 #17 0x00002ae3a44d91e0 in ?? () #18 0x00002ae3927b4eae in _L_unlock_713 () from /lib64/libpthread.so.0 #19 0x00002ae3927b4e20 in pthread_mutex_unlock () from /lib64/libpthread.so.0 #20 0x0000000000000000 in ?? () Thread 146 (Thread 0x2ae427666700 (LWP 28001)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985f3400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985f3400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae3985f2f60, Self=Self at entry=0x2ae3985f2000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x2ae3985f2f60, no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d70825 in java_suspend_self (this=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2378 #6 JavaThread::handle_special_runtime_exit_condition (this=0x2ae3985f2000, check_asyncs=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2225 #7 0x00002ae393c65dc0 in SafepointSynchronize::block (thread=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/safepoint.cpp:934 #8 0x00002ae393d6a7dd in block_if_requested_local_poll (thread=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/safepointMechanism.inline.hpp:63 #9 block_if_requested (thread=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/safepointMechanism.inline.hpp:73 #10 JavaThread::check_safepoint_and_suspend_for_native_trans (thread=thread at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2441 #11 0x00002ae3939a9b01 in transition_from_native (to=_thread_in_vm, thread=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:166 #12 trans_from_native (to=_thread_in_vm, this=0x2ae4276653d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:177 #13 ~ThreadToNativeFromVM (this=0x2ae4276653d0, __in_chrg=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/interfaceSupport.inline.hpp:280 #14 JvmtiJavaThreadEventTransition::~JvmtiJavaThreadEventTransition (this=0x2ae4276653a0, __in_chrg=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:80 #15 0x00002ae3939a0088 in JvmtiExport::post_method_entry (thread=thread at entry=0x2ae3985f2000, method=, current_frame=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1519 #16 0x00002ae393819195 in InterpreterRuntime::post_method_entry (thread=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/interpreter/interpreterRuntime.cpp:1309 #17 0x00002ae3a43ed891 in ?? () #18 0x00002ae3a43ed84c in ?? () #19 0x00002ae427665518 in ?? () #20 0x0000000800521d58 in ?? () #21 0x00002ae427665570 in ?? () #22 0x0000000800003748 in ?? () #23 0x00002ae40a911c28 in ?? () #24 0x00000007ffb2e0b8 in ?? () #25 0x0000000800004320 in ?? () #26 0x0000000000000000 in ?? () Thread 145 (Thread 0x2ae427767700 (LWP 28002)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985f5600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985f5600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae3985f4000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae393de7867 in VMThread::execute (op=0x2ae427764d30) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 #6 0x00002ae39358840a in CodeCache::flush_dependents_on (dependee=dependee at entry=0x840186e60) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/code/codeCache.cpp:1270 #7 0x00002ae393d21253 in add_to_hierarchy (__the_thread__=0x2ae3985f4000, k=0x840186e60) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/systemDictionary.cpp:1846 #8 SystemDictionary::define_instance_class (k=k at entry=0x840186e60, __the_thread__=__the_thread__ at entry=0x2ae3985f4000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/systemDictionary.cpp:1638 #9 0x00002ae393d219ec in SystemDictionary::resolve_from_stream (class_name=class_name at entry=0x2ae47006ea60, class_loader=..., protection_domain=..., st=st at entry=0x2ae427765030, __the_thread__=__the_thread__ at entry=0x2ae3985f4000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/systemDictionary.cpp:1144 #10 0x00002ae3938cfea0 in jvm_define_class_common (env=env at entry=0x2ae3985f4330, name=name at entry=0x2ae427765180 "spec/jbb/SaveOutput", loader=loader at entry=0x2ae427765710, buf=buf at entry=0x2ae4702230d0 "\312\376\272\276", len=len at entry=1945, pd=pd at entry=0x2ae4277656e8, source=0x2ae393eb8ebe "__JVM_DefineClass__", __the_thread__=0x2ae3985f4000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:935 #11 0x00002ae3938d00ff in JVM_DefineClassWithSource (env=0x2ae3985f4330, name=, loader=0x2ae427765710, buf=0x2ae4702230d0 "\312\376\272\276", len=1945, pd=, source=0x0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:955 #12 0x00002ae394b77663 in Java_java_lang_ClassLoader_defineClass1 (env=0x2ae3985f4330, cls=, loader=0x2ae427765710, name=0x2ae427765708, data=, offset=, length=1945, pd=0x2ae4277656e8, source=0x0) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/share/native/libjava/ClassLoader.c:136 #13 0x00002ae3a43ef257 in ?? () #14 0x00002ae400000799 in ?? () #15 0x00002ae4277656e8 in ?? () #16 0x0000000000000000 in ?? () Thread 144 (Thread 0x2ae427868700 (LWP 28003)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae3985f7500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae480005d80, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae3985f6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae3985f6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae427866fd0, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae427866fa0 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae427866f58 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae427866fd0 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 143 (Thread 0x2ae427969700 (LWP 28004)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae3985f9300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae47807e000, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae3985f8800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae3985f8800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae427967fd0, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae427967fa0 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae427967f58 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae427967fd0 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 142 (Thread 0x2ae427a6a700 (LWP 28005)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985fb900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3985fb900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae3985fa800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae3985fa800, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=262144) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae39370607f in attempt_allocation (actual_word_size=0x2ae427a692d0, desired_word_size=262144, min_word_size=256, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::allocate_new_tlab (this=0x2ae39804f9c0, min_size=256, requested_size=262144, actual_size=0x2ae427a692d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:395 #10 0x00002ae393ae42c8 in MemAllocator::allocate_inside_tlab_slow (this=0x2ae427a69320, allocation=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:316 #11 0x00002ae393ae45e1 in allocate_inside_tlab (allocation=..., this=0x2ae427a69320) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:278 #12 mem_allocate (allocation=..., this=0x2ae427a69320) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:348 #13 MemAllocator::allocate (this=this at entry=0x2ae427a69320) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #14 0x00002ae39359859d in CollectedHeap::obj_allocate (this=, klass=, size=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:466 #15 0x00002ae3937f0c09 in InstanceKlass::allocate_instance (this=this at entry=0x80032dd68, __the_thread__=__the_thread__ at entry=0x2ae3985fa800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1233 #16 0x00002ae3934c9416 in Runtime1::new_instance (thread=0x2ae3985fa800, klass=0x80032dd68) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/c1/c1_Runtime1.cpp:356 #17 0x00002ae3a44d91e0 in ?? () #18 0x00002ae394422bec in os::_initial_active_processor_count () from /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/jdk/lib/server/libjvm.so #19 0x000000000000000c in ?? () #20 0x0000000000000018 in ?? () #21 0x000000000000000c in ?? () #22 0x00000000823e8888 in ?? () #23 0x000000000000000c in ?? () #24 0x287065656c732e64 in ?? () #25 0x0000000000000000 in ?? () Thread 141 (Thread 0x2ae427b6b700 (LWP 28006)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985fdb00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3985fdb00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae3985fc800, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=262144) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae39370607f in attempt_allocation (actual_word_size=0x2ae427b6a190, desired_word_size=262144, min_word_size=256, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::allocate_new_tlab (this=0x2ae39804f9c0, min_size=256, requested_size=262144, actual_size=0x2ae427b6a190) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:395 #10 0x00002ae393ae42c8 in MemAllocator::allocate_inside_tlab_slow (this=0x2ae427b6a1e0, allocation=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:316 #11 0x00002ae393ae45e1 in allocate_inside_tlab (allocation=..., this=0x2ae427b6a1e0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:278 #12 mem_allocate (allocation=..., this=0x2ae427b6a1e0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:348 #13 MemAllocator::allocate (this=this at entry=0x2ae427b6a1e0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #14 0x00002ae39359859d in CollectedHeap::obj_allocate (this=, klass=, size=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:466 #15 0x00002ae3937f0c09 in InstanceKlass::allocate_instance (this=, __the_thread__=__the_thread__ at entry=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1233 #16 0x00002ae393821239 in java_lang_String::basic_create (length=length at entry=15, is_latin1=, __the_thread__=__the_thread__ at entry=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/javaClasses.cpp:229 #17 0x00002ae39382146b in java_lang_String::create_from_unicode (unicode=unicode at entry=0x2ae3985fd000, length=length at entry=15, __the_thread__=__the_thread__ at entry=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/javaClasses.cpp:247 #18 0x00002ae393cb5795 in StringTable::do_intern (this=0x2ae398493890, string_or_null_h=..., string_or_null_h at entry=..., name=0x2ae3985fd000, len=15, hash=3215636097, __the_thread__=0x2ae3985fc800, __the_thread__ at entry=0xd8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/stringTable.cpp:370 #19 0x00002ae393cb59c6 in StringTable::intern (string_or_null_h=..., string_or_null_h at entry=..., name=, len=, __the_thread__=0xd8, __the_thread__ at entry=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/stringTable.cpp:335 #20 0x00002ae393cb5a41 in StringTable::intern (symbol=, __the_thread__=__the_thread__ at entry=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/stringTable.cpp:298 #21 0x00002ae39361848b in ConstantPool::string_at_impl (this_cp=..., which=, obj_index=, __the_thread__=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/constantPool.cpp:1272 #22 0x00002ae39361e4f8 in ConstantPool::resolve_constant_at_impl (this_cp=..., index=18, cache_index=1, status_return=0x0, __the_thread__=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/constantPool.cpp:986 #23 0x00002ae3934198bc in resolve_constant_at (__the_thread__=, index=, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/constantPool.hpp:730 #24 Bytecode_loadconstant::resolve_constant (this=this at entry=0x2ae427b6a720, __the_thread__=__the_thread__ at entry=0x2ae3985fc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/interpreter/bytecode.cpp:228 #25 0x00002ae393810411 in InterpreterRuntime::resolve_ldc (thread=0x2ae3985fc800, bytecode=Bytecodes::_fast_aldc) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/interpreter/interpreterRuntime.cpp:200 #26 0x00002ae3a440bbbb in ?? () #27 0x00002ae3a440bb76 in ?? () #28 0x00000000e239e128 in ?? () #29 0x00002ae427b6a7f0 in ?? () #30 0x00002ae40aa7d53c in ?? () #31 0x00002ae427b6a848 in ?? () #32 0x00002ae40acd3c70 in ?? () #33 0x0000000000000000 in ?? () Thread 140 (Thread 0x2ae427c6c700 (LWP 28007)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae3985ffa00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae480007e80, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae3985fe800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae3985fe800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae427c6b850, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae427c6b820 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae427c6b7d8 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae427c6b850 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 139 (Thread 0x2ae427d6d700 (LWP 28008)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae398601f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae398601f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae398600800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae393de7867 in VMThread::execute (op=op at entry=0x2ae427d6c540) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 #6 0x00002ae3937059c9 in do_collection_pause (gc_cause=GCCause::_g1_inc_collection_pause, succeeded=, gc_count_before=, word_size=502, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:2533 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=502) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:459 #8 0x00002ae393705e23 in attempt_allocation (actual_word_size=, desired_word_size=502, min_word_size=502, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::mem_allocate (this=0x2ae39804f9c0, word_size=502, gc_overhead_limit_was_exceeded=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:407 #10 0x00002ae393ae4504 in allocate_outside_tlab (allocation=..., this=0x2ae427d6c6d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:256 #11 mem_allocate (allocation=..., this=0x2ae427d6c6d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:354 #12 MemAllocator::allocate (this=this at entry=0x2ae427d6c6d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #13 0x00002ae3935985e4 in CollectedHeap::array_allocate (this=, klass=, size=, length=, do_zero=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:471 #14 0x00002ae39389fc85 in jni_NewObjectArray (env=0x2ae398600b30, length=1000, elementClass=, initialElement=0x0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jni.cpp:2589 #15 0x00002ae494102ccb in Java_applications_kitchensink_process_stress_modules_JniStressModule_newObjectArray (env=, this=) at /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJniStressModule.c:357 #16 0x00002ae3ac00cc81 in ?? () #17 0x0000000082009538 in ?? () #18 0x0000000082072808 in ?? () #19 0x00000000b57ffa00 in ?? () #20 0x00000000000000b6 in ?? () #21 0x0000000000000000 in ?? () Thread 138 (Thread 0x2ae427e6e700 (LWP 28009)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae398603e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae48c002a80, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae398603000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae398603000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae427e6d850, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae427e6d820 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae427e6d7d8 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae427e6d850 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 137 (Thread 0x2ae427f6f700 (LWP 28010)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae398606000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae480007d80, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae398605000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae398605000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae427f6e850, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae427f6e820 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae427f6e7d8 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae427f6e850 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 136 (Thread 0x2ae494100700 (LWP 28023)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae454005800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae393de7867 in VMThread::execute (op=op at entry=0x2ae4940ffb10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 #6 0x00002ae393d6a3bd in JavaThread::java_suspend (this=this at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 #7 0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend (java_thread=java_thread at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:847 #8 0x00002ae3939887ae in JvmtiEnv::SuspendThread (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:955 #9 0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, thread=0x2ae49929fdf8) at /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:527 #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, env=, p=) at /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:274 #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 #13 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 135 (Thread 0x2ae40bb93700 (LWP 28389)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae434098500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae434098500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398025a10, Self=Self at entry=0x2ae480050800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=0x2ae398025a10, no_safepoint_check=no_safepoint_check at entry=false, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae393862623 in recorderthread_entry (thread=, unused=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/recorder/service/jfrRecorderThreadLoop.cpp:58 #6 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae480050800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #7 0x00002ae393d736c6 in JavaThread::run (this=0x2ae480050800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae480050800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 134 (Thread 0x2ae40ba92700 (LWP 28391)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41400a800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41400a800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41400a800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 133 (Thread 0x2ae56478d700 (LWP 28392)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414002800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414002800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414002800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 132 (Thread 0x2ae56488e700 (LWP 28393)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414003800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414003800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414003800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 131 (Thread 0x2ae56498f700 (LWP 28394)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414005000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414005000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414005000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 130 (Thread 0x2ae564a90700 (LWP 28395)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414006800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414006800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414006800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 129 (Thread 0x2ae564b91700 (LWP 28396)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414008800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414008800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414008800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 128 (Thread 0x2ae564c92700 (LWP 28397)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41400b800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41400b800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41400b800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 127 (Thread 0x2ae564d93700 (LWP 28398)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41400d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41400d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41400d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 126 (Thread 0x2ae564e94700 (LWP 28399)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41400f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41400f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41400f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 125 (Thread 0x2ae564f95700 (LWP 28400)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414011000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414011000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414011000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 124 (Thread 0x2ae565096700 (LWP 28401)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414013000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414013000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414013000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 123 (Thread 0x2ae565197700 (LWP 28402)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41415b800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41415b800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41415b800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 122 (Thread 0x2ae565298700 (LWP 28403)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41415d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41415d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41415d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 121 (Thread 0x2ae565399700 (LWP 28404)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41415f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41415f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41415f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 120 (Thread 0x2ae56549a700 (LWP 28405)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414161800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414161800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414161800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 119 (Thread 0x2ae56559b700 (LWP 28406)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414131000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414131000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414131000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 118 (Thread 0x2ae56569c700 (LWP 28407)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414132800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414132800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414132800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 117 (Thread 0x2ae56579d700 (LWP 28408)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414134800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414134800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414134800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 116 (Thread 0x2ae56589e700 (LWP 28409)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414136800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414136800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414136800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 115 (Thread 0x2ae56599f700 (LWP 28410)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae414138800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae414138800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae414138800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 114 (Thread 0x2ae565aa0700 (LWP 28411)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41413a800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41413a800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41413a800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 113 (Thread 0x2ae565ba1700 (LWP 28412)): #0 0x00002ae3927b7a0b in do_futex_wait.constprop.1 () from /lib64/libpthread.so.0 #1 0x00002ae3927b7a9f in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0 #2 0x00002ae3927b7b3b in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0 #3 0x00002ae393c72b62 in PosixSemaphore::wait (this=0x2ae39805d2e8) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/semaphore_posix.cpp:64 #4 0x00002ae393e0ccc9 in wait (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/semaphore.hpp:56 #5 SemaphoreGangTaskDispatcher::worker_wait_for_task (this=0x2ae39805d240) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:158 #6 0x00002ae393e0bae1 in wait_for_task (this=0x2ae41413c800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:326 #7 GangWorker::loop (this=0x2ae41413c800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/workgroup.cpp:345 #8 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae41413c800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #9 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #10 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 112 (Thread 0x2ae565ca2700 (LWP 28426)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae4740ba800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae5bc00ae00, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae4740ba000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae4740ba000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae565ca16c0, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3ac023b7b in ?? () #6 0x000000008255b980 in ?? () #7 0x00002ae565ca16c8 in ?? () #8 0x0000000000000000 in ?? () Thread 111 (Thread 0x2ae565da3700 (LWP 28427)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae5bc004b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae5bc004b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae5bc005000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae5bc005000, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=65538) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae393705e23 in attempt_allocation (actual_word_size=, desired_word_size=65538, min_word_size=65538, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::mem_allocate (this=0x2ae39804f9c0, word_size=65538, gc_overhead_limit_was_exceeded=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:407 #10 0x00002ae393ae4504 in allocate_outside_tlab (allocation=..., this=0x2ae565da24c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:256 #11 mem_allocate (allocation=..., this=0x2ae565da24c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:354 #12 MemAllocator::allocate (this=this at entry=0x2ae565da24c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #13 0x00002ae3935985e4 in CollectedHeap::array_allocate (this=, klass=, size=, length=, do_zero=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:471 #14 0x00002ae393810ca6 in InterpreterRuntime::newarray (thread=0x2ae5bc005000, type=, size=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/interpreter/interpreterRuntime.cpp:263 #15 0x00002ae3a4406939 in ?? () #16 0x00002ae3a44068f1 in ?? () #17 0x00002ae565da2538 in ?? () #18 0x00002ae40af515ac in ?? () #19 0x00002ae565da25d0 in ?? () #20 0x00002ae40af526b0 in ?? () #21 0x0000000000000000 in ?? () Thread 110 (Thread 0x2ae565ea4700 (LWP 28428)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae5bc007d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae5bc007d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae5bc006800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae5bc006800, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=65538) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae393705e23 in attempt_allocation (actual_word_size=, desired_word_size=65538, min_word_size=65538, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::mem_allocate (this=0x2ae39804f9c0, word_size=65538, gc_overhead_limit_was_exceeded=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:407 #10 0x00002ae393ae4504 in allocate_outside_tlab (allocation=..., this=0x2ae565ea34c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:256 #11 mem_allocate (allocation=..., this=0x2ae565ea34c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:354 #12 MemAllocator::allocate (this=this at entry=0x2ae565ea34c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #13 0x00002ae3935985e4 in CollectedHeap::array_allocate (this=, klass=, size=, length=, do_zero=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:471 #14 0x00002ae393810ca6 in InterpreterRuntime::newarray (thread=0x2ae5bc006800, type=, size=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/interpreter/interpreterRuntime.cpp:263 #15 0x00002ae3a4406939 in ?? () #16 0x00002ae3a44068f1 in ?? () #17 0x00002ae565ea3538 in ?? () #18 0x00002ae40af515ac in ?? () #19 0x00002ae565ea35d0 in ?? () #20 0x00002ae40af526b0 in ?? () #21 0x0000000000000000 in ?? () Thread 109 (Thread 0x2ae494990700 (LWP 28899)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae460013800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae47807e800, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae47804b800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae47804b800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae49498f8c0, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae49498f890 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae49498f848 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae49498f8c0 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 108 (Thread 0x2ae49478e700 (LWP 28910)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46000f600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46000f600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae4800b7800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5 0x00002ae393de7867 in VMThread::execute (op=0x2ae49478d2f0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 #6 0x00002ae3936a825c in ThreadDumpDCmd::execute (this=0x2ae434186560, source=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/services/diagnosticCommand.cpp:624 #7 0x00002ae3936b10dd in DCmd::parse_and_execute (source=source at entry=DCmd_Source_Internal, out=out at entry=0x2ae49478d480, cmdline=cmdline at entry=0x2ae393e9dfe9 "Thread.print", delim=delim at entry=32 ' ', __the_thread__=__the_thread__ at entry=0x2ae4800b7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/services/diagnosticFramework.cpp:409 #8 0x00002ae3938723b0 in execute_dcmd (cmd=0x2ae393e9dfe9 "Thread.print", st=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/periodic/jfrThreadDumpEvent.cpp:44 #9 JfrDcmdEvent::thread_dump () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/periodic/jfrThreadDumpEvent.cpp:62 #10 0x00002ae393859c56 in JfrPeriodicEventSet::requestThreadDump () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:115 #11 0x00002ae393845925 in requestEvent (id=JfrThreadDumpEvent) at /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jfrfiles/jfrPeriodic.hpp:89 #12 jfr_emit_event (env=, jvm=, eventTypeId=355, timeStamp=, when=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/jni/jfrJniMethod.cpp:219 #13 0x00002ae3a43ef257 in ?? () #14 0x00002ae49478d5e0 in ?? () #15 0x00002ae40aae3e85 in ?? () #16 0x00002ae49478d640 in ?? () #17 0x00002ae40aae4170 in ?? () #18 0x00002ae4966b6a70 in ?? () #19 0x0000000000000099 in ?? () #20 0x0000000000000000 in ?? () Thread 107 (Thread 0x2ae49539a700 (LWP 28912)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae460028500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae45c011e80, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae528002800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae528002800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae495399860, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae495399830 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae4953997e8 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae495399860 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 106 (Thread 0x2ae64e01d700 (LWP 28989)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4800aa200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4800aa200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024710, Self=0x2ae4800a9000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4800a9000, this=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024710) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae3937055ff in MutexLockerEx (no_safepoint_check=false, mutex=0x2ae398024710, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:229 #7 G1CollectedHeap::attempt_allocation_slow (this=this at entry=0x2ae39804f9c0, word_size=word_size at entry=45861) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:432 #8 0x00002ae39370607f in attempt_allocation (actual_word_size=0x2ae64e01c880, desired_word_size=45861, min_word_size=256, this=0x2ae39804f9c0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:741 #9 G1CollectedHeap::allocate_new_tlab (this=0x2ae39804f9c0, min_size=256, requested_size=45861, actual_size=0x2ae64e01c880) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/g1/g1CollectedHeap.cpp:395 #10 0x00002ae393ae42c8 in MemAllocator::allocate_inside_tlab_slow (this=0x2ae64e01c8d0, allocation=...) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:316 #11 0x00002ae393ae45e1 in allocate_inside_tlab (allocation=..., this=0x2ae64e01c8d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:278 #12 mem_allocate (allocation=..., this=0x2ae64e01c8d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:348 #13 MemAllocator::allocate (this=this at entry=0x2ae64e01c8d0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/memAllocator.cpp:361 #14 0x00002ae39359859d in CollectedHeap::obj_allocate (this=, klass=, size=, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/collectedHeap.cpp:466 #15 0x00002ae3937f0c09 in InstanceKlass::allocate_instance (this=this at entry=0x840087948, __the_thread__=__the_thread__ at entry=0x2ae4800a9000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/oops/instanceKlass.cpp:1233 #16 0x00002ae393810ab6 in InterpreterRuntime::_new (thread=0x2ae4800a9000, pool=, index=7) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/interpreter/interpreterRuntime.cpp:257 #17 0x00002ae3a44067ae in ?? () #18 0x00002ae3a4406769 in ?? () #19 0x00002ae64e01c988 in ?? () #20 0x00002ae40ad7b989 in ?? () #21 0x00002ae64e01ca08 in ?? () #22 0x00002ae40ad7bae8 in ?? () #23 0x0000000000000000 in ?? () Thread 105 (Thread 0x2ae64d110700 (LWP 28995)): #0 0x00002ae3927b8e4d in nanosleep () from /lib64/libpthread.so.0 #1 0x00002ae393b9d3c8 in os::naked_short_sleep (ms=ms at entry=2) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:4054 #2 0x00002ae3938789aa in JfrThreadSampler::run (this=0x2ae42c035000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp:483 #3 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae42c035000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #4 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #5 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 104 (Thread 0x2ae64c908700 (LWP 29024)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=0x2ae4600d0d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b76245 in ObjectMonitor::wait (this=this at entry=0x2ae45c014380, millis=millis at entry=0, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae47813e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1271 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=0, __the_thread__=__the_thread__ at entry=0x2ae47813e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae64c907860, ms=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3a43ef257 in ?? () #6 0x00002ae64c907830 in ?? () #7 0x00002ae3a43eee26 in ?? () #8 0x00002ae3a43eede1 in ?? () #9 0x00002ae64c9077e8 in ?? () #10 0x0000000800521e08 in ?? () #11 0x00002ae64c907860 in ?? () #12 0x0000000800003748 in ?? () #13 0x0000000000000000 in ?? () Thread 103 (Thread 0x2ae64c504700 (LWP 29026)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600c8100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600c8100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398025110, Self=0x2ae478272000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b50fe1 in Monitor::lock (this=this at entry=0x2ae398025110, Self=Self at entry=0x2ae478272000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 0x00002ae393d21230 in MutexLocker (thread=0x2ae478272000, mutex=0x2ae398025110, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:190 #6 SystemDictionary::define_instance_class (k=k at entry=0x840282c08, __the_thread__=__the_thread__ at entry=0x2ae478272000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/systemDictionary.cpp:1634 #7 0x00002ae393d219ec in SystemDictionary::resolve_from_stream (class_name=class_name at entry=0x2ae66000add0, class_loader=..., protection_domain=..., st=st at entry=0x2ae64c502040, __the_thread__=__the_thread__ at entry=0x2ae478272000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/classfile/systemDictionary.cpp:1144 #8 0x00002ae3938cfea0 in jvm_define_class_common (env=env at entry=0x2ae478272330, name=name at entry=0x2ae64c502190 "spec/benchmarks/derby/DataReader", loader=loader at entry=0x2ae64c502720, buf=buf at entry=0x2ae66040c1e0 "\312\376\272\276", len=len at entry=2079, pd=pd at entry=0x2ae64c5026f8, source=0x2ae393eb8ebe "__JVM_DefineClass__", __the_thread__=0x2ae478272000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:935 #9 0x00002ae3938d00ff in JVM_DefineClassWithSource (env=0x2ae478272330, name=, loader=0x2ae64c502720, buf=0x2ae66040c1e0 "\312\376\272\276", len=2079, pd=, source=0x0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:955 #10 0x00002ae394b77663 in Java_java_lang_ClassLoader_defineClass1 (env=0x2ae478272330, cls=, loader=0x2ae64c502720, name=0x2ae64c502718, data=, offset=, length=2079, pd=0x2ae64c5026f8, source=0x0) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/share/native/libjava/ClassLoader.c:136 #11 0x00002ae3a43ef257 in ?? () #12 0x00002ae60000081f in ?? () #13 0x00002ae64c5026f8 in ?? () #14 0x0000000000000000 in ?? () Thread 102 (Thread 0x2ae4966ad700 (LWP 29270)): #0 0x00002ae3927b5cf2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8efe in os::PlatformEvent::park (this=0x2ae4600e2600, millis=millis at entry=10000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1947 #2 0x00002ae393b76103 in ObjectMonitor::wait (this=this at entry=0x2ae48c007780, millis=millis at entry=10000, interruptible=interruptible at entry=true, __the_thread__=__the_thread__ at entry=0x2ae66003e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/objectMonitor.cpp:1273 #3 0x00002ae393d1256c in ObjectSynchronizer::wait (obj=..., millis=millis at entry=10000, __the_thread__=__the_thread__ at entry=0x2ae66003e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/synchronizer.cpp:484 #4 0x00002ae3938cb5eb in JVM_MonitorWait (env=, handle=0x2ae4966ac830, ms=10000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvm.cpp:616 #5 0x00002ae3ac023b7b in ?? () #6 0x00000000e2082b18 in ?? () #7 0x00002ae64e12fc3e in ?? () #8 0x00002ae4966ac938 in ?? () #9 0x00002ae66003e000 in ?? () #10 0x00002ae4966ac890 in ?? () #11 0x00000000000000b6 in ?? () #12 0x0000000000000000 in ?? () Thread 101 (Thread 0x2ae64c403700 (LWP 29604)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46002e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46002e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460062800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460062800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460062800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460062800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460062800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460062800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 100 (Thread 0x2ae5670b6700 (LWP 29605)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46003f500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46003f500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46009e800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46009e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46009e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46009e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46009e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46009e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 99 (Thread 0x2ae495da4700 (LWP 29606)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460066000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460066000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600d1800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600d1800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600d1800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600d1800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600d1800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600d1800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 98 (Thread 0x2ae495ea5700 (LWP 29607)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46001d700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46001d700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460023000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460023000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460023000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460023000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460023000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460023000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 97 (Thread 0x2ae495fa6700 (LWP 29608)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460030a00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460030a00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460016000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460016000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460016000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460016000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460016000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460016000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 96 (Thread 0x2ae4960a7700 (LWP 29609)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460077100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460077100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46001e000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46001e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46001e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46001e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46001e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46001e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 95 (Thread 0x2ae4961a8700 (LWP 29611)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae434090d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae434090d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460067000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460067000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460067000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460067000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460067000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460067000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 94 (Thread 0x2ae4962a9700 (LWP 29612)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae43408bd00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae43408bd00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460046800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460046800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460046800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460046800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460046800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460046800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 93 (Thread 0x2ae4963aa700 (LWP 29613)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae434089900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae434089900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460020000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460020000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460020000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460020000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460020000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460020000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 92 (Thread 0x2ae4964ab700 (LWP 29614)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae43408ea00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae43408ea00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46006b000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46006b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46006b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46006b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46006b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46006b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 91 (Thread 0x2ae4965ac700 (LWP 29615)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae434093000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae434093000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600ba000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600ba000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600ba000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600ba000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600ba000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600ba000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 90 (Thread 0x2ae4969ae700 (LWP 29616)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae434085200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae434085200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46001a000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46001a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46001a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46001a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46001a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46001a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 89 (Thread 0x2ae496aaf700 (LWP 29617)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae434087600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae434087600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460044800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460044800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460044800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460044800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460044800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460044800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 88 (Thread 0x2ae496cb3700 (LWP 29618)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600b9400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600b9400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460082800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460082800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460082800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460082800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460082800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460082800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 87 (Thread 0x2ae496db4700 (LWP 29619)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460019200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460019200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600de800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600de800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600de800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600de800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600de800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600de800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 86 (Thread 0x2ae496fb6700 (LWP 29620)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46001f900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46001f900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600af000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600af000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600af000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600af000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600af000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600af000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 85 (Thread 0x2ae4971b8700 (LWP 29621)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460079200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460079200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600c5000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600c5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600c5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600c5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600c5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c5000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 84 (Thread 0x2ae4973ba700 (LWP 29622)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460025f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460025f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600cd800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600cd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600cd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600cd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600cd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600cd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 83 (Thread 0x2ae4974bb700 (LWP 29623)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460090b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460090b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600e0000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600e0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600e0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600e0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600e0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600e0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 82 (Thread 0x2ae4975bc700 (LWP 29624)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46008c600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46008c600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46003e000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46003e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46003e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46003e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46003e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46003e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 81 (Thread 0x2ae565fa5700 (LWP 29625)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460048200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460048200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460077800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460077800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460077800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460077800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460077800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460077800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 80 (Thread 0x2ae5660a6700 (LWP 29626)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600d4f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600d4f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600d7800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600d7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600d7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600d7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600d7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600d7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 79 (Thread 0x2ae5661a7700 (LWP 29627)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460083e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460083e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600d3800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600d3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600d3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600d3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600d3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600d3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 78 (Thread 0x2ae5662a8700 (LWP 29628)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460072c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460072c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460088800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460088800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460088800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460088800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460088800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460088800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 77 (Thread 0x2ae5666ac700 (LWP 29629)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46009b500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46009b500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46009a000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46009a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46009a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46009a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46009a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46009a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 76 (Thread 0x2ae5669af700 (LWP 29630)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460015200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460015200) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600d5800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600d5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600d5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600d5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600d5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600d5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 75 (Thread 0x2ae566ab0700 (LWP 29631)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460021b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460021b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600a8800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600a8800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600a8800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600a8800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600a8800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600a8800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 74 (Thread 0x2ae566cb2700 (LWP 29632)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460094f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460094f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460057800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460057800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460057800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460057800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460057800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460057800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 73 (Thread 0x2ae5674ba700 (LWP 29633)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46008a400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46008a400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600ab000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600ab000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600ab000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600ab000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600ab000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600ab000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 72 (Thread 0x2ae5675bb700 (LWP 29634)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600b7100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600b7100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46008b000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46008b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46008b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46008b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46008b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46008b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 71 (Thread 0x2ae5676bc700 (LWP 29635)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600b4f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600b4f00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46009c000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46009c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46009c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46009c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46009c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46009c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 70 (Thread 0x2ae5677bd700 (LWP 29636)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600aa500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600aa500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600c0000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600c0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600c0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600c0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600c0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 69 (Thread 0x2ae567bc1700 (LWP 29637)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600d7100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600d7100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460080000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460080000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460080000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460080000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460080000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460080000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 68 (Thread 0x2ae567ec4700 (LWP 29638)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46002a300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46002a300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46008f000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46008f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46008f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46008f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46008f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46008f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 67 (Thread 0x2ae64c100700 (LWP 29639)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46005b500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46005b500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46007e000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46007e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46007e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46007e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46007e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46007e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 66 (Thread 0x2ae64c201700 (LWP 29640)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600a8300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600a8300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600ad000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600ad000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600ad000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600ad000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600ad000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600ad000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 65 (Thread 0x2ae64c706700 (LWP 29641)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600bb600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600bb600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600b5800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600b5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600b5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600b5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600b5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600b5800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 64 (Thread 0x2ae64cb0a700 (LWP 29642)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600dfa00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600dfa00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460091000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460091000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460091000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460091000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460091000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460091000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 63 (Thread 0x2ae64cc0b700 (LWP 29643)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460088300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460088300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460095800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460095800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460095800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460095800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460095800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460095800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 62 (Thread 0x2ae64ce0d700 (LWP 29644)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600ac700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600ac700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600a4800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600a4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600a4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600a4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600a4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600a4800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 61 (Thread 0x2ae64cf0e700 (LWP 29645)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460070a00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460070a00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460093800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460093800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460093800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460093800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460093800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460093800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 60 (Thread 0x2ae64d00f700 (LWP 29646)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460041b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460041b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600a6800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600a6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600a6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600a6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600a6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600a6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 59 (Thread 0x2ae64d411700 (LWP 29647)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46003d700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46003d700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600bc000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600bc000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600bc000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600bc000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600bc000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600bc000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 58 (Thread 0x2ae64d512700 (LWP 29648)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460086000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460086000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46002d000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46002d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46002d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46002d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46002d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46002d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 57 (Thread 0x2ae64d613700 (LWP 29649)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600c6100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600c6100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae46007c000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae46007c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae46007c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae46007c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae46007c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46007c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 56 (Thread 0x2ae64d714700 (LWP 29650)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460074e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae460074e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600cb000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600cb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600cb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600cb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600cb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600cb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 55 (Thread 0x2ae64d815700 (LWP 29651)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600bfa00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600bfa00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae460079800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae460079800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae460079800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae460079800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae460079800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460079800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 54 (Thread 0x2ae64d916700 (LWP 29652)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600cc700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600cc700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600e7800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600e7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600e7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600e7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600e7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600e7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 53 (Thread 0x2ae64da17700 (LWP 29653)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46006e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae46006e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600e9800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600e9800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600e9800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600e9800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600e9800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600e9800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 52 (Thread 0x2ae64db18700 (LWP 29654)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600c1c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae4600c1c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::IWait (this=this at entry=0x87d000 , Self=Self at entry=0x2ae4600eb000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4 0x00002ae393b51ef1 in Monitor::wait (this=0x87d000 , no_safepoint_check=no_safepoint_check at entry=true, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1091 #5 0x00002ae393d79213 in ThreadsSMRSupport::smr_delete (thread=thread at entry=0x2ae4600eb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/threadSMR.cpp:981 #6 0x00002ae393d732c8 in smr_delete (this=0x2ae4600eb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:209 #7 JavaThread::thread_main_inner (this=this at entry=0x2ae4600eb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1801 #8 0x00002ae393d736c6 in JavaThread::run (this=0x2ae4600eb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #9 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600eb000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #10 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #11 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460061c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 50 (Thread 0x2ae4970b7700 (LWP 29679)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46005cf00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46005cf00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460055800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460055800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460055800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460055800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460055800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460055800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460055800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 49 (Thread 0x2ae4959a0700 (LWP 29680)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46001b500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46001b500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460031800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460031800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460031800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460031800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460031800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460031800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460031800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 48 (Thread 0x2ae5671b7700 (LWP 29681)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46004c800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46004c800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460069000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460069000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460069000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460069000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460069000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460069000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460069000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 47 (Thread 0x2ae566fb5700 (LWP 29682)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46003f900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46003f900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46006f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46006f800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46006f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46006f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46006f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46006f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46006f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 46 (Thread 0x2ae64ca09700 (LWP 29683)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460099400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460099400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460060800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460060800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460060800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460060800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460060800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460060800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460060800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 45 (Thread 0x2ae64e520700 (LWP 29684)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae43408c900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae43408c900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460097800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460097800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460097800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460097800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460097800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460097800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460097800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 44 (Thread 0x2ae49589f700 (LWP 29685)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460061500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46005a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46005a000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46005a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46005a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46005a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46005a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46005a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 43 (Thread 0x2ae495aa1700 (LWP 29686)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46002c600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46002c600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460037800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460037800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460037800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460037800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460037800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460037800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460037800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 42 (Thread 0x2ae567fc5700 (LWP 29687)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46005d700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46005d700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c9000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600c9000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600c9000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600c9000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600c9000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c9000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c9000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 41 (Thread 0x2ae49559c700 (LWP 29688)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600a1c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600a1c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600b7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600b7800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600b7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600b7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600b7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600b7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600b7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 40 (Thread 0x2ae64c605700 (LWP 29689)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460068400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460068400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460071800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460071800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460071800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460071800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460071800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460071800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460071800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 39 (Thread 0x2ae495299700 (LWP 29690)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46003b500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46003b500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460010800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460010800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460010800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460010800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460010800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460010800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460010800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 38 (Thread 0x2ae567cc2700 (LWP 29691)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460017000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460017000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46001c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46001c000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46001c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46001c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46001c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46001c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46001c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 37 (Thread 0x2ae64cd0c700 (LWP 29692)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600d9400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600d9400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460053800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460053800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460053800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460053800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460053800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460053800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460053800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 36 (Thread 0x2ae496bb2700 (LWP 29693)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460038900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460038900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46004b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46004b000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46004b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46004b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46004b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46004b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46004b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 35 (Thread 0x2ae495198700 (LWP 29694)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600ca500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600ca500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460033800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460033800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460033800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460033800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460033800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460033800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460033800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 34 (Thread 0x2ae566eb4700 (LWP 29695)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460052800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460052800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460042800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460042800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460042800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460042800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460042800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460042800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460042800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 33 (Thread 0x2ae4978bf700 (LWP 29696)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460054800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460054800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460051800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460051800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460051800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460051800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460051800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460051800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460051800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 32 (Thread 0x2ae566db3700 (LWP 29697)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460051300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460051300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460073800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460073800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460073800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460073800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460073800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460073800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460073800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 31 (Thread 0x2ae495ca3700 (LWP 29698)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460057300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460057300) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46005c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46005c000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46005c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46005c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46005c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46005c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46005c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 30 (Thread 0x2ae64c807700 (LWP 29699)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460059500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460059500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460012800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460012800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460012800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460012800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460012800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460012800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460012800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 29 (Thread 0x2ae49569d700 (LWP 29700)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46009fa00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46009fa00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460035800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460035800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460035800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460035800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460035800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460035800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460035800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 28 (Thread 0x2ae5678be700 (LWP 29701)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460063e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460063e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46005e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46005e000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46005e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46005e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46005e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46005e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46005e000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 27 (Thread 0x2ae567ac0700 (LWP 29702)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460023d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460023d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460025000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460025000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460025000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460025000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460025000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460025000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460025000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 26 (Thread 0x2ae5667ad700 (LWP 29703)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600e4b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600e4b00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600b2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600b2000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600b2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600b2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600b2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600b2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600b2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 25 (Thread 0x2ae5679bf700 (LWP 29704)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460043d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460043d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460014000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460014000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460014000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460014000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460014000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460014000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460014000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 24 (Thread 0x2ae5672b8700 (LWP 29705)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460046000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460046000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46004d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46004d000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46004d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46004d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46004d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46004d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46004d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 23 (Thread 0x2ae5664aa700 (LWP 29706)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46006c600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46006c600) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600cf000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600cf000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600cf000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600cf000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600cf000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600cf000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600cf000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 22 (Thread 0x2ae5665ab700 (LWP 29707)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46004a400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46004a400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46002b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46002b000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46002b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46002b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46002b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46002b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46002b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 21 (Thread 0x2ae567dc3700 (LWP 29708)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460011500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460011500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460029000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460029000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460029000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460029000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460029000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460029000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460029000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 20 (Thread 0x2ae495097700 (LWP 29709)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600bd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600bd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460086800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460086800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460086800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460086800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460086800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460086800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460086800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 19 (Thread 0x2ae496eb5700 (LWP 29710)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46004e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46004e800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600c6800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600c6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600c6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600c6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c6800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 18 (Thread 0x2ae49488f700 (LWP 29711)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600b2d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600b2d00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460075800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460075800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460075800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460075800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460075800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460075800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460075800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 17 (Thread 0x2ae495ba2700 (LWP 29712)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460035000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460035000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46008d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46008d000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46008d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46008d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46008d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46008d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46008d000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 16 (Thread 0x2ae4972b9700 (LWP 29713)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460050a00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460050a00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46002f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46002f000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46002f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46002f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46002f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46002f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46002f000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 15 (Thread 0x2ae494f96700 (LWP 29714)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460097100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460097100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600e3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600e3800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600e3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600e3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600e3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600e3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600e3800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 14 (Thread 0x2ae5673b9700 (LWP 29715)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46009d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46009d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460026800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460026800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460026800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460026800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460026800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460026800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460026800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 13 (Thread 0x2ae494c93700 (LWP 29716)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46001b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46001b000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46003c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46003c000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46003c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46003c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46003c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46003c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46003c000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 12 (Thread 0x2ae494a91700 (LWP 29717)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600dd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600dd800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600da000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600da000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600da000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600da000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600da000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600da000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600da000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 11 (Thread 0x2ae494b92700 (LWP 29718)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460043700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460043700) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600be000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600be000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600be000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600be000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600be000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600be000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600be000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 10 (Thread 0x2ae494d94700 (LWP 29719)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46005f900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46005f900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600a2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600a2800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600a2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600a2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600a2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600a2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600a2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 9 (Thread 0x2ae494e95700 (LWP 29720)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae46006a400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae46006a400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46003a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46003a000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46003a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46003a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46003a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46003a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46003a000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 8 (Thread 0x2ae49579e700 (LWP 29721)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460032c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460032c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600a0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600a0000, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600a0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600a0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600a0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600a0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600a0000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 7 (Thread 0x2ae4976bd700 (LWP 29722)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600a3e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600a3e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460084800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460084800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460084800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460084800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460084800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460084800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460084800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 6 (Thread 0x2ae4977be700 (LWP 29723)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460052c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460052c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae460017800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae460017800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae460017800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae460017800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae460017800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae460017800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae460017800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x2ae5663a9700 (LWP 29724)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae4600ae900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae4600ae900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46004f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46004f800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46004f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46004f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46004f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46004f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46004f800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x2ae5668ae700 (LWP 29725)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460054e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460054e00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae46006d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae46006d800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae46006d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae46006d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae46006d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae46006d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae46006d800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x2ae566bb1700 (LWP 29726)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460034900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460034900) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600dc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600dc800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600dc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600dc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600dc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600dc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600dc800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x2ae64c302700 (LWP 29727)): #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460037000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460037000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600ed800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 #4 0x00002ae393b512c1 in lock (Self=0x2ae4600ed800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 #7 thread_started (thread=0x2ae4600ed800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 #8 JvmtiEventController::thread_started (thread=0x2ae4600ed800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600ed800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600ed800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600ed800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x2ae3921ad880 (LWP 27915)): #0 0x00002ae3927b2f57 in pthread_join () from /lib64/libpthread.so.0 #1 0x00002ae3925a2c7d in ContinueInNewThread0 (continuation=continuation at entry=0x2ae39259d8e0 , stack_size=1048576, args=args at entry=0x7ffffdffd350) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/unix/native/libjli/java_md_solinux.c:749 #2 0x00002ae39259f3d2 in ContinueInNewThread (ifn=ifn at entry=0x7ffffdffd450, threadStackSize=, argc=, argv=0x873c00 , mode=mode at entry=0, what=what at entry=0x0, ret=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/share/native/libjli/java.c:2351 #3 0x00002ae3925a2d3b in JVMInit (ifn=ifn at entry=0x7ffffdffd450, threadStackSize=, argc=, argv=, mode=0, mode at entry=1, what=0x0, what at entry=0x8739e0 "applications.kitchensink.process.stress.Main", ret=) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/unix/native/libjli/java_md_solinux.c:796 #4 0x00002ae3925a09c8 in JLI_Launch (argc=, argv=, jargc=, jargv=, appclassc=0, appclassv=0x0, fullversion=0x400c30 "12-internal+0-2018-10-19-0235139.lmesnik.hs-bigapps", dotversion=0x400c1e "0.0", pname=0x400c19 "java", lname=0x400c19 "java", javaargs=0 '\000', cpwildcard=1 '\001', javaw=0 '\000', ergo=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/java.base/share/native/libjli/java.c:341 #5 0x00000000004009cc in compressed_integers () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp:39 #6 WriterHost (thread=0x7ffffe0016f0, storage=0x2ae3922b0700, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp:138 #7 EventWriterHost (thread=0x7ffffe0016f0, storage=0x2ae3922b0700, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/writers/jfrEventWriterHost.inline.hpp:33 #8 StackEventWriterHost (thread=0x7ffffe0016f0, storage=0x2ae3922b0700, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/writers/jfrEventWriterHost.inline.hpp:83 #9 write_event (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/recorder/service/jfrEvent.hpp:163 #10 commit (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/recorder/service/jfrEvent.hpp:92 #11 AllocTracer::send_allocation_outside_tlab (klass=0x0, obj=, alloc_size=140737454806552, thread=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/allocTracer.cpp:41 #12 0x00002ae392bebc05 in __libc_start_main () from /lib64/libc.so.6 #13 0x0000000000400a65 in write (len=1, value=, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp:75 #14 write (value=46943591922256, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/writers/jfrWriterHost.inline.hpp:184 #15 write_event (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/recorder/service/jfrEvent.hpp:166 #16 commit (this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/jfr/recorder/service/jfrEvent.hpp:92 #17 AllocTracer::send_allocation_outside_tlab (klass=, obj=, alloc_size=140737454806544, thread=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/gc/shared/allocTracer.cpp:41 From david.holmes at oracle.com Tue Oct 23 08:34:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Oct 2018 18:34:12 +1000 Subject: The failure In-Reply-To: <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> Message-ID: <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> Hi Serguei, The VMThread is executing VM_HandshakeAllThreads which is not a safepoint operation. There's no real way to tell from the stacks what it's stuck on. David On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: > Hi David, > > You are right, thanks. > It means, this deadlock needs more analysis. > For completeness, the stack traces are in attachments. > > Thanks, > Serguei > > > On 10/23/18 00:43, David Holmes wrote: >> Hi Serguei, >> >> The JvmtiThreadState_lock is always acquired with safepoint checks >> enabled, so all JavaThreads blocked trying to acquire it will be >> _thread_blocked and so safepoint-safe and so won't be holding up the >> safepoint. >> >> David >> >> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>> Hi, >>> >>> I've added the seviceability-dev mailing list. >>> It can be interesting for the SVC folks. :) >>> >>> >>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>> Hi >>>> >>>> Seems last version also crashes with 2 other different symptoms. >>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>> >>>> >>>> >>>> >>>> Also it might hangs with ?stack attached. ?Seems that test might be >>>> blocked because it invoke 2 jvmti methods. Can jvmti agent invoke >>>> jvmti methods from different threads? >>> >>> Yes, in general. >>> However, you have to be careful when using debugging features. >>> Below, one thread is enabling single stepping while another thread is >>> being suspended. >>> Both are blocked at a safepoint which is Okay in general but not Okay >>> if they hold any lock. >>> For instance, the thread #152 is holding the monitor JvmtiThreadState. >>> >>> Also, I see a couple of more threads that are interesting as well: >>> >>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>> (this=this at entry=0x2ae3984c9100) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>> >>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>> >>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>> >>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984c7800, >>> this=0x2ae398024f10) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>> >>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>> >>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>> this=) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>> >>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>> (task=task at entry=0x2ae48800ff40) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>> >>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>> >>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>> (this=this at entry=0x2ae3984c7800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>> >>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>> >>> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c7800) >>> at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>> >>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>> >>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>> (this=this at entry=0x2ae3984cbb00) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>> >>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>> >>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>> >>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>> this=0x2ae398024f10) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>> >>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>> >>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>> this=) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>> >>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>> (task=task at entry=0x2ae49c00a670) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>> >>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>> >>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>> (this=this at entry=0x2ae3984ca800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>> >>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>> >>> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984ca800) >>> at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>> >>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>> >>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>> /lib64/libpthread.so.0 >>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>> (this=this at entry=0x2ae460061c00) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>> >>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>> >>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>> >>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>> this=0x2ae398024f10) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>> >>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>> >>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>> this=) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>> >>> #7? thread_started (thread=0x2ae4600c2800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>> >>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>> >>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>> (thread=thread at entry=0x2ae4600c2800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>> >>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>> >>> #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c2800) >>> at >>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>> >>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>> >>> >>> These two thread are blocked on the monitor JvmtiThreadState_lock in >>> the function ciEnv::cache_jvmti_state(). >>> Also, there are many threads (like #51) that are executing >>> JvmtiExport::post_thread_start and blocked on the same monitor. >>> >>> >>> Now, the question is why this safepoint can not start? >>> What thread is blocking it? Or in reverse, what thread this safepoint >>> is waiting for? >>> >>> I think, this safepoint operation is waiting for all threads that are >>> blocked on the JvmtiThreadState_lock. >>> >>> Conclusion: >>> >>> The deadlock is: >>> >>> Thread #152: >>> ?? - grabbed the monitor JvmtiThreadState_lock >>> ?? - blocked in the VM_GetCurrentLocation in the function >>> JvmtiEnvThreadState::reset_current_location() >>> >>> Many other threads: >>> ?? - blocked on the monitor JvmtiThreadState_lock >>> ?? - can not reach the blocked at a safepoint state (all threads have >>> to reach this state for this safepoint to happen) >>> >>> It seems to me, this is a bug which has to be filed. >>> >>> My guess is that this will stop to reproduce after if you turn off >>> the single stepping for thread #152. >>> Please, let me know about the results. >>> >>> >>>> Assuming that crashes look like VM bugs I think it make sense to >>>> integrate jvmti changes but *don't* enabled jvmti module by default. >>> >>> This one is a deadlock. >>> However, the root cause is a race condition that can potentially >>> result in both deadlocks and crashes. >>> So, I'm curious if you observed crashes as well. >>> >>> >>>> And add to more tests with jvmti enabled. >>>> So anyone could easily run them to reproduce crashes. ?This test >>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>> >>>> Consider hang - I think that it might be product bug since I don't >>>> see any locking on my monitors. But I am not sure. Is it possible >>>> that any my code jvmti agent prevent VM to get into safepoint? >>>> Could we discuss it tomorrow or his week when you have a time? >>> >>> Yes, of course. >>> Let's find some time tomorrow. >>> >>> >>>> Any suggestion how to diagnose deadlock would be great. >>> >>> Analysis of stack traces is needed. >>> It is non-trivial in this particular case as there are so many >>> threads executed at the same time. >>> >>> >>>> Part of stack trace with 2 my threads only: >>>> >>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>> (this=this at entry=0x2ae454005800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>> >>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>> >>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>> >>>> 8 >>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=, >>>> timeout=timeout at entry=0, >>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>> try=false) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>> >>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>> (op=op at entry=0x2ae4940ffb10) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>> >>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>> (this=this at entry=0x2ae3985f2000) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>> >>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>> >>>> 47 >>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>> nv.cpp:955 >>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >>>> thread=0x2ae49929fdf8) at >>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>> >>>> /jvmtiEnter.cpp:527 >>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>> env=, p=) at >>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>> >>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) >>>> at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>> >>>> #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, >>>> __the_thread__=) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>> >>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>> (this=this at entry=0x2ae454004800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>> >>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>> >>>> #15 0x00002ae393ba0070 in thread_native_entry >>>> (thread=0x2ae454004800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>> >>>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>> >>>> >>>> >>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>> (this=this at entry=0x2ae3985e7400) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>> >>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>> >>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>> >>>> 8 >>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=, >>>> timeout=timeout at entry=0, >>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>> try=false) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>> >>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>> >>>> #6 ?0x00002ae3939965f3 in >>>> JvmtiEnvThreadState::reset_current_location >>>> (this=this at entry=0x2ae6bc000d80, >>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>> enabled=enabled at entry=tr\ >>>> ue) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>> >>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>> >>>> r.cpp:490 >>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>> (state=state at entry=0x2ae6bc000cd0) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>> >>>> :523 >>>> #9 ?0x00002ae393998168 in >>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>> >>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) >>>> at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>> re/prims/jvmtiEventController.cpp:818 >>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>> nt_thread=event_thread at entry=0x0) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>> >>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>> event_thread=event_\ >>>> thread at entry=0x0) at >>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>> >>>> #14 0x00002ae394d97989 in enable_events () at >>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>> >>>> #15 0x00002ae394d98070 in >>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>> (env=, this=) at /scratch/lmesnik/ws/h\ >>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>> >>>> #16 0x00002ae3a43ef257 in ?? () >>>> #17 0x00002ae3a43eede1 in ?? () >>>> #18 0x00002ae42705f878 in ?? () >>>> #19 0x00002ae40ad334e0 in ?? () >>>> #20 0x00002ae42705f8e0 in ?? () >>>> #21 0x00002ae40ad33c68 in ?? () >>>> #22 0x0000000000000000 in ?? () >>> >>> Thanks, >>> Serguei >>> >>>> >>>> >>>> >>>> Leonid >>>> >>>> >>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>> wrote: >>>>> >>>>> Hi Leonid, >>>>> >>>>> There is an existing bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> During fixing kitchensink I get >>>>>> assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth >>>>>> out of sync >>>>>> >>>>>> Do you know if i might be bug in my jvmti agent? >>>>>> >>>>>> Leonid >>>>>> >>>>>> >>>>>> # >>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>> # >>>>>> # ?Internal Error >>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>> pid=13926, tid=13962 >>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>> cur_stack_depth out of sync >>>>>> # >>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug >>>>>> build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, >>>>>> tiered, compressed oops, g1 gc, linux-amd64) >>>>>> # Core dump will be written. Default location: Core dumps may be >>>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P >>>>>> %I %h" (or dumping to >>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>> >>>>>> # >>>>>> # If you would like to submit a bug report, please visit: >>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>> # >>>>>> >>>>>> --------------- ?S U M M A R Y ------------ >>>>>> >>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false >>>>>> -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>> -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>> applications.kitchensink.process.stress.Main >>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>> >>>>>> >>>>>> Host: scaaa118.us.oracle.com , >>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >>>>>> Linux Server release 7.3 >>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d 0h >>>>>> 0m 31s) >>>>>> >>>>>> --------------- ?T H R E A D ?--------------- >>>>>> >>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" [stack: >>>>>> 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>> >>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, void*, >>>>>> char const*, int, char const*, char const*, __va_list_tag*)+0x2f >>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>>> const*, char const*, ...)+0x100 >>>>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>> V ?[libjvm.so+0x11f3257] >>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>> V ?[libjvm.so+0x19040be] >>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>> .constprop.51]+0x18e >>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>> >>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>> >>>>> >>>> >>> > From gary.adams at oracle.com Tue Oct 23 12:40:21 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 23 Oct 2018 08:40:21 -0400 Subject: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD In-Reply-To: <1CE64BD7-ECD1-43A8-B8C9-CE2EFA31BAEA@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> <5BC86A9A.3080602@oracle.com> <253448DD-4920-442F-B057-C7F6E8AA95B9@oracle.com> <509FDA34-26AA-4B6A-81B6-8F59079C905D@oracle.com> <1191d89d-b44a-d0b4-b7db-91ec9752ff62@oracle.com> <48867FBF-FA00-4341-B9EA-5B53AAB39C6B@oracle.com> <5BCDBA31.6050300@oracle.com> <1CE64BD7-ECD1-43A8-B8C9-CE2EFA31BAEA@oracle.com> Message-ID: <5BCF16B5.9090000@oracle.com> Thanks for checking. I think it is Ok if the tests are only supported in the default locale. I think that restriction should be documented somewhere. If there is a simple way to check at runtime, we could issue a warning message. Definitely out of scope for this specific changeset. I wonder if this was discussed when the initial alternate locale messages were introduced. On 10/22/18, 5:54 PM, Daniil Titov wrote: > Hi Gary, > > As I see currently multiple tests already use the patterns that in fact are localized messages, e.g. for 'Breakpoint hit' the following tests expect to find this message in the JDB output. > > grep -rn 'Breakpoint hit' open/test/jdk/com/sun/jdi/ > open/test/jdk/com/sun/jdi//JdbMissStep.java:82: .shouldContain("Breakpoint hit"); > open/test/jdk/com/sun/jdi//JdbExprTest.java:73: .shouldContain("Breakpoint hit"); > open/test/jdk/com/sun/jdi//JdbVarargsTest.java:98: .shouldMatch("Breakpoint hit:.*varString\\(\\)"); > open/test/jdk/com/sun/jdi//lib/jdb/Jdb.java:81: public static final String BREAKPOINT_HIT = "Breakpoint hit:"; > open/test/jdk/com/sun/jdi//JdbMethodExitTest.java:204: .shouldContain("Breakpoint hit"); > open/test/jdk/com/sun/jdi//JdbMethodExitTest.java:303: .shouldContain("Breakpoint hit"); > ? > If we really want to get rid of this (e.g. for the cases when these tests are run with non-default English locale), I would suggest to file a separate issue for that rather than addressing it in the current fix. > > Best regards, > Daniil > > On 10/22/18, 4:50 AM, "Gary Adams" wrote: > > > Thanks for making the extra effort to avoid dependency on > the simple prompt matching. One thing to check with the > large reply matches - make sure the locale translated messages > do not interfere with the compiled pattern matching. > See MessageOutput.format(). > > On 10/19/18, 7:01 PM, Daniil Titov wrote: > > Hi Chris, > > > > Please review an updated version of the fix that makes the tests to use a custom pattern while waiting for the command to complete. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.05/ > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211736 > > > > Thanks! > > --Daniil > > > > > > ?On 10/19/18, 12:55 PM, "Chris Plummer" wrote: > > > > On 10/19/18 9:47 AM, Daniil Titov wrote: > > > Hi Gary and Chris, > > > > > > I am resending the previous email since the table in that email got corrupted. > > > > > > Below is what output jdb prints when a breakpoint is hit depending on what suspended policy is used: > > > > > > The current behavior. > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > > SUSPEND_EVENT_THREAD: Prompt is not printed, location is not printed > > > SUSPEND_NONE: Prompt is not printed, location is not printed > > > > > > The fix changes this behavior as the following: > > > > > > SUSPEND_ALL: Prompt is printed ( e.g. "main[1]"), location is printed > > > SUSPEND_EVENT_THREAD: Prompt is printed ( "> "), location is printed > > > SUSPEND_NONE: Prompt is printed ( "> "), location is printed > > I'm still in favor of this fix. > > > > > > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > Maybe we need a version of command() that takes a pattern to look for > > other than the prompt. > > > > Chris > > > > > > > > > Thanks! > > > --Daniil > > > > > > ?On 10/19/18, 9:27 AM, "Daniil Titov" wrote: > > > > > > Hi Gary and Chris, > > > > > > Below is the table that shows what jdb output is printed when a breakpoint is hit depending on what suspended policy is used: > > > > > > SUSPEND POLICY | PROMPT PRINTED | LOCATION PRINTED > > > --------------------------------------- |---------------------------|-------------------------- > > > SUSPEND_ALL. | yes, e.g. "main[1]" | yes > > > --------------------------------------- |-------------------------- |-------------------------- > > > SUSPEND_EVENT_THREAD | no | no > > > ----------------------------------------|------------------------ --|-------------------------- > > > SUSPEND_ALL. | no | no > > > > > > > > > The fix changes this behavior as the following: > > > > > > SUSPEND POLICY | PROMPT PRINTED. | LOCATION PRINTED > > > --------------------------------------- |----------------------------|-------------------------- > > > SUSPEND_ALL. | yes , e.g. "main[1]" | yes > > > --------------------------------------- |----------------------------|-------------------------- > > > SUSPEND_EVENT_THREAD | yes , ">" | yes > > > ----------------------------------------|--------------------------- |-------------------------- > > > SUSPEND_ALL. | yes, ">". | yes > > > > > > Could you please say is it OK for you or you want that the location was printed only for SUSPEND_ALL case? Or probably just leave all behavior unchanged and close the bug as "not an issue"? > > > > > > Regarding settable prompt... As I understand Gary's original concern was that waiting in tests for a simple prompt "> " (>  ) could be unreliable if this substring somehow appears in the output of the test program and the suggestion was to use more specific patterns for the cases when the full prompt (thread_name[frame_index]) is not printed ( e.g. when the current thread is not set). However, we need somehow pass this pattern to Jdb.command(JdbCommand) method otherwise it would keep waiting for the full prompt and fail with the timeout. Probably I am missing something here... > > > > > > > > > Thanks! > > > > > > Best regards, > > > Daniil > > > > > > > > > > > > ?On 10/19/18, 12:54 AM, "gary.adams at oracle.com" wrote: > > > > > > It's not clear to me if the omitted location information for the non > > > stopping > > > cases was intentional or not. It may be sufficient to know that the > > > event fired > > > without the extra information. > > > > > > I don't think a settable prompt is required either. There are plenty of > > > jdb commands that > > > could be used with the wait for message in tests that need to > > > synchronize at a specific > > > point in the test sequence. > > > > > > I don't think we see wait for simple prompt in any of the tests, because it > > > is not reliable enough. > > > > > > On 10/18/18 11:53 AM, Daniil Titov wrote: > > > > Hi Gary, > > > > > > > > Currently when a breakpoint is hit the message "Breakpoint hit:" is printed in the debugger output. What we do in this fix we just add more information about what exact breakpoint is hit. Do you suggest we should not print this line at all if suspend policy is SUSPEND_NONE? If so then it is not clear what is the use of the command "stop go ..." would be. Regarding waiting for the simple prompt, we could change JDbCommand to have a field to store a prompt pattern and use this pattern (if it was set) when waiting for command to complete. In tests when required we would set the pattern in JdbCommand to more complicated one matching a specific output we are expecting at this particular step. Do you think it would be a better approach? > > > > > > > > Thanks! > > > > > > > > Best regards, > > > > Daniil > > > > > > > > > > > > > > > > ?On 10/18/18, 4:09 AM, "Gary Adams" wrote: > > > > > > > > I'm not certain that we should be printing locations or prompts for > > > > events when the vm has not been suspended. This looks OK for the > > > > simple test case we are working on here, but in real life there may > > > > be a lot more output produced. > > > > > > > > The user has to select a specific thread before additional commands > > > > can be performed in the correct context. e.g. threads, thread n, where, ... > > > > So the information is available to the user. It doesn't have to be > > > > produced at the time the event is processed. > > > > > > > > I'm uncomfortable putting too much trust in waiting for the simple prompt, > > > > because there is too great a chance of false positives on such a small > > > > marker. > > > > > > > > > > > > On 10/17/18, 8: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). > > > > > >>> >> > > > > > >>> >> 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 thomas.schatzl at oracle.com Tue Oct 23 13:37:43 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 23 Oct 2018 15:37:43 +0200 Subject: RFR: 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: <208c3313a6ce24a97d121abf718b0b9dbf6ab023.camel@oracle.com> Hi Paul, sorry for the long wait. On Mon, 2018-10-08 at 23:49 +0000, Hohensee, Paul wrote: > 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/ Note that I reviewed the latest change at http://cr.openjdk.java.net/~phh/8196989/webrev.04/ Currently pushing this through our testing. At that point the thread itself has moved to a question of a particular detail, with too many indentations to the email text I wanted to actually answer, so I answered to the original email. :) > > 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. I will look at it. As David already mentioned, it also needs to mention the new flag regardless of whether introducing it as deprecated or not. > 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). > I think we discussed this before, but none of these so-called invariants are specified anywhere and artifacts of the particular heap layout and MXBean implementations for Serial GC/Parallel GC and CMS. My understanding is that there are implementations out there that assume just that - but those can just use the "legacy" mxbeans. Currently, the MXBean values for G1 have been hacked to conform to this scheme for "compatibility reasons" (e.g. eden regions max is -1; or just look at the sorry code bending over backwards in recalculate_sizes()). I would prefer to not carry on with this, particularly with the new collectors (ZGC and Shenandoah) in the future in mind, with a potential "young gen" going to have the same issues (not sure about Shenandoah going to have something like this, but I assume so for various reasons). This change would be a good opportunity to do things correctly and return values as the VM sees them (like proper max values for all MXBeans), and avoid another round of having a "UseLegacyMemoryMXBeans2" switch later. Additionally most of these invariants do not even hold for the "old" collectors if you look closely. One simple case is a GC occuring between readings of the MemoryMXBean (with the known workaround retry until you get consisten values instead of calling the right method), and the issue related to JDK-8207200 (which *exactly* did rely on these "invariants", and was broken because of that). I also want to point out that the jstat counters already return heap size as max capacity (which probably most of the MemoryMXBeans would also return if fixed). So overall I honestly do not like the scope of this change, i.e. this half-fixing of G1 MemoryMXBeans for all these reasons (while the change itself is good). Changing the values returned by MemoryMXBeans would not decrease the amount of information or quality you get, but rather improve both, and make sure that future generational enhancements of collectors won't have to bend backwards for broken code that assumes non-"invariants" again. > 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. My intuitive take on the values of the Free region space would be: - used = 0, there are never objects in there, it's the *free* space after all. - committed = number of regions committed to Free regions - max = current max heap size - other committed size, as this would then also encompass the so-called "Not Available" Free regions in G1. It would probably be too complicated and not relevant to the users to have an extra MXBean for those. > 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. - I am not sure about the reasons for the change in G1CollectedHeap::post_initialize(). Did you experience some problems, or is this some cleanup? - the comment in g1Collected.hpp:1224 is misplaced, if you touch it, please remove. The "surv rate groups" moved to G1Policy long ago. - the two "Record start/end, but take no time" comments in g1ConcurrentMark.cpp seem to not be very useful. The call below tells you that exactly that happens, but not why, adding no information. I would remove them. - the comments at the top of g1MemoryPool.hpp and g1MemoryPool.hpp:66-68 and 95-98 are nice but seem to mostly duplicate the information in the comment in g1MonitoringSupport.hpp. Maybe they could be merged a bit to avoid having too much duplicate information around (and refer to it in g1MemoryPool). - in the G1MonitoringSupport constructor, please avoid specifying multiple member variable initializations in the same line using additional formatting via spaces (I'm fine with additional newlines if you want to group them). That is somewhat uncommon to read. - g1MonitoringSupport.cpp:288: please remove the unused variable old_regions_count. - the comment in g1MonitoringSupport.hpp:277 needs to be made more concise (thanks for fixing up lots of comments in this change!) by adding something like: "Values between different returned MemoryUsage may not be consistent with each other." - memoryManager.cpp:214/248: please add braces around the return statement. Rest of the changes seems good. Thanks, Thomas From lois.foltan at oracle.com Tue Oct 23 14:34:14 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 23 Oct 2018 10:34:14 -0400 Subject: RFR(S) 8212200 assert when shared java.lang.Object is redefined by JVMTI agent In-Reply-To: References: <2a05dfef-f5e3-7f72-152c-a42be439d1b7@oracle.com> <12e90dc8-802d-92fb-e419-f9a6b523bb75@oracle.com> <75b95743-86be-860d-89b8-7e0b5f64ed43@oracle.com> Message-ID: <0a924689-c13c-db97-8439-d7c8376363f3@oracle.com> On 10/23/2018 12:09 AM, Ioi Lam wrote: > > > On 10/22/18 10:25 AM, Lois Foltan wrote: >> On 10/22/2018 1:49 AM, Ioi Lam wrote: >> >>> Hi David, >>> >>> Thanks for the review. Updated webrev: >>> >>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04/ >>> >>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v04.delta/ >>> >> >> Hi Ioi, >> >> Looks good.? A couple of comments: >> >> classfile/systemDictionary.cpp >> - line#1975 - My preference is to declare the variable sid outside >> the for statement and compare sid == 0 within the for loop conditional. > Do you mean this? > > bool SystemDictionary::is_well_known_klass(Symbol* class_name) { > ? int sid; > ? for (int i = 0; (sid = wk_init_info[i]) != 0; i++) { > ??? Symbol* symbol = vmSymbols::symbol_at((vmSymbols::SID)sid); > ??? if (class_name == symbol) { > ????? return true; > ??? } > ? } > ? return false; > } > Yes, I think that's better. >> - line#1981 - can you use class_name->fast_compare(symbol) for the >> equality check? >> > The comments around fast_compare says it's for vtable sorting only. Right, David pointed that out to me as well.? Comment retracted. > >> memory/heapShared.cpp >> - line#422 could be a ResourceMark rm(THREAD); >> > Fixed. Great, thanks! Lois > > Thanks > - Ioi > >> Thanks, >> Lois >> >>> >>> More comments below: >>> >>> >>> >>> On 10/21/18 6:57 PM, David Holmes wrote: >>>> Hi Ioi, >>>> >>>> Generally seems okay. >>>> >>>> On 22/10/2018 11:15 AM, Ioi Lam wrote: >>>>> Re-sending to the correct mailing lists. Please disregard the >>>>> other email. >>>>> >>>>> http://cr.openjdk.java.net/~iklam/jdk12/8212200-cds-jvmti-clfh-critical-classes.v03/ >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8212200 >>>>> >>>>> Hi, >>>>> >>>>> CDS has various built-in assumptions that classes loaded by >>>>> SystemDictionary::resolve_well_known_classes must not be replaced >>>>> by JVMTI ClassFileLoadHook during run time, including >>>>> >>>>> - field offsets computed in JavaClasses::compute_offsets >>>>> - the layout of the strings objects in the shared strings table >>>>> >>>>> The "well-known" classes can be replaced by ClassFileLoadHook only >>>>> when JvmtiExport::early_class_hook_env() is true. Therefore, the >>>>> fix is to disable CDS under this condition. >>>> >>>> I'm a little unclear why we have to iterate JvmtiEnv list when this >>>> has to be checked during JVMTI_PHASE_PRIMORDIAL? >>>> >>> I think you are asking about this new function? I don't like the >>> name "early_class_hook_env()". Maybe I should change it to >>> "has_early_class_hook_env()"? >>> >>> >>> bool JvmtiExport::early_class_hook_env() { >>> ? JvmtiEnvIterator it; >>> ? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >>> ??? if (env->early_class_hook_env()) { >>> ????? return true; >>> ??? } >>> ? } >>> ? return false; >>> } >>> >>> This function matches condition in the existing code that would call >>> into ClassFileLoadHook: >>> >>> class JvmtiClassFileLoadHookPoster { >>> ?... >>> ? void post_all_envs() { >>> ??? JvmtiEnvIterator it; >>> ??? for (JvmtiEnv* env = it.first(); env != NULL; env = it.next(env)) { >>> ? ? ??? .. >>> ??????? post_to_env(env, true); >>> ??? } >>> ? } >>> ... >>> ? void post_to_env(JvmtiEnv* env, bool caching_needed) { >>> ??? if (env->phase() == JVMTI_PHASE_PRIMORDIAL && >>> !env->early_class_hook_env()) { >>> ????? return; >>> ??? } >>> >>> >>> post_all_envs() is called just before a class is about to be loaded >>> in the JVM. So if *any* env->early_class_hook_env() returns true, >>> there's a chance that it will replace a well-known class.So, as a >>> preventive measure, CDS will be disabled. >>> >>> >>> >>>>> I have added a few test cases to try to replace shared classes, >>>>> including well-known classes and other classes. See >>>>> comments in ReplaceCriticalClasses.java for details. >>>>> >>>>> As a clean up, I also renamed all use of "preloaded" in >>>>> the source code to "well-known". They refer to the same thing >>>>> in HotSpot, so there's no need to use 2 terms. Also, The word >>>>> "preloaded" is ambiguous -- it's unclear when "preloading" happens, >>>>> and could be confused with what CDS does during archive dump time. >>>> >>>> A few specific comments: >>>> >>>> src/hotspot/share/classfile/systemDictionary.cpp >>>> >>>> + bool SystemDictionary::is_well_known_klass(Symbol* class_name) { >>>> +?? for (int i = 0; ; i++) { >>>> +???? int sid = wk_init_info[i]; >>>> +???? if (sid == 0) { >>>> +?????? break; >>>> +???? } >>>> >>>> I take it a zero value is a guaranteed end-of-list sentinel? >>>> >>> >>> Yes. The array is defined just a few lines above: >>> >>> static const short wk_init_info[] = { >>> ? #define WK_KLASS_INIT_INFO(name, symbol) \ >>> ??? ((short)vmSymbols::VM_SYMBOL_ENUM_NAME(symbol)), >>> >>> ? WK_KLASSES_DO(WK_KLASS_INIT_INFO) >>> ? #undef WK_KLASS_INIT_INFO >>> ? 0 >>> }; >>> >>> Also, >>> >>> class vmSymbols: AllStatic { >>> ? enum SID { >>> ??? NO_SID = 0, >>> ??? .... >>> >>> >>> >>>> + for (int i=FIRST_WKID; i>>> >>>> Style nit: need spaces around = and < >>>> >>> >>> Fixed. >>> >>>> --- >>>> >>>> test/hotspot/jtreg/runtime/SharedArchiveFile/serviceability/ReplaceCriticalClasses.java >>>> >>>> >>>> New file should have current copyright year only. >>>> >>> Fixed. >>> >>>> ?31? * @comment CDS should not be disabled -- these critical >>>> classes will be replaced because >>>> JvmtiExport::early_class_hook_env() is true. >>>> >>>> Comment seems contradictory: if we replace critical classes then >>>> CDS should be disabled right?? >>>> >>> Fixed. >>> >>>> I expected to see tests that checked for: >>>> >>>> "CDS is disabled because early JVMTI ClassFileLoadHook is in use." >>>> >>>> in the output. ?? >>>> >>> >>> It would have been easy if jtreg lets you check the output of @run >>> easily. Instead, your innocent suggestion has turned into 150+ lines >>> of new code :-( Maybe "let's write all shell tests in Java" isn't >>> such a great idea after all. >>> >>> >>> Now the test checks that whether CDS is indeed disabled, whether the >>> affected class is loaded from the shared archive, etc. >>> >>> Thanks >>> - Ioi >>> >>>> Thanks, >>>> David >>>> >>>> >>>>> >>>>> ?> In early e-mails Jiangli wrote: >>>>> ?> >>>>> ?> We should consider including more classes from the default >>>>> classlist >>>>> ?> in the test. Archived classes loaded during both 'early' phase >>>>> and after >>>>> ?> should be tested. >>>>> >>>>> Done. >>>>> >>>>> >>>>> ?> For future optimizations, we might want to prevent loading >>>>> additional >>>>> ?> shared classes if any of the archived system classes is changed. >>>>> >>>>> What's the benefit of doing this? Today we already stop loading a >>>>> shared >>>>> class if its super class was not loaded from the archive. >>>>> >>>>> >>>>> Thanks >>>>> - Ioi >>>>> >>> >> > From robbin.ehn at oracle.com Tue Oct 23 14:38:30 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 23 Oct 2018 16:38:30 +0200 Subject: The failure In-Reply-To: <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> Message-ID: <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> Hi, On 10/23/18 10:34 AM, David Holmes wrote: > Hi Serguei, > > The VMThread is executing VM_HandshakeAllThreads which is not a safepoint > operation. There's no real way to tell from the stacks what it's stuck on. I cannot find a thread that is not considered safepoint safe or is_ext_suspended (thread 146). So the handshake should go through. The handshake will log a warning after a while, is there such warning from the handshake operation? There are several threads competing with e.g. Threads_lock, and threads waiting for GC and several other VM ops, could it just be really slow? /Robbin > > David > > On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> You are right, thanks. >> It means, this deadlock needs more analysis. >> For completeness, the stack traces are in attachments. >> >> Thanks, >> Serguei >> >> >> On 10/23/18 00:43, David Holmes wrote: >>> Hi Serguei, >>> >>> The JvmtiThreadState_lock is always acquired with safepoint checks enabled, >>> so all JavaThreads blocked trying to acquire it will be _thread_blocked and >>> so safepoint-safe and so won't be holding up the safepoint. >>> >>> David >>> >>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi, >>>> >>>> I've added the seviceability-dev mailing list. >>>> It can be interesting for the SVC folks. :) >>>> >>>> >>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>> Hi >>>>> >>>>> Seems last version also crashes with 2 other different symptoms. >>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>> >>>>> >>>>> >>>>> >>>>> Also it might hangs with ?stack attached. ?Seems that test might be blocked >>>>> because it invoke 2 jvmti methods. Can jvmti agent invoke jvmti methods >>>>> from different threads? >>>> >>>> Yes, in general. >>>> However, you have to be careful when using debugging features. >>>> Below, one thread is enabling single stepping while another thread is being >>>> suspended. >>>> Both are blocked at a safepoint which is Okay in general but not Okay if >>>> they hold any lock. >>>> For instance, the thread #152 is holding the monitor JvmtiThreadState. >>>> >>>> Also, I see a couple of more threads that are interesting as well: >>>> >>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>> (this=this at entry=0x2ae3984c9100) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, this=>>> pointer>) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>> >>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>> (task=task at entry=0x2ae48800ff40) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>> >>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>> >>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>> (this=this at entry=0x2ae3984c7800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c7800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>> >>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>> (this=this at entry=0x2ae3984cbb00) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, this=0x2ae398024f10) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, this=>>> pointer>) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>> >>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>> (task=task at entry=0x2ae49c00a670) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>> >>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>> >>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>> (this=this at entry=0x2ae3984ca800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984ca800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>> >>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>> /lib64/libpthread.so.0 >>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>> (this=this at entry=0x2ae460061c00) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, this=0x2ae398024f10) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=>>> pointer>) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>> >>>> #7? thread_started (thread=0x2ae4600c2800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>> >>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>> >>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>> (thread=thread at entry=0x2ae4600c2800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>> >>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>> #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c2800) at >>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>> >>>> >>>> These two thread are blocked on the monitor JvmtiThreadState_lock in the >>>> function ciEnv::cache_jvmti_state(). >>>> Also, there are many threads (like #51) that are executing >>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>> >>>> >>>> Now, the question is why this safepoint can not start? >>>> What thread is blocking it? Or in reverse, what thread this safepoint is >>>> waiting for? >>>> >>>> I think, this safepoint operation is waiting for all threads that are >>>> blocked on the JvmtiThreadState_lock. >>>> >>>> Conclusion: >>>> >>>> The deadlock is: >>>> >>>> Thread #152: >>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>> JvmtiEnvThreadState::reset_current_location() >>>> >>>> Many other threads: >>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>> ?? - can not reach the blocked at a safepoint state (all threads have to >>>> reach this state for this safepoint to happen) >>>> >>>> It seems to me, this is a bug which has to be filed. >>>> >>>> My guess is that this will stop to reproduce after if you turn off the >>>> single stepping for thread #152. >>>> Please, let me know about the results. >>>> >>>> >>>>> Assuming that crashes look like VM bugs I think it make sense to integrate >>>>> jvmti changes but *don't* enabled jvmti module by default. >>>> >>>> This one is a deadlock. >>>> However, the root cause is a race condition that can potentially result in >>>> both deadlocks and crashes. >>>> So, I'm curious if you observed crashes as well. >>>> >>>> >>>>> And add to more tests with jvmti enabled. >>>>> So anyone could easily run them to reproduce crashes. ?This test would be >>>>> out of CI to don't introduce any bugs. Does it make sense? >>>>> >>>>> Consider hang - I think that it might be product bug since I don't see any >>>>> locking on my monitors. But I am not sure. Is it possible that any my code >>>>> jvmti agent prevent VM to get into safepoint? >>>>> Could we discuss it tomorrow or his week when you have a time? >>>> >>>> Yes, of course. >>>> Let's find some time tomorrow. >>>> >>>> >>>>> Any suggestion how to diagnose deadlock would be great. >>>> >>>> Analysis of stack traces is needed. >>>> It is non-trivial in this particular case as there are so many threads >>>> executed at the same time. >>>> >>>> >>>>> Part of stack trace with 2 my threads only: >>>>> >>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>> (this=this at entry=0x2ae454005800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>> 8 >>>>> #4 ?0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, >>>>> no_safepoint_check=, timeout=timeout at entry=0, >>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>> try=false) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=op at entry=0x2ae4940ffb10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>> (this=this at entry=0x2ae3985f2000) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>> 47 >>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>> nv.cpp:955 >>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >>>>> thread=0x2ae49929fdf8) at >>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>> >>>>> /jvmtiEnter.cpp:527 >>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>> env=, p=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>> #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, >>>>> __the_thread__=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>> (this=this at entry=0x2ae454004800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>> #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>> >>>>> >>>>> >>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>> (this=this at entry=0x2ae3985e7400) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>> 8 >>>>> #4 ?0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, >>>>> no_safepoint_check=, timeout=timeout at entry=0, >>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>> try=false) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>> #6 ?0x00002ae3939965f3 in JvmtiEnvThreadState::reset_current_location >>>>> (this=this at entry=0x2ae6bc000d80, >>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, enabled=enabled at entry=tr\ >>>>> ue) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>> >>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>> >>>>> r.cpp:490 >>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>> >>>>> :523 >>>>> #9 ?0x00002ae393998168 in JvmtiEventControllerPrivate::recompute_enabled () >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>> >>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>> re/prims/jvmtiEventController.cpp:818 >>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, thread=0x0, >>>>> event_type=JVMTI_EVENT_SINGLE_STEP, enabled=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>> nt_thread=event_thread at entry=0x0) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, event_thread=event_\ >>>>> thread at entry=0x0) at >>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>> >>>>> #14 0x00002ae394d97989 in enable_events () at >>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>> >>>>> #15 0x00002ae394d98070 in >>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>> (env=, this=) at /scratch/lmesnik/ws/h\ >>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>> >>>>> #16 0x00002ae3a43ef257 in ?? () >>>>> #17 0x00002ae3a43eede1 in ?? () >>>>> #18 0x00002ae42705f878 in ?? () >>>>> #19 0x00002ae40ad334e0 in ?? () >>>>> #20 0x00002ae42705f8e0 in ?? () >>>>> #21 0x00002ae40ad33c68 in ?? () >>>>> #22 0x0000000000000000 in ?? () >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> >>>>> >>>>> Leonid >>>>> >>>>> >>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>> >>>>>> Hi Leonid, >>>>>> >>>>>> There is an existing bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> During fixing kitchensink I get >>>>>>> assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of >>>>>>> sync >>>>>>> >>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>> >>>>>>> Leonid >>>>>>> >>>>>>> >>>>>>> # >>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>> # >>>>>>> # ?Internal Error >>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>> pid=13926, tid=13962 >>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out >>>>>>> of sync >>>>>>> # >>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug build >>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, tiered, >>>>>>> compressed oops, g1 gc, linux-amd64) >>>>>>> # Core dump will be written. Default location: Core dumps may be >>>>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" >>>>>>> (or dumping to >>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>> >>>>>>> # >>>>>>> # If you would like to submit a bug report, please visit: >>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>> # >>>>>>> >>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>> >>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false >>>>>>> -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal -XX:+StartAttachListener >>>>>>> -XX:NativeMemoryTracking=detail -XX:+FlightRecorder >>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>> applications.kitchensink.process.stress.Main >>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>> >>>>>>> >>>>>>> Host: scaaa118.us.oracle.com , Intel(R) >>>>>>> Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux Server >>>>>>> release 7.3 >>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d 0h 0m 31s) >>>>>>> >>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>> >>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" [stack: >>>>>>> 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, _nested_threads_hazard_ptr_cnt=0 >>>>>>> >>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], ?sp=0x00002af44f208720, >>>>>>> ?free space=1017k >>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char const*, char >>>>>>> const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char >>>>>>> const*, int, unsigned long)+0x2c3 >>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, void*, char >>>>>>> const*, int, char const*, char const*, __va_list_tag*)+0x2f >>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char const*, >>>>>>> char const*, ...)+0x100 >>>>>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>> V ?[libjvm.so+0x11f3257] ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>> V ?[libjvm.so+0x19040be] ?VMThread::evaluate_operation(VM_Operation*) >>>>>>> [clone .constprop.51]+0x18e >>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>> >>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: safepoint, >>>>>>> requested by thread 0x00002af4dc008800 >>>>>> >>>>>> >>>>> >>>> >> From jcbeyler at google.com Tue Oct 23 14:45:36 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 23 Oct 2018 07:45:36 -0700 Subject: RFR (M) 8212771: Remove remaining spaces before/after () for vmTestbase In-Reply-To: References: <39560b3f-41b5-bd64-4acf-7e81cf196953@oracle.com> Message-ID: Hi Paul, Thanks for the review! I created two new bugs for these two refactoring cases. They seem fairly uncommon so should be easy to fix throughout .cpp files in vmTestbase. https://bugs.openjdk.java.net/browse/JDK-8212822 https://bugs.openjdk.java.net/browse/JDK-8212824 So I'll keep them out of scope of this change as you recommended to do it separately ;-), Jc On Mon, Oct 22, 2018 at 5:10 PM Hohensee, Paul wrote: > Lgtm. > There?s a similar issue with ?{??}? you might want to fix separately, > except in the opposite direction :), e.g., in > test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp, > > +#define JVMTI_ERROR_CHECK(str,res) if (res != JVMTI_ERROR_NONE) { > printf(str); printf("%d\n",res); return res;} > > +#define JVMTI_ERROR_CHECK_EXPECTED_ERROR(str,res,err) if (res != err) { > printf(str); printf("unexpected error %d\n",res); return res;} > => > > +#define JVMTI_ERROR_CHECK(str,res) if (res != JVMTI_ERROR_NONE) { printf(str); printf("%d\n",res); return res; } > > +#define JVMTI_ERROR_CHECK_EXPECTED_ERROR(str,res,err) if (res != err) { printf(str); printf("unexpected error %d\n",res); return res; } > > > And somewhat different in > test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp > > + (threadConstructor = NSK_CPP_STUB4(GetMethodID, jni, klass, "", "()V")) != NULL)) { > > => > > + (threadConstructor = NSK_CPP_STUB4(GetMethodID, jni, klass, "", "()V")) != NULL)) { > > Paul > > *From: *serviceability-dev > on behalf of "serguei.spitsyn at oracle.com" > *Date: *Monday, October 22, 2018 at 3:15 PM > *To: *JC Beyler , " > serviceability-dev at openjdk.java.net" > *Subject: *Re: RFR (M) 8212771: Remove remaining spaces before/after () > for vmTestbase > > > > Hi Jc, > > It looks good. > > Thanks! > Serguei > > > On 10/22/18 11:30, JC Beyler wrote: > > Hi all, > > > > Here is the last webrev (3 out of 3) to remove the spaces after/before () > from vmTestbase. It is straightforward and I generated the webrev with > white-space changes showing up of course: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212771/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212771 > > > > Could I please get some reviews? > > > > Thanks, > > Jc > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From hohensee at amazon.com Tue Oct 23 14:55:06 2018 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 23 Oct 2018 14:55:06 +0000 Subject: RFR (M) 8212771: Remove remaining spaces before/after () for vmTestbase In-Reply-To: References: <39560b3f-41b5-bd64-4acf-7e81cf196953@oracle.com> Message-ID: <69F1A35C-4AEB-4F68-910B-8C4D8A63F80E@amazon.com> Thanks for filing the new RFEs! Paul From: JC Beyler Date: Tuesday, October 23, 2018 at 7:49 AM To: "Hohensee, Paul" Cc: "serguei.spitsyn at oracle.com" , "serviceability-dev at openjdk.java.net" Subject: Re: RFR (M) 8212771: Remove remaining spaces before/after () for vmTestbase Hi Paul, Thanks for the review! I created two new bugs for these two refactoring cases. They seem fairly uncommon so should be easy to fix throughout .cpp files in vmTestbase. https://bugs.openjdk.java.net/browse/JDK-8212822 https://bugs.openjdk.java.net/browse/JDK-8212824 So I'll keep them out of scope of this change as you recommended to do it separately ;-), Jc On Mon, Oct 22, 2018 at 5:10 PM Hohensee, Paul > wrote: Lgtm. There?s a similar issue with ?{??}? you might want to fix separately, except in the opposite direction :), e.g., in test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/MethodBind/JvmtiTest/JvmtiTest.cpp, +#define JVMTI_ERROR_CHECK(str,res) if (res != JVMTI_ERROR_NONE) { printf(str); printf("%d\n",res); return res;} +#define JVMTI_ERROR_CHECK_EXPECTED_ERROR(str,res,err) if (res != err) { printf(str); printf("unexpected error %d\n",res); return res;} => +#define JVMTI_ERROR_CHECK(str,res) if (res != JVMTI_ERROR_NONE) { printf(str); printf("%d\n",res); return res; } +#define JVMTI_ERROR_CHECK_EXPECTED_ERROR(str,res,err) if (res != err) { printf(str); printf("unexpected error %d\n",res); return res; } And somewhat different in test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/aod/jvmti_aod.cpp + (threadConstructor = NSK_CPP_STUB4(GetMethodID, jni, klass, "", "()V")) != NULL)) { => + (threadConstructor = NSK_CPP_STUB4(GetMethodID, jni, klass, "", "()V")) != NULL)) { Paul From: serviceability-dev > on behalf of "serguei.spitsyn at oracle.com" > Date: Monday, October 22, 2018 at 3:15 PM To: JC Beyler >, "serviceability-dev at openjdk.java.net" > Subject: Re: RFR (M) 8212771: Remove remaining spaces before/after () for vmTestbase Hi Jc, It looks good. Thanks! Serguei On 10/22/18 11:30, JC Beyler wrote: Hi all, Here is the last webrev (3 out of 3) to remove the spaces after/before () from vmTestbase. It is straightforward and I generated the webrev with white-space changes showing up of course: Webrev: http://cr.openjdk.java.net/~jcbeyler/8212771/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212771 Could I please get some reviews? Thanks, Jc -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Oct 23 16:09:28 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Oct 2018 09:09:28 -0700 Subject: The failure In-Reply-To: <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> Message-ID: <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> Hi David and Robbin, I have an idea that needs to be checked. It can be almost the same deadlock scenario that I've already explained but more sophisticated. I suspect a scenario with JvmtiThreadState_lock that the flag Monitor::_safepoint_check_always does not help much. It can be verified by checking what monitors are used by the blocked threads. Thanks, Serguei On 10/23/18 07:38, Robbin Ehn wrote: > Hi, > > On 10/23/18 10:34 AM, David Holmes wrote: >> Hi Serguei, >> >> The VMThread is executing VM_HandshakeAllThreads which is not a >> safepoint operation. There's no real way to tell from the stacks what >> it's stuck on. > > I cannot find a thread that is not considered safepoint safe or > is_ext_suspended (thread 146). So the handshake should go through. The > handshake will log a warning after a while, is there such warning from > the handshake operation? > > There are several threads competing with e.g. Threads_lock, and > threads waiting for GC and several other VM ops, could it just be > really slow? > > /Robbin > >> >> David >> >> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> You are right, thanks. >>> It means, this deadlock needs more analysis. >>> For completeness, the stack traces are in attachments. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/23/18 00:43, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>> _thread_blocked and so safepoint-safe and so won't be holding up >>>> the safepoint. >>>> >>>> David >>>> >>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi, >>>>> >>>>> I've added the seviceability-dev mailing list. >>>>> It can be interesting for the SVC folks. :) >>>>> >>>>> >>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Also it might hangs with ?stack attached. ?Seems that test might >>>>>> be blocked because it invoke 2 jvmti methods. Can jvmti agent >>>>>> invoke jvmti methods from different threads? >>>>> >>>>> Yes, in general. >>>>> However, you have to be careful when using debugging features. >>>>> Below, one thread is enabling single stepping while another thread >>>>> is being suspended. >>>>> Both are blocked at a safepoint which is Okay in general but not >>>>> Okay if they hold any lock. >>>>> For instance, the thread #152 is holding the monitor >>>>> JvmtiThreadState. >>>>> >>>>> Also, I see a couple of more threads that are interesting as well: >>>>> >>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>> (this=this at entry=0x2ae3984c9100) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>> #4? 0x00002ae393b512c1 in lock >>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>> this=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>> >>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>> >>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>> (task=task at entry=0x2ae48800ff40) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>> >>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>> >>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>> (this=this at entry=0x2ae3984c7800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>> (thread=0x2ae3984c7800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>> >>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>> (this=this at entry=0x2ae3984cbb00) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>> this=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>> this=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>> >>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>> >>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>> (task=task at entry=0x2ae49c00a670) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>> >>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>> >>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>> (this=this at entry=0x2ae3984ca800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>> (thread=0x2ae3984ca800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>> >>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>> (this=this at entry=0x2ae460061c00) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>> this=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>> this=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>> >>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>> >>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>> >>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>> >>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>> (thread=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>> >>>>> >>>>> These two thread are blocked on the monitor JvmtiThreadState_lock >>>>> in the function ciEnv::cache_jvmti_state(). >>>>> Also, there are many threads (like #51) that are executing >>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>> >>>>> >>>>> Now, the question is why this safepoint can not start? >>>>> What thread is blocking it? Or in reverse, what thread this >>>>> safepoint is waiting for? >>>>> >>>>> I think, this safepoint operation is waiting for all threads that >>>>> are blocked on the JvmtiThreadState_lock. >>>>> >>>>> Conclusion: >>>>> >>>>> The deadlock is: >>>>> >>>>> Thread #152: >>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>> JvmtiEnvThreadState::reset_current_location() >>>>> >>>>> Many other threads: >>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>> have to reach this state for this safepoint to happen) >>>>> >>>>> It seems to me, this is a bug which has to be filed. >>>>> >>>>> My guess is that this will stop to reproduce after if you turn off >>>>> the single stepping for thread #152. >>>>> Please, let me know about the results. >>>>> >>>>> >>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>> integrate jvmti changes but *don't* enabled jvmti module by default. >>>>> >>>>> This one is a deadlock. >>>>> However, the root cause is a race condition that can potentially >>>>> result in both deadlocks and crashes. >>>>> So, I'm curious if you observed crashes as well. >>>>> >>>>> >>>>>> And add to more tests with jvmti enabled. >>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>> >>>>>> Consider hang - I think that it might be product bug since I >>>>>> don't see any locking on my monitors. But I am not sure. Is it >>>>>> possible that any my code jvmti agent prevent VM to get into >>>>>> safepoint? >>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>> >>>>> Yes, of course. >>>>> Let's find some time tomorrow. >>>>> >>>>> >>>>>> Any suggestion how to diagnose deadlock would be great. >>>>> >>>>> Analysis of stack traces is needed. >>>>> It is non-trivial in this particular case as there are so many >>>>> threads executed at the same time. >>>>> >>>>> >>>>>> Part of stack trace with 2 my threads only: >>>>>> >>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>> /lib64/libpthread.so.0 >>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>> (this=this at entry=0x2ae454005800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>> 8 >>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>> out>, timeout=timeout at entry=0, >>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>> try=false) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>> 47 >>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>> nv.cpp:955 >>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>> >>>>>> /jvmtiEnter.cpp:527 >>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>> env=, p=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>> (this=0x2ae454004800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>> (this=this at entry=0x2ae454004800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>> (thread=0x2ae454004800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>> /lib64/libpthread.so.0 >>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>> >>>>>> >>>>>> >>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>> /lib64/libpthread.so.0 >>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>> 8 >>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>> out>, timeout=timeout at entry=0, >>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>> try=false) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>> #6 ?0x00002ae3939965f3 in >>>>>> JvmtiEnvThreadState::reset_current_location >>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>> enabled=enabled at entry=tr\ >>>>>> ue) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>> >>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>> >>>>>> r.cpp:490 >>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>> >>>>>> :523 >>>>>> #9 ?0x00002ae393998168 in >>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>> >>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>> env=0x2ae39801b270) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, >>>>>> enabled=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>> nt_thread=event_thread at entry=0x0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>> event_thread=event_\ >>>>>> thread at entry=0x0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>> >>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>> >>>>>> #15 0x00002ae394d98070 in >>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>> (env=, this=) at >>>>>> /scratch/lmesnik/ws/h\ >>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>> >>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>> #18 0x00002ae42705f878 in ?? () >>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>> #22 0x0000000000000000 in ?? () >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Leonid >>>>>> >>>>>> >>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>> wrote: >>>>>>> >>>>>>> Hi Leonid, >>>>>>> >>>>>>> There is an existing bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> During fixing kitchensink I get >>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>> cur_stack_depth out of sync >>>>>>>> >>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>>>> >>>>>>>> # >>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>> # >>>>>>>> # ?Internal Error >>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>> pid=13926, tid=13962 >>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>> cur_stack_depth out of sync >>>>>>>> # >>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>> (fastdebug build >>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed >>>>>>>> mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>> # Core dump will be written. Default location: Core dumps may >>>>>>>> be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g >>>>>>>> %t e %P %I %h" (or dumping to >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>> >>>>>>>> # >>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>> # >>>>>>>> >>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>> >>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>> -XX:+CrashOnOutOfMemoryError >>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>> -XX:+FlightRecorder >>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>> >>>>>>>> >>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, >>>>>>>> Oracle Linux Server release 7.3 >>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d >>>>>>>> 0h 0m 31s) >>>>>>>> >>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>> >>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>> >>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>> __va_list_tag*)+0x2f >>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>>>>> const*, char const*, ...)+0x100 >>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>> .constprop.51]+0x18e >>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>> >>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>> >>>>>>> >>>>>> >>>>> >>> From dean.long at oracle.com Tue Oct 23 16:46:48 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 23 Oct 2018 09:46:48 -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> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> Message-ID: On 10/22/18 3:31 PM, David Holmes wrote: > Sorry Dean I'm concerned about a thread termination bottleneck with > this. A simple microbenchmark that creates 500,000 threads that have > to run and terminate, shows a 15+% slowdown on my Linux box. I tried > to find some kind of real benchmarks that covers thread termination > but couldn't see anything specific. > > Can you at least run this through our performance system to see if any > of the regular benchmarks are affected. > OK, but even if the regular benchmarks don't show a difference, I'd feel better if microbenchmarks were not affected.? What if I go back to the original approach and add locking: ?? static jlong get_live_thread_count()??????? { MutexLocker mu(Threads_lock); return _live_threads_count->get_value() - _exiting_threads_count; } ?? static jlong get_daemon_thread_count()????? { MutexLocker mu(Threads_lock); return _daemon_threads_count->get_value() - _exiting_daemon_threads_count; } along with the other cleanups around is_daemon and is_hidden_thread? dl > Thanks, > David > > On 20/10/2018 1:28 PM, dean.long at oracle.com wrote: >> On 10/18/18 6:12 PM, Mandy Chung wrote: >>> >>> >>> On 10/18/18 12:27 AM, David Holmes wrote: >>>> Hi Dean, >>>> >>>> On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: >>>>> >>>>> You're right, I missed that.? I think the right thing to do is >>>>> call current_thread_exiting while holding the Threads_lock. >>>>> Then we can get rid of the parallel atomic counters.? So, here's >>>>> one more try: >>>>> >>>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ >>>> >>>> Okay that is the simple and obvious solution that doesn't require >>>> split counts. So I have to ask Mandy if she recalls why this >>>> approach wasn't taken 15 years ago when the exit counts were added >>>> as part of: >>>> >>> >>> It has been so long.? I think it's likely an oversight. >>>> https://bugs.openjdk.java.net/browse/JDK-4530538 ? >>>> >>>> Does taking the Threads_lock here cost too much and cause a thread >>>> termination bottleneck? >>> >>> If the contention on Threads_lock is not high (that seems to me), it >>> should be okay. ? I'm not close to the VM implementation (lot of >>> changes since then) and I don't have a definitive answer unless I >>> study the code closely.?? You and others have a better judgement on >>> this. >>> >>> AFAICT the change is okay. >>> >> >> Thanks Mandy.? David, OK to push? >> >> dl >> >>> Mandy >>> >>> >> From dean.long at oracle.com Tue Oct 23 18:05:00 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 23 Oct 2018 11:05:00 -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> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> Message-ID: <5b6265b6-36b3-4317-1e6a-8ba51c8a48b3@oracle.com> On 10/23/18 9:46 AM, dean.long at oracle.com wrote: > On 10/22/18 3:31 PM, David Holmes wrote: >> Sorry Dean I'm concerned about a thread termination bottleneck with >> this. A simple microbenchmark that creates 500,000 threads that have >> to run and terminate, shows a 15+% slowdown on my Linux box. I tried >> to find some kind of real benchmarks that covers thread termination >> but couldn't see anything specific. >> >> Can you at least run this through our performance system to see if >> any of the regular benchmarks are affected. >> > > OK, but even if the regular benchmarks don't show a difference, I'd > feel better if microbenchmarks were not affected.? What if I go back > to the original approach and add locking: > > ?? static jlong get_live_thread_count()??????? { MutexLocker > mu(Threads_lock); return _live_threads_count->get_value() - > _exiting_threads_count; } > ?? static jlong get_daemon_thread_count()????? { MutexLocker > mu(Threads_lock); return _daemon_threads_count->get_value() - > _exiting_daemon_threads_count; } > > along with the other cleanups around is_daemon and is_hidden_thread? > Some micro-benchmarks like SecureRandomBench show a regression with webrev.7.? I could go back to webrev.5 and then we shouldn't need any locking in the get_*() functions. dl > dl > >> Thanks, >> David >> >> On 20/10/2018 1:28 PM, dean.long at oracle.com wrote: >>> On 10/18/18 6:12 PM, Mandy Chung wrote: >>>> >>>> >>>> On 10/18/18 12:27 AM, David Holmes wrote: >>>>> Hi Dean, >>>>> >>>>> On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: >>>>>> >>>>>> You're right, I missed that.? I think the right thing to do is >>>>>> call current_thread_exiting while holding the Threads_lock. >>>>>> Then we can get rid of the parallel atomic counters. So, here's >>>>>> one more try: >>>>>> >>>>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ >>>>> >>>>> Okay that is the simple and obvious solution that doesn't require >>>>> split counts. So I have to ask Mandy if she recalls why this >>>>> approach wasn't taken 15 years ago when the exit counts were added >>>>> as part of: >>>>> >>>> >>>> It has been so long.? I think it's likely an oversight. >>>>> https://bugs.openjdk.java.net/browse/JDK-4530538 ? >>>>> >>>>> Does taking the Threads_lock here cost too much and cause a thread >>>>> termination bottleneck? >>>> >>>> If the contention on Threads_lock is not high (that seems to me), >>>> it should be okay. ? I'm not close to the VM implementation (lot of >>>> changes since then) and I don't have a definitive answer unless I >>>> study the code closely.?? You and others have a better judgement on >>>> this. >>>> >>>> AFAICT the change is okay. >>>> >>> >>> Thanks Mandy.? David, OK to push? >>> >>> dl >>> >>>> Mandy >>>> >>>> >>> > From gary.adams at oracle.com Tue Oct 23 18:07:32 2018 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 23 Oct 2018 14:07:32 -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: <5BCF6364.1010802@oracle.com> Could I get a second reviewer for this change. 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 jcbeyler at google.com Tue Oct 23 18:13:16 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 23 Oct 2018 11:13:16 -0700 Subject: RFR: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt In-Reply-To: <5BCF6364.1010802@oracle.com> References: <5BC4D1EA.8010008@oracle.com> <11799558-9036-b15c-f2a2-0430be1642ef@oracle.com> <5BCF6364.1010802@oracle.com> Message-ID: Hi Gary, Looks good to me (not an official reviewer though), Jc On Tue, Oct 23, 2018 at 11:08 AM Gary Adams wrote: > Could I get a second reviewer for this change. > > 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. > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Oct 23 18:15:33 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 23 Oct 2018 11:15:33 -0700 Subject: JDK-8211013: TESTBUG] nsk/jdb/kill/kill002 wait for message and prompt In-Reply-To: References: <5BC4D1EA.8010008@oracle.com> <11799558-9036-b15c-f2a2-0430be1642ef@oracle.com> Message-ID: Hi Gary, This change looks OK to me. Bets regards, Daniil ?On 10/23/18, 11:08 AM, "serviceability-dev on behalf of Gary Adams" wrote: Could I get a second reviewer for this change. 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 manc at google.com Tue Oct 23 21:37:20 2018 From: manc at google.com (Man Cao) Date: Tue, 23 Oct 2018 14:37:20 -0700 Subject: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: <56a2527c-e882-7868-1d3c-ff85aed15ea5@oracle.com> References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> <773340F4-C9A2-4904-A634-1CDE95253E88@amazon.com> <6C5B0F49-6829-4793-BF1A-AD310ABC1B2A@amazon.com> <56a2527c-e882-7868-1d3c-ff85aed15ea5@oracle.com> Message-ID: Hi Paul, I looked at the code in detail, and didn't find any major problem. A few small issues below. I'm not a Reviewer, though. ----------------------------File Separator---------------------------------- In http://cr.openjdk.java.net/~phh/8196989/webrev.04/src/hotspot/share/gc/g1/g1MonitoringSupport.hpp.udiff.html -// - young_gen_used = current young region capacity +// - young_gen_committed = current young region capacity // - survivor_used = survivor_capacity // - eden_used = young_gen_used - survivor_used "young_gen_used" is still referenced several times in comment, although there is no function or field in code to compute young_gen_used. Maybe the following is more accurate? // * Occupancy // // - young_gen_committed = current young region capacity // - survivor_used = survivor_capacity // - eden_used = sum of eden regions allocated // In legacy mode: // - old_used = overall_used - survivor_used - eden_used // Otherwise: // - humongous_used = sum of humongous regions allocated // - archive_used = sum of archive regions allocated // - old_used = overall_used - survivor_used - eden_used - // humongous_used - archive_used ----------------------------File Separator---------------------------------- In http://cr.openjdk.java.net/~phh/8196989/webrev.04/src/hotspot/share/gc/g1/g1CollectedHeap.cpp.udiff.html void G1CollectedHeap::post_initialize() { + // Necessary to satisfy locking discipline assertions. + MutexLockerEx x(Heap_lock); + CollectedHeap::post_initialize(); ref_processing_init(); } I couldn't immediately see which assertion requires the Heap_lock. Is the lock required by the call to G1MonitoringSupport::update_sizes() in G1MonitoringSupport::initialize_serviceability()? Other collectors (Parallel, CMS, etc.) do not seem to hold the Heap_lock for post_initialize() and initialize_serviceability(), either. Should this locking statement be put at a more general place, e.g. universe_post_init() in universe.cpp; or if it is G1-specific, at a place closer to where it is required in G1? ----------------------------File Separator---------------------------------- In http://cr.openjdk.java.net/~phh/8196989/webrev.04/src/hotspot/share/services/memoryManager.cpp.udiff.html void GCMemoryManager::gc_begin(bool recordGCBeginTime, bool recordPreGCUsage, bool recordAccumulatedGCTime) { - assert(_last_gc_stat != NULL && _current_gc_stat != NULL, "Just checking"); + // Inactive memory managers (concurrent in G1 legacy mode) will not be initialized. + if (_last_gc_stat == NULL && _current_gc_stat == NULL) return; + void GCMemoryManager::gc_end(bool recordPostGCUsage, bool recordAccumulatedGCTime, bool recordGCEndTime, bool countCollection, GCCause::Cause cause, bool allMemoryPoolsAffected) { + if (_last_gc_stat == NULL && _current_gc_stat == NULL) return; + Because they are only for handling the special case for g1mm()->conc_memory_manager(), it is probably better not to change memoryManager.cpp, but let TraceConcMemoryManagerStats handle them. I was considering if we can make the calls to gc_begin() and gc_end() conditional on G1UseLegacyMonitoring, but C++ does not allow complete overriding of the base class's destructor ~TraceMemoryManagerStats(), which calls GCMemoryManager::gc_end(). One option is to keep the code as-is, but I recommend adding assertions that the two branches can only be taken when G1UseLegacyMonitoring && this == g1mm()->conc_memory_manager(). The other option is to implement TraceConcMemoryManagerStats independent of TraceMemoryManagerStats, so it can have a destructor that conditionally calls GCMemoryManager::gc_end(). ----------------------------File Separator---------------------------------- In http://cr.openjdk.java.net/~phh/8196989/webrev.04/test/hotspot/jtreg/gc/g1/mixedgc/TestOldGenCollectionUsage.java.udiff.html - if (newCollectionCount <= collectionCount) { + if (useLegacyMonitoring) { + if (newCollectionCount <= youngCollectionCount) { throw new RuntimeException("No new collection"); } - if (newCollectionTime <= collectionTime) { - throw new RuntimeException("Collector has not run some more"); + } else { + if (newCollectionCount <= 0) { + throw new RuntimeException("Mixed collection count <= 0"); + } + if (newCollectionTime <= 0) { + throw new RuntimeException("Mixed collector did not run"); + } } It seems under the useLegacyMonitoring==true branch, the check for "newCollectionTime <= collectionTime" was removed. In addition, I think this test add a check that youngCollector and mixedCollector point to the same instance if useLegacyMonitoring==true. ----------------------------File Separator---------------------------------- In http://cr.openjdk.java.net/~phh/8196989/webrev.04/test/jdk/jdk/jfr/event/gc/stacktrace/AllocationStackTrace.java.udiff.html private static GarbageCollectorMXBean garbageCollectorMXBean(String name) throws Exception { MBeanServer server = ManagementFactory.getPlatformMBeanServer(); - GarbageCollectorMXBean bean = ManagementFactory.newPlatformMXBeanProxy( - server, "java.lang:type=GarbageCollector,name=" + name, GarbageCollectorMXBean.class); + GarbageCollectorMXBean bean; + try { + bean = ManagementFactory.newPlatformMXBeanProxy(server, + "java.lang:type=GarbageCollector,name=" + name, + GarbageCollectorMXBean.class); + } catch (IllegalArgumentException e) { + bean = null; + } + return bean; + } + + private static GarbageCollectorMXBean g1YoungGarbageCollectorMXBean() throws Exception { + GarbageCollectorMXBean bean = garbageCollectorMXBean("G1 Young Generation"); + if (bean == null) { + bean = garbageCollectorMXBean("G1 Young"); + } + return bean; + } + + private static GarbageCollectorMXBean g1FullGarbageCollectorMXBean() throws Exception { + GarbageCollectorMXBean bean = garbageCollectorMXBean("G1 Old Generation"); + if (bean == null) { + bean = garbageCollectorMXBean("G1 Full"); + } return bean; } It is probably better to add the LegacyMonitoring checker class to this file and use LegacyMonitoring.use() to determine the appropriate name of the MXBeans. Catching IllegalArgumentException and retrying with a different name is like using exception for control flow. Thanks, Man On Sun, Oct 21, 2018 at 3:08 PM David Holmes wrote: > > Hi Paul, > > On 20/10/2018 2:05 AM, Hohensee, Paul wrote: > > If we put the flag into deprecation, I?d like to keep it for a year so > > people have time to change their monitoring code (one release to change > > their code, and another to run with their new code), which would be two > > releases. I don?t know how the deprecation process works either. Note > > that if/when this gets backported to jdk8u and/or jdk11u, there?s no > > mechanism there to obsolete a flag. > > First the new flag has to be added to the CSR to get approval to be > added. It would be quite strange to add a new flag and deprecate it at > the same time - not completely out of the question given its legacy > compatibility nature, but still odd. So I'd suggest not initially > deprecating it but rather file a new bug and CSR to deprecate in 13, > obsolete in 14 and expire in 15. That gives you 12 and 13 where the flag > is active - though you'll only get a deprecation warning in 13. The > obsoletion in 14 will require new bug, but not CSR. The expiration is > normally handled en-masse when we bump the JDK release version. > > For 8u the deprecation process is more manual. You need to add an > explicit check and warning in arguments.cpp, then when you're ready to > obsolete it add it to the obsolete flag table and remove the deprecation > warning. > > Cheers, > David > ----- > > > > Discovered an issue with the > > jdk/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java > > test, new new webrev at > > > > http://cr.openjdk.java.net/~phh/8196989/webrev.04/ > > > > > > Paul > > > > *From: *JC Beyler > > *Date: *Thursday, October 18, 2018 at 10:47 PM > > *To: *"Hohensee, Paul" > > *Cc: *"hotspot-gc-dev at openjdk.java.net" > > , "serviceability-dev at openjdk.java.net" > > > > *Subject: *Re: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector > > MXBean definitions > > > > Hi Paul, > > > > Looks much better to me. The other question I have is about the legacy > > mode. I understand why, from a tool's perspective, having a legacy mode > > is practical. By doing it this way, we are ensuring we don't break any > > tools (or at least they can use a flag to be "unbroken") and give time > > to migrate. This also provides an easier means to backport this fix to > > older JDKs because now the legacy mode can be used to not break anything > > and yet provide a means to migrate to a more sane vision of G1 collector > > definitions. > > > > Should the flag perhaps be automatically put in deprecation and then we > > can mark it as obsolete for JDK13? That would give a limited time for a > > flag but again I'm not sure this is really done? > > > > Or is the plan to keep the flag for a given number of versions, try out > > these new pools and ensure they provide what we need? > > > > Thanks! > > > > Jc > > > > On Thu, Oct 18, 2018 at 3:18 PM Hohensee, Paul > > wrote: > > > > Thanks for your review, JC. New webrev: > > http://cr.openjdk.java.net/~phh/8196989/webrev.03/ > > > > > > I updated the copyright date in memoryService.hpp because I forgot > > to do so in the patch for > > https://bugs.openjdk.java.net/browse/JDK-8195115. Thomas asked me to > > fix in it a separate CR, so I?ve reverted it. Ditto the #include > > fixes in g1FullGCOopClosures.inline.hpp and g1HeapVerifier.cpp. At > > one point during development, clang complained about the latter, but > > no longer does. > > > > The ?break? on the same line as the ?}? was in the original version, > > but I?ve moved it. :) > > > > The comment is indeed a bit opaque. I changed it to: > > > > // Only check heap pools that support a usage threshold. > > > > // This is typically only the old generation space > > > > // since the other spaces are expected to get filled up. > > > > if (p.getType() == MemoryType.HEAP && > > > > p.isUsageThresholdSupported()) { > > > > // In all collectors except G1, only the old > > generation supports a > > > > // usage threshold. The G1 legacy mode "G1 Old Gen" > > also does. In > > > > // G1 default mode, both the old space ("G1 Old > > Space": it's not > > > > // really a generation in the non-G1 collector > > sense) and the > > > > // humongous space ("G1 Humongous Space"), support > > a usage threshold. > > > > // So, the following condition is true for all > > non-G1 old generations, > > > > // for the G1 legacy old gen, and for the G1 > > default humongous space. > > > > // It is not true for the G1 default old gen. > > > > // > > > > // We're allocating humongous objects in this test, > > so the G1 default > > > > // mode "G1 Old Space" occupancy doesn't change, > > because humongous > > > > // objects are allocated in the "G1 Humongous > > Space". If we allowed > > > > // the G1 default mode "G1 Old Space", notification > > would never > > > > // happen because no objects are allocated there. > > > > if (!p.getName().equals("G1 Old Space")) { > > > > Finally, the G1MonitoringScope constructor now does a better job of > > selecting a memory manager. > > > > Paul > > > > *From: *JC Beyler > > > *Date: *Wednesday, October 17, 2018 at 4:47 PM > > *To: *"Hohensee, Paul" > > > > *Cc: *"hotspot-gc-dev at openjdk.java.net > > " > > > >, > > "serviceability-dev at openjdk.java.net > > " > > > > > > *Subject: *Re: 8196989: Revamp G1 JMX MemoryPool and > > GarbageCollector MXBean definitions > > > > 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 3^rd 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 > > > > > > -- > > > > Thanks, > > > > Jc > > From david.holmes at oracle.com Tue Oct 23 21:51:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Oct 2018 07:51:34 +1000 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <5b6265b6-36b3-4317-1e6a-8ba51c8a48b3@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> <5b6265b6-36b3-4317-1e6a-8ba51c8a48b3@oracle.com> Message-ID: <0560343b-94b4-2261-0f1d-a08d7067e97b@oracle.com> Hi Dean, On 24/10/2018 4:05 AM, dean.long at oracle.com wrote: > On 10/23/18 9:46 AM, dean.long at oracle.com wrote: >> On 10/22/18 3:31 PM, David Holmes wrote: >>> Sorry Dean I'm concerned about a thread termination bottleneck with >>> this. A simple microbenchmark that creates 500,000 threads that have >>> to run and terminate, shows a 15+% slowdown on my Linux box. I tried >>> to find some kind of real benchmarks that covers thread termination >>> but couldn't see anything specific. >>> >>> Can you at least run this through our performance system to see if >>> any of the regular benchmarks are affected. >>> >> >> OK, but even if the regular benchmarks don't show a difference, I'd >> feel better if microbenchmarks were not affected.? What if I go back >> to the original approach and add locking: >> >> ?? static jlong get_live_thread_count()??????? { MutexLocker >> mu(Threads_lock); return _live_threads_count->get_value() - >> _exiting_threads_count; } >> ?? static jlong get_daemon_thread_count()????? { MutexLocker >> mu(Threads_lock); return _daemon_threads_count->get_value() - >> _exiting_daemon_threads_count; } >> >> along with the other cleanups around is_daemon and is_hidden_thread? >> > > Some micro-benchmarks like SecureRandomBench show a regression with > webrev.7.? I could go back to webrev.5 and then we shouldn't need any > locking in the get_*() functions. I don't see version 5 discussed but I took a look and it seems okay. My only query with that version is that it appears the actual perfCounters no longer get read by anything - is that the case? Thanks, David > dl > >> dl >> >>> Thanks, >>> David >>> >>> On 20/10/2018 1:28 PM, dean.long at oracle.com wrote: >>>> On 10/18/18 6:12 PM, Mandy Chung wrote: >>>>> >>>>> >>>>> On 10/18/18 12:27 AM, David Holmes wrote: >>>>>> Hi Dean, >>>>>> >>>>>> On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: >>>>>>> >>>>>>> You're right, I missed that.? I think the right thing to do is >>>>>>> call current_thread_exiting while holding the Threads_lock. >>>>>>> Then we can get rid of the parallel atomic counters. So, here's >>>>>>> one more try: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ >>>>>> >>>>>> Okay that is the simple and obvious solution that doesn't require >>>>>> split counts. So I have to ask Mandy if she recalls why this >>>>>> approach wasn't taken 15 years ago when the exit counts were added >>>>>> as part of: >>>>>> >>>>> >>>>> It has been so long.? I think it's likely an oversight. >>>>>> https://bugs.openjdk.java.net/browse/JDK-4530538 ? >>>>>> >>>>>> Does taking the Threads_lock here cost too much and cause a thread >>>>>> termination bottleneck? >>>>> >>>>> If the contention on Threads_lock is not high (that seems to me), >>>>> it should be okay. ? I'm not close to the VM implementation (lot of >>>>> changes since then) and I don't have a definitive answer unless I >>>>> study the code closely.?? You and others have a better judgement on >>>>> this. >>>>> >>>>> AFAICT the change is okay. >>>>> >>>> >>>> Thanks Mandy.? David, OK to push? >>>> >>>> dl >>>> >>>>> Mandy >>>>> >>>>> >>>> >> > From dean.long at oracle.com Tue Oct 23 22:30:35 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 23 Oct 2018 15:30:35 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <0560343b-94b4-2261-0f1d-a08d7067e97b@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> <5b6265b6-36b3-4317-1e6a-8ba51c8a48b3@oracle.com> <0560343b-94b4-2261-0f1d-a08d7067e97b@oracle.com> Message-ID: <43be9a19-d0c5-298a-9bcb-e98223f4566a@oracle.com> On 10/23/18 2:51 PM, David Holmes wrote: > Hi Dean, > > On 24/10/2018 4:05 AM, dean.long at oracle.com wrote: >> On 10/23/18 9:46 AM, dean.long at oracle.com wrote: >>> On 10/22/18 3:31 PM, David Holmes wrote: >>>> Sorry Dean I'm concerned about a thread termination bottleneck with >>>> this. A simple microbenchmark that creates 500,000 threads that >>>> have to run and terminate, shows a 15+% slowdown on my Linux box. I >>>> tried to find some kind of real benchmarks that covers thread >>>> termination but couldn't see anything specific. >>>> >>>> Can you at least run this through our performance system to see if >>>> any of the regular benchmarks are affected. >>>> >>> >>> OK, but even if the regular benchmarks don't show a difference, I'd >>> feel better if microbenchmarks were not affected.? What if I go back >>> to the original approach and add locking: >>> >>> ?? static jlong get_live_thread_count()??????? { MutexLocker >>> mu(Threads_lock); return _live_threads_count->get_value() - >>> _exiting_threads_count; } >>> ?? static jlong get_daemon_thread_count()????? { MutexLocker >>> mu(Threads_lock); return _daemon_threads_count->get_value() - >>> _exiting_daemon_threads_count; } >>> >>> along with the other cleanups around is_daemon and is_hidden_thread? >>> >> >> Some micro-benchmarks like SecureRandomBench show a regression with >> webrev.7.? I could go back to webrev.5 and then we shouldn't need any >> locking in the get_*() functions. > > I don't see version 5 discussed but I took a look and it seems okay. Mandy had questions about the asserts in .5, and it seemed like we could just set the perf counters to the same value as the atomic counters, which resulted in .6.? I think the only problem with .6 is that I set the perf counters in decrement_thread_counts without the lock.? If I "sync" the perf counters to the atomic counters only in add_thread and remove_thread, with the lock, then it's about the same as .5, but without the asserts and parallel inc/dec.? If anyone likes the sound of that, I can send out a new webrev.? Or we can go with webrev.5. > My only query with that version is that it appears the actual > perfCounters no longer get read by anything - is that the case? > There does seem to be code that references them, through their name string.? That's a difference interface that I'm not familiar with, so I didn't want to break it. dl > Thanks, > David > >> dl >> >>> dl >>> >>>> Thanks, >>>> David >>>> >>>> On 20/10/2018 1:28 PM, dean.long at oracle.com wrote: >>>>> On 10/18/18 6:12 PM, Mandy Chung wrote: >>>>>> >>>>>> >>>>>> On 10/18/18 12:27 AM, David Holmes wrote: >>>>>>> Hi Dean, >>>>>>> >>>>>>> On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: >>>>>>>> >>>>>>>> You're right, I missed that.? I think the right thing to do is >>>>>>>> call current_thread_exiting while holding the Threads_lock. >>>>>>>> Then we can get rid of the parallel atomic counters. So, here's >>>>>>>> one more try: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ >>>>>>> >>>>>>> Okay that is the simple and obvious solution that doesn't >>>>>>> require split counts. So I have to ask Mandy if she recalls why >>>>>>> this approach wasn't taken 15 years ago when the exit counts >>>>>>> were added as part of: >>>>>>> >>>>>> >>>>>> It has been so long.? I think it's likely an oversight. >>>>>>> https://bugs.openjdk.java.net/browse/JDK-4530538 ? >>>>>>> >>>>>>> Does taking the Threads_lock here cost too much and cause a >>>>>>> thread termination bottleneck? >>>>>> >>>>>> If the contention on Threads_lock is not high (that seems to me), >>>>>> it should be okay. ? I'm not close to the VM implementation (lot >>>>>> of changes since then) and I don't have a definitive answer >>>>>> unless I study the code closely.?? You and others have a better >>>>>> judgement on this. >>>>>> >>>>>> AFAICT the change is okay. >>>>>> >>>>> >>>>> Thanks Mandy.? David, OK to push? >>>>> >>>>> dl >>>>> >>>>>> Mandy >>>>>> >>>>>> >>>>> >>> >> From serguei.spitsyn at oracle.com Tue Oct 23 23:15:43 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Oct 2018 16:15:43 -0700 Subject: The failure In-Reply-To: <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> Message-ID: <26bba1b2-d7c2-a62b-e2c8-9fa3e70773d5@oracle.com> Hi David and Robbin, On 10/23/18 7:38 AM, Robbin Ehn wrote: > Hi, > > On 10/23/18 10:34 AM, David Holmes wrote: >> Hi Serguei, >> >> The VMThread is executing VM_HandshakeAllThreads which is not a >> safepoint operation. There's no real way to tell from the stacks what >> it's stuck on. Good point. We agreed with Leonid that he will try to reproduce this deadlock with fewer kitchensink modules and modes. It would really help if there are less threads to analyze. > I cannot find a thread that is not considered safepoint safe or > is_ext_suspended (thread 146). So the handshake should go through. The > handshake will log a warning after a while, is there such warning from > the handshake operation? There is Thread #136 that executes JvmtiSuspendControl::suspend(). Not sure if it helps. > > There are several threads competing with e.g. Threads_lock, and > threads waiting for GC and several other VM ops, could it just be > really slow? No idea yet. Thanks, Serguei > /Robbin > >> >> David >> >> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> You are right, thanks. >>> It means, this deadlock needs more analysis. >>> For completeness, the stack traces are in attachments. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/23/18 00:43, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>> _thread_blocked and so safepoint-safe and so won't be holding up >>>> the safepoint. >>>> >>>> David >>>> >>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi, >>>>> >>>>> I've added the seviceability-dev mailing list. >>>>> It can be interesting for the SVC folks. :) >>>>> >>>>> >>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>> Hi >>>>>> >>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Also it might hangs with ?stack attached. ?Seems that test might >>>>>> be blocked because it invoke 2 jvmti methods. Can jvmti agent >>>>>> invoke jvmti methods from different threads? >>>>> >>>>> Yes, in general. >>>>> However, you have to be careful when using debugging features. >>>>> Below, one thread is enabling single stepping while another thread >>>>> is being suspended. >>>>> Both are blocked at a safepoint which is Okay in general but not >>>>> Okay if they hold any lock. >>>>> For instance, the thread #152 is holding the monitor >>>>> JvmtiThreadState. >>>>> >>>>> Also, I see a couple of more threads that are interesting as well: >>>>> >>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>> (this=this at entry=0x2ae3984c9100) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>> #4? 0x00002ae393b512c1 in lock >>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>> this=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>> >>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>> >>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>> (task=task at entry=0x2ae48800ff40) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>> >>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>> >>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>> (this=this at entry=0x2ae3984c7800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>> (thread=0x2ae3984c7800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>> >>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>> (this=this at entry=0x2ae3984cbb00) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>> this=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>> this=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>> >>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>> >>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>> (task=task at entry=0x2ae49c00a670) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>> >>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>> >>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>> (this=this at entry=0x2ae3984ca800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>> (thread=0x2ae3984ca800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>> >>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>> /lib64/libpthread.so.0 >>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>> (this=this at entry=0x2ae460061c00) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>> this=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>> this=) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>> >>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>> >>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) >>>>> at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>> >>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>> >>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>> (thread=0x2ae4600c2800) at >>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>> >>>>> >>>>> These two thread are blocked on the monitor JvmtiThreadState_lock >>>>> in the function ciEnv::cache_jvmti_state(). >>>>> Also, there are many threads (like #51) that are executing >>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>> >>>>> >>>>> Now, the question is why this safepoint can not start? >>>>> What thread is blocking it? Or in reverse, what thread this >>>>> safepoint is waiting for? >>>>> >>>>> I think, this safepoint operation is waiting for all threads that >>>>> are blocked on the JvmtiThreadState_lock. >>>>> >>>>> Conclusion: >>>>> >>>>> The deadlock is: >>>>> >>>>> Thread #152: >>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>> JvmtiEnvThreadState::reset_current_location() >>>>> >>>>> Many other threads: >>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>> have to reach this state for this safepoint to happen) >>>>> >>>>> It seems to me, this is a bug which has to be filed. >>>>> >>>>> My guess is that this will stop to reproduce after if you turn off >>>>> the single stepping for thread #152. >>>>> Please, let me know about the results. >>>>> >>>>> >>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>> integrate jvmti changes but *don't* enabled jvmti module by default. >>>>> >>>>> This one is a deadlock. >>>>> However, the root cause is a race condition that can potentially >>>>> result in both deadlocks and crashes. >>>>> So, I'm curious if you observed crashes as well. >>>>> >>>>> >>>>>> And add to more tests with jvmti enabled. >>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>> >>>>>> Consider hang - I think that it might be product bug since I >>>>>> don't see any locking on my monitors. But I am not sure. Is it >>>>>> possible that any my code jvmti agent prevent VM to get into >>>>>> safepoint? >>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>> >>>>> Yes, of course. >>>>> Let's find some time tomorrow. >>>>> >>>>> >>>>>> Any suggestion how to diagnose deadlock would be great. >>>>> >>>>> Analysis of stack traces is needed. >>>>> It is non-trivial in this particular case as there are so many >>>>> threads executed at the same time. >>>>> >>>>> >>>>>> Part of stack trace with 2 my threads only: >>>>>> >>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>> /lib64/libpthread.so.0 >>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>> (this=this at entry=0x2ae454005800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>> 8 >>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>> out>, timeout=timeout at entry=0, >>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>> try=false) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>> 47 >>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>> nv.cpp:955 >>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>> >>>>>> /jvmtiEnter.cpp:527 >>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>> env=, p=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>> (this=0x2ae454004800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>> (this=this at entry=0x2ae454004800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>> (thread=0x2ae454004800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>> /lib64/libpthread.so.0 >>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>> >>>>>> >>>>>> >>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>> /lib64/libpthread.so.0 >>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>> 8 >>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>> out>, timeout=timeout at entry=0, >>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>> try=false) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>> #6 ?0x00002ae3939965f3 in >>>>>> JvmtiEnvThreadState::reset_current_location >>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>> enabled=enabled at entry=tr\ >>>>>> ue) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>> >>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>> >>>>>> r.cpp:490 >>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>> >>>>>> :523 >>>>>> #9 ?0x00002ae393998168 in >>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>> >>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>> env=0x2ae39801b270) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, >>>>>> enabled=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>> nt_thread=event_thread at entry=0x0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>> event_thread=event_\ >>>>>> thread at entry=0x0) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>> >>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>> >>>>>> #15 0x00002ae394d98070 in >>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>> (env=, this=) at >>>>>> /scratch/lmesnik/ws/h\ >>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>> >>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>> #18 0x00002ae42705f878 in ?? () >>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>> #22 0x0000000000000000 in ?? () >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> >>>>>> >>>>>> Leonid >>>>>> >>>>>> >>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>> wrote: >>>>>>> >>>>>>> Hi Leonid, >>>>>>> >>>>>>> There is an existing bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> During fixing kitchensink I get >>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>> cur_stack_depth out of sync >>>>>>>> >>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>>>> >>>>>>>> # >>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>> # >>>>>>>> # ?Internal Error >>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>> pid=13926, tid=13962 >>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>> cur_stack_depth out of sync >>>>>>>> # >>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>> (fastdebug build >>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed >>>>>>>> mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>> # Core dump will be written. Default location: Core dumps may >>>>>>>> be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g >>>>>>>> %t e %P %I %h" (or dumping to >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>> >>>>>>>> # >>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>> # >>>>>>>> >>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>> >>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>> -XX:+CrashOnOutOfMemoryError >>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>> -XX:+FlightRecorder >>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>> >>>>>>>> >>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, >>>>>>>> Oracle Linux Server release 7.3 >>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d >>>>>>>> 0h 0m 31s) >>>>>>>> >>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>> >>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>> >>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>> __va_list_tag*)+0x2f >>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>>>>> const*, char const*, ...)+0x100 >>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>> .constprop.51]+0x18e >>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>> >>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>> >>>>>>> >>>>>> >>>>> >>> From serguei.spitsyn at oracle.com Tue Oct 23 23:18:02 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Oct 2018 16:18:02 -0700 Subject: The failure In-Reply-To: <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> Message-ID: Please, skip it - sorry for the noise. It is hard to prove anything with current dump. Thanks, Serguei On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: > Hi David and Robbin, > > I have an idea that needs to be checked. > It can be almost the same deadlock scenario that I've already > explained but more sophisticated. > I suspect a scenario with JvmtiThreadState_lock that the flag > Monitor::_safepoint_check_always does not help much. > It can be verified by checking what monitors are used by the blocked > threads. > > Thanks, > Serguei > > > On 10/23/18 07:38, Robbin Ehn wrote: >> Hi, >> >> On 10/23/18 10:34 AM, David Holmes wrote: >>> Hi Serguei, >>> >>> The VMThread is executing VM_HandshakeAllThreads which is not a >>> safepoint operation. There's no real way to tell from the stacks >>> what it's stuck on. >> >> I cannot find a thread that is not considered safepoint safe or >> is_ext_suspended (thread 146). So the handshake should go through. >> The handshake will log a warning after a while, is there such warning >> from the handshake operation? >> >> There are several threads competing with e.g. Threads_lock, and >> threads waiting for GC and several other VM ops, could it just be >> really slow? >> >> /Robbin >> >>> >>> David >>> >>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> You are right, thanks. >>>> It means, this deadlock needs more analysis. >>>> For completeness, the stack traces are in attachments. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/23/18 00:43, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>>> _thread_blocked and so safepoint-safe and so won't be holding up >>>>> the safepoint. >>>>> >>>>> David >>>>> >>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi, >>>>>> >>>>>> I've added the seviceability-dev mailing list. >>>>>> It can be interesting for the SVC folks. :) >>>>>> >>>>>> >>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>> Hi >>>>>>> >>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also it might hangs with ?stack attached. ?Seems that test might >>>>>>> be blocked because it invoke 2 jvmti methods. Can jvmti agent >>>>>>> invoke jvmti methods from different threads? >>>>>> >>>>>> Yes, in general. >>>>>> However, you have to be careful when using debugging features. >>>>>> Below, one thread is enabling single stepping while another >>>>>> thread is being suspended. >>>>>> Both are blocked at a safepoint which is Okay in general but not >>>>>> Okay if they hold any lock. >>>>>> For instance, the thread #152 is holding the monitor >>>>>> JvmtiThreadState. >>>>>> >>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>> >>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>> /lib64/libpthread.so.0 >>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>> #4? 0x00002ae393b512c1 in lock >>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>> this=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>> >>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>> >>>>>> #8? 0x00002ae3935d3294 in >>>>>> CompileBroker::invoke_compiler_on_method >>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>> >>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>> >>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>> (thread=0x2ae3984c7800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>> /lib64/libpthread.so.0 >>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>> >>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>> /lib64/libpthread.so.0 >>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>> this=0x2ae398024f10) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>> this=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>> >>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>> >>>>>> #8? 0x00002ae3935d3294 in >>>>>> CompileBroker::invoke_compiler_on_method >>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>> >>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>> >>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>> (thread=0x2ae3984ca800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>> /lib64/libpthread.so.0 >>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>> >>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>> /lib64/libpthread.so.0 >>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>> (this=this at entry=0x2ae460061c00) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>> this=0x2ae398024f10) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>> this=) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>> >>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>> >>>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>> >>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>> >>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) >>>>>> at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>> (thread=0x2ae4600c2800) at >>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>> #12 0x00002ae3927b1e25 in start_thread () from >>>>>> /lib64/libpthread.so.0 >>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>> >>>>>> >>>>>> These two thread are blocked on the monitor JvmtiThreadState_lock >>>>>> in the function ciEnv::cache_jvmti_state(). >>>>>> Also, there are many threads (like #51) that are executing >>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>> >>>>>> >>>>>> Now, the question is why this safepoint can not start? >>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>> safepoint is waiting for? >>>>>> >>>>>> I think, this safepoint operation is waiting for all threads that >>>>>> are blocked on the JvmtiThreadState_lock. >>>>>> >>>>>> Conclusion: >>>>>> >>>>>> The deadlock is: >>>>>> >>>>>> Thread #152: >>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>> >>>>>> Many other threads: >>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>>> have to reach this state for this safepoint to happen) >>>>>> >>>>>> It seems to me, this is a bug which has to be filed. >>>>>> >>>>>> My guess is that this will stop to reproduce after if you turn >>>>>> off the single stepping for thread #152. >>>>>> Please, let me know about the results. >>>>>> >>>>>> >>>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>>> integrate jvmti changes but *don't* enabled jvmti module by >>>>>>> default. >>>>>> >>>>>> This one is a deadlock. >>>>>> However, the root cause is a race condition that can potentially >>>>>> result in both deadlocks and crashes. >>>>>> So, I'm curious if you observed crashes as well. >>>>>> >>>>>> >>>>>>> And add to more tests with jvmti enabled. >>>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>>> >>>>>>> Consider hang - I think that it might be product bug since I >>>>>>> don't see any locking on my monitors. But I am not sure. Is it >>>>>>> possible that any my code jvmti agent prevent VM to get into >>>>>>> safepoint? >>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>> >>>>>> Yes, of course. >>>>>> Let's find some time tomorrow. >>>>>> >>>>>> >>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>> >>>>>> Analysis of stack traces is needed. >>>>>> It is non-trivial in this particular case as there are so many >>>>>> threads executed at the same time. >>>>>> >>>>>> >>>>>>> Part of stack trace with 2 my threads only: >>>>>>> >>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>> >>>>>>> 8 >>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>> out>, timeout=timeout at entry=0, >>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>> try=false) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>> 47 >>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>> nv.cpp:955 >>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>> >>>>>>> /jvmtiEnter.cpp:527 >>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>>> env=, p=) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>> (this=0x2ae454004800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>> (thread=0x2ae454004800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>> >>>>>>> 8 >>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>> out>, timeout=timeout at entry=0, >>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>> try=false) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>> enabled=enabled at entry=tr\ >>>>>>> ue) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>> >>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>> >>>>>>> r.cpp:490 >>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>> >>>>>>> :523 >>>>>>> #9 ?0x00002ae393998168 in >>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>> >>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>> env=0x2ae39801b270) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, >>>>>>> enabled=) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>> event_thread=event_\ >>>>>>> thread at entry=0x0) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>> >>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>> >>>>>>> #15 0x00002ae394d98070 in >>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>> (env=, this=) at >>>>>>> /scratch/lmesnik/ws/h\ >>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>> >>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>> #22 0x0000000000000000 in ?? () >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Leonid >>>>>>> >>>>>>> >>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Leonid, >>>>>>>> >>>>>>>> There is an existing bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> During fixing kitchensink I get >>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>> cur_stack_depth out of sync >>>>>>>>> >>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>> >>>>>>>>> Leonid >>>>>>>>> >>>>>>>>> >>>>>>>>> # >>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>> Environment: >>>>>>>>> # >>>>>>>>> # ?Internal Error >>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>> pid=13926, tid=13962 >>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>> cur_stack_depth out of sync >>>>>>>>> # >>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>>> (fastdebug build >>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed >>>>>>>>> mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>> # Core dump will be written. Default location: Core dumps may >>>>>>>>> be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g >>>>>>>>> %t e %P %I %h" (or dumping to >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>> >>>>>>>>> # >>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>> # >>>>>>>>> >>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>> >>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>>> -XX:+CrashOnOutOfMemoryError >>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>> -XX:+FlightRecorder >>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>> >>>>>>>>> >>>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, >>>>>>>>> Oracle Linux Server release 7.3 >>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds >>>>>>>>> (0d 0h 0m 31s) >>>>>>>>> >>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>> >>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>> >>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java >>>>>>>>> code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>>> __va_list_tag*)+0x2f >>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, >>>>>>>>> char const*, char const*, ...)+0x100 >>>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>> .constprop.51]+0x18e >>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>> >>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> > From david.holmes at oracle.com Tue Oct 23 23:56:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Oct 2018 09:56:30 +1000 Subject: The failure In-Reply-To: References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> Message-ID: Hi Serguei, Robbin, One thing I noticed which Robbin should be able to expand upon is that Thread 101 is terminating and has called ThreadsSMRSupport::smr_delete and is blocked here: // Wait for a release_stable_list() call before we check again. No // safepoint check, no timeout, and not as suspend equivalent flag // because this JavaThread is not on the Threads list. ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, 0, !Mutex::_as_suspend_equivalent_flag); As the comment says this thread is no longer on the Threads_list, but the VM_HandshakeAllThreads is not a safepoint operation and does not hold the Threads_lock, so is it possible this thread was captured by the JavaThreadIteratorWithHandle being used by VM_HandshakeAllThreads, before it got removed? If so we'd be hung waiting it for it handshake as it's not in a "safepoint-safe" or suspend-equivalent state. David ----- On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: > Please, skip it - sorry for the noise. > It is hard to prove anything with current dump. > > Thanks, > Serguei > > On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >> Hi David and Robbin, >> >> I have an idea that needs to be checked. >> It can be almost the same deadlock scenario that I've already >> explained but more sophisticated. >> I suspect a scenario with JvmtiThreadState_lock that the flag >> Monitor::_safepoint_check_always does not help much. >> It can be verified by checking what monitors are used by the blocked >> threads. >> >> Thanks, >> Serguei >> >> >> On 10/23/18 07:38, Robbin Ehn wrote: >>> Hi, >>> >>> On 10/23/18 10:34 AM, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>> safepoint operation. There's no real way to tell from the stacks >>>> what it's stuck on. >>> >>> I cannot find a thread that is not considered safepoint safe or >>> is_ext_suspended (thread 146). So the handshake should go through. >>> The handshake will log a warning after a while, is there such warning >>> from the handshake operation? >>> >>> There are several threads competing with e.g. Threads_lock, and >>> threads waiting for GC and several other VM ops, could it just be >>> really slow? >>> >>> /Robbin >>> >>>> >>>> David >>>> >>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi David, >>>>> >>>>> You are right, thanks. >>>>> It means, this deadlock needs more analysis. >>>>> For completeness, the stack traces are in attachments. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>>>> _thread_blocked and so safepoint-safe and so won't be holding up >>>>>> the safepoint. >>>>>> >>>>>> David >>>>>> >>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've added the seviceability-dev mailing list. >>>>>>> It can be interesting for the SVC folks. :) >>>>>>> >>>>>>> >>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Also it might hangs with ?stack attached. ?Seems that test might >>>>>>>> be blocked because it invoke 2 jvmti methods. Can jvmti agent >>>>>>>> invoke jvmti methods from different threads? >>>>>>> >>>>>>> Yes, in general. >>>>>>> However, you have to be careful when using debugging features. >>>>>>> Below, one thread is enabling single stepping while another >>>>>>> thread is being suspended. >>>>>>> Both are blocked at a safepoint which is Okay in general but not >>>>>>> Okay if they hold any lock. >>>>>>> For instance, the thread #152 is holding the monitor >>>>>>> JvmtiThreadState. >>>>>>> >>>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>>> >>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>> >>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>> >>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>> >>>>>>> #4? 0x00002ae393b512c1 in lock >>>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>> >>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>> >>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>> this=) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>> >>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>> >>>>>>> #8? 0x00002ae3935d3294 in >>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>> >>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>> >>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>> >>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>> >>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>> (thread=0x2ae3984c7800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>> >>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>> >>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>> >>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>> >>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>> >>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>> this=0x2ae398024f10) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>> >>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>> >>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>> this=) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>> >>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>> >>>>>>> #8? 0x00002ae3935d3294 in >>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>> >>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>> >>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>> >>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>> >>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>> (thread=0x2ae3984ca800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>> >>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>> >>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>> >>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>> >>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>> >>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>> this=0x2ae398024f10) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>> >>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>> >>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>> this=) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>> >>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>> >>>>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>> >>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>> >>>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) >>>>>>> at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>> >>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>> (thread=0x2ae4600c2800) at >>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>> >>>>>>> #12 0x00002ae3927b1e25 in start_thread () from >>>>>>> /lib64/libpthread.so.0 >>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>> >>>>>>> >>>>>>> These two thread are blocked on the monitor JvmtiThreadState_lock >>>>>>> in the function ciEnv::cache_jvmti_state(). >>>>>>> Also, there are many threads (like #51) that are executing >>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>> >>>>>>> >>>>>>> Now, the question is why this safepoint can not start? >>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>> safepoint is waiting for? >>>>>>> >>>>>>> I think, this safepoint operation is waiting for all threads that >>>>>>> are blocked on the JvmtiThreadState_lock. >>>>>>> >>>>>>> Conclusion: >>>>>>> >>>>>>> The deadlock is: >>>>>>> >>>>>>> Thread #152: >>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>> >>>>>>> Many other threads: >>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>>>> have to reach this state for this safepoint to happen) >>>>>>> >>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>> >>>>>>> My guess is that this will stop to reproduce after if you turn >>>>>>> off the single stepping for thread #152. >>>>>>> Please, let me know about the results. >>>>>>> >>>>>>> >>>>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>>>> integrate jvmti changes but *don't* enabled jvmti module by >>>>>>>> default. >>>>>>> >>>>>>> This one is a deadlock. >>>>>>> However, the root cause is a race condition that can potentially >>>>>>> result in both deadlocks and crashes. >>>>>>> So, I'm curious if you observed crashes as well. >>>>>>> >>>>>>> >>>>>>>> And add to more tests with jvmti enabled. >>>>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>>>> >>>>>>>> Consider hang - I think that it might be product bug since I >>>>>>>> don't see any locking on my monitors. But I am not sure. Is it >>>>>>>> possible that any my code jvmti agent prevent VM to get into >>>>>>>> safepoint? >>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>> >>>>>>> Yes, of course. >>>>>>> Let's find some time tomorrow. >>>>>>> >>>>>>> >>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>> >>>>>>> Analysis of stack traces is needed. >>>>>>> It is non-trivial in this particular case as there are so many >>>>>>> threads executed at the same time. >>>>>>> >>>>>>> >>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>> >>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>> >>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>> >>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>> >>>>>>>> 8 >>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>> try=false) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>> >>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>> >>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>> >>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>> >>>>>>>> 47 >>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>> nv.cpp:955 >>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>> >>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>>>> env=, p=) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>> >>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>>> (this=0x2ae454004800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>> >>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>> >>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>> >>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>> >>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>> (thread=0x2ae454004800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>> >>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>> >>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>> >>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>> >>>>>>>> 8 >>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>> try=false) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>> >>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>> >>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>> enabled=enabled at entry=tr\ >>>>>>>> ue) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>> >>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>> >>>>>>>> r.cpp:490 >>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>> >>>>>>>> :523 >>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>> >>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>>> env=0x2ae39801b270) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, >>>>>>>> enabled=) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>> >>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>> event_thread=event_\ >>>>>>>> thread at entry=0x0) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>> >>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>> >>>>>>>> #15 0x00002ae394d98070 in >>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>> (env=, this=) at >>>>>>>> /scratch/lmesnik/ws/h\ >>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>> >>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Leonid >>>>>>>> >>>>>>>> >>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Leonid, >>>>>>>>> >>>>>>>>> There is an existing bug: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> During fixing kitchensink I get >>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>> >>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>> >>>>>>>>>> Leonid >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> # >>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>> Environment: >>>>>>>>>> # >>>>>>>>>> # ?Internal Error >>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>> # >>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>>>> (fastdebug build >>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed >>>>>>>>>> mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>> # Core dump will be written. Default location: Core dumps may >>>>>>>>>> be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g >>>>>>>>>> %t e %P %I %h" (or dumping to >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>> >>>>>>>>>> # >>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>> # >>>>>>>>>> >>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>> >>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>>>> -XX:+CrashOnOutOfMemoryError >>>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>> -XX:+FlightRecorder >>>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, >>>>>>>>>> Oracle Linux Server release 7.3 >>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds >>>>>>>>>> (0d 0h 0m 31s) >>>>>>>>>> >>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>> >>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>> >>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java >>>>>>>>>> code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>>>> __va_list_tag*)+0x2f >>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, >>>>>>>>>> char const*, char const*, ...)+0x100 >>>>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>> >>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >> > From david.holmes at oracle.com Tue Oct 23 23:58:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Oct 2018 09:58:19 +1000 Subject: The failure In-Reply-To: References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> Message-ID: <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> I should have looked further before sending this. Many threads are in smr_delete. David On 24/10/2018 9:56 AM, David Holmes wrote: > Hi Serguei, Robbin, > > One thing I noticed which Robbin should be able to expand upon is that > Thread 101 is terminating and has called ThreadsSMRSupport::smr_delete > and is blocked here: > > ?// Wait for a release_stable_list() call before we check again. No > ?// safepoint check, no timeout, and not as suspend equivalent flag > ?// because this JavaThread is not on the Threads list. > ?ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, > ??????????????????????????????????????? 0, > !Mutex::_as_suspend_equivalent_flag); > > As the comment says this thread is no longer on the Threads_list, but > the VM_HandshakeAllThreads is not a safepoint operation and does not > hold the Threads_lock, so is it possible this thread was captured by the > JavaThreadIteratorWithHandle being used by VM_HandshakeAllThreads, > before it got removed? If so we'd be hung waiting it for it handshake as > it's not in a "safepoint-safe" or suspend-equivalent state. > > David > ----- > > On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >> Please, skip it - sorry for the noise. >> It is hard to prove anything with current dump. >> >> Thanks, >> Serguei >> >> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>> Hi David and Robbin, >>> >>> I have an idea that needs to be checked. >>> It can be almost the same deadlock scenario that I've already >>> explained but more sophisticated. >>> I suspect a scenario with JvmtiThreadState_lock that the flag >>> Monitor::_safepoint_check_always does not help much. >>> It can be verified by checking what monitors are used by the blocked >>> threads. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/23/18 07:38, Robbin Ehn wrote: >>>> Hi, >>>> >>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>>> safepoint operation. There's no real way to tell from the stacks >>>>> what it's stuck on. >>>> >>>> I cannot find a thread that is not considered safepoint safe or >>>> is_ext_suspended (thread 146). So the handshake should go through. >>>> The handshake will log a warning after a while, is there such >>>> warning from the handshake operation? >>>> >>>> There are several threads competing with e.g. Threads_lock, and >>>> threads waiting for GC and several other VM ops, could it just be >>>> really slow? >>>> >>>> /Robbin >>>> >>>>> >>>>> David >>>>> >>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David, >>>>>> >>>>>> You are right, thanks. >>>>>> It means, this deadlock needs more analysis. >>>>>> For completeness, the stack traces are in attachments. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> The JvmtiThreadState_lock is always acquired with safepoint >>>>>>> checks enabled, so all JavaThreads blocked trying to acquire it >>>>>>> will be _thread_blocked and so safepoint-safe and so won't be >>>>>>> holding up the safepoint. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>> >>>>>>>> >>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test >>>>>>>>> might be blocked because it invoke 2 jvmti methods. Can jvmti >>>>>>>>> agent invoke jvmti methods from different threads? >>>>>>>> >>>>>>>> Yes, in general. >>>>>>>> However, you have to be careful when using debugging features. >>>>>>>> Below, one thread is enabling single stepping while another >>>>>>>> thread is being suspended. >>>>>>>> Both are blocked at a safepoint which is Okay in general but not >>>>>>>> Okay if they hold any lock. >>>>>>>> For instance, the thread #152 is holding the monitor >>>>>>>> JvmtiThreadState. >>>>>>>> >>>>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>>>> >>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>> >>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>> >>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>> >>>>>>>> #4? 0x00002ae393b512c1 in lock >>>>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>> >>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>> >>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>> this=) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>> >>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>> >>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>> >>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>> >>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>> >>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>> >>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>> >>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>> >>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>> >>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>> >>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>> >>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>> this=0x2ae398024f10) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>> >>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>> >>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>> this=) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>> >>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>> >>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>> >>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>> >>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>> >>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>> >>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>> >>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>> >>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>> >>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>> >>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>> >>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>> this=0x2ae398024f10) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>> >>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>> >>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>> this=) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>> >>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>> >>>>>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>> >>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>> >>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) >>>>>>>> at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>> >>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>> >>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from >>>>>>>> /lib64/libpthread.so.0 >>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>> >>>>>>>> >>>>>>>> These two thread are blocked on the monitor >>>>>>>> JvmtiThreadState_lock in the function ciEnv::cache_jvmti_state(). >>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>> >>>>>>>> >>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>> safepoint is waiting for? >>>>>>>> >>>>>>>> I think, this safepoint operation is waiting for all threads >>>>>>>> that are blocked on the JvmtiThreadState_lock. >>>>>>>> >>>>>>>> Conclusion: >>>>>>>> >>>>>>>> The deadlock is: >>>>>>>> >>>>>>>> Thread #152: >>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>> >>>>>>>> Many other threads: >>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>>>>> have to reach this state for this safepoint to happen) >>>>>>>> >>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>> >>>>>>>> My guess is that this will stop to reproduce after if you turn >>>>>>>> off the single stepping for thread #152. >>>>>>>> Please, let me know about the results. >>>>>>>> >>>>>>>> >>>>>>>>> Assuming that crashes look like VM bugs I think it make sense >>>>>>>>> to integrate jvmti changes but *don't* enabled jvmti module by >>>>>>>>> default. >>>>>>>> >>>>>>>> This one is a deadlock. >>>>>>>> However, the root cause is a race condition that can potentially >>>>>>>> result in both deadlocks and crashes. >>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>> >>>>>>>> >>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>> So anyone could easily run them to reproduce crashes. ?This >>>>>>>>> test would be out of CI to don't introduce any bugs. Does it >>>>>>>>> make sense? >>>>>>>>> >>>>>>>>> Consider hang - I think that it might be product bug since I >>>>>>>>> don't see any locking on my monitors. But I am not sure. Is it >>>>>>>>> possible that any my code jvmti agent prevent VM to get into >>>>>>>>> safepoint? >>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>> >>>>>>>> Yes, of course. >>>>>>>> Let's find some time tomorrow. >>>>>>>> >>>>>>>> >>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>> >>>>>>>> Analysis of stack traces is needed. >>>>>>>> It is non-trivial in this particular case as there are so many >>>>>>>> threads executed at the same time. >>>>>>>> >>>>>>>> >>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>> >>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>> >>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>> ev=0x2ae454005800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>> >>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>> >>>>>>>>> 8 >>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>> try=false) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>> >>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>> >>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>> >>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>> >>>>>>>>> 47 >>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>> >>>>>>>>> nv.cpp:955 >>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>> >>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>>>>> env=, p=) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>> >>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>>>> (this=0x2ae454004800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>> >>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>> >>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>> >>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) >>>>>>>>> at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>> >>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>> >>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>> >>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>> ev=0x2ae3985e7400) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>> >>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>> >>>>>>>>> 8 >>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>> try=false) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>> >>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) >>>>>>>>> at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>> >>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>> ue) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>> >>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>> >>>>>>>>> r.cpp:490 >>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>> >>>>>>>>> :523 >>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>> >>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>>>> env=0x2ae39801b270) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>> enabled=) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>> >>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>> event_thread=event_\ >>>>>>>>> thread at entry=0x0) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>> >>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>> >>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>> (env=, this=) at >>>>>>>>> /scratch/lmesnik/ws/h\ >>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>> >>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Leonid >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Leonid, >>>>>>>>>> >>>>>>>>>> There is an existing bug: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>> >>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>> >>>>>>>>>>> Leonid >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> # >>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>> Environment: >>>>>>>>>>> # >>>>>>>>>>> # ?Internal Error >>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>> # >>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>>>>> (fastdebug build >>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed >>>>>>>>>>> mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>> # Core dump will be written. Default location: Core dumps may >>>>>>>>>>> be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g >>>>>>>>>>> %t e %P %I %h" (or dumping to >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>> >>>>>>>>>>> # >>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>> # >>>>>>>>>>> >>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>> >>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>>>>> -XX:+CrashOnOutOfMemoryError >>>>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>> -XX:+FlightRecorder >>>>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, >>>>>>>>>>> Oracle Linux Server release 7.3 >>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds >>>>>>>>>>> (0d 0h 0m 31s) >>>>>>>>>>> >>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>> >>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>> >>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java >>>>>>>>>>> code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>>>>> __va_list_tag*)+0x2f >>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, >>>>>>>>>>> char const*, char const*, ...)+0x100 >>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>> >>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, >>>>>>>>>>> mode: safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>> >> From serguei.spitsyn at oracle.com Wed Oct 24 00:00:43 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Oct 2018 17:00:43 -0700 Subject: The failure In-Reply-To: <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> Message-ID: Okay, thanks! Serguei On 10/23/18 4:58 PM, David Holmes wrote: > I should have looked further before sending this. Many threads are in > smr_delete. > > David > > On 24/10/2018 9:56 AM, David Holmes wrote: >> Hi Serguei, Robbin, >> >> One thing I noticed which Robbin should be able to expand upon is >> that Thread 101 is terminating and has called >> ThreadsSMRSupport::smr_delete and is blocked here: >> >> ??// Wait for a release_stable_list() call before we check again. No >> ??// safepoint check, no timeout, and not as suspend equivalent flag >> ??// because this JavaThread is not on the Threads list. >> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >> >> ???????????????????????????????????????? 0, >> !Mutex::_as_suspend_equivalent_flag); >> >> As the comment says this thread is no longer on the Threads_list, but >> the VM_HandshakeAllThreads is not a safepoint operation and does not >> hold the Threads_lock, so is it possible this thread was captured by >> the JavaThreadIteratorWithHandle being used by >> VM_HandshakeAllThreads, before it got removed? If so we'd be hung >> waiting it for it handshake as it's not in a "safepoint-safe" or >> suspend-equivalent state. >> >> David >> ----- >> >> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>> Please, skip it - sorry for the noise. >>> It is hard to prove anything with current dump. >>> >>> Thanks, >>> Serguei >>> >>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David and Robbin, >>>> >>>> I have an idea that needs to be checked. >>>> It can be almost the same deadlock scenario that I've already >>>> explained but more sophisticated. >>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>> Monitor::_safepoint_check_always does not help much. >>>> It can be verified by checking what monitors are used by the >>>> blocked threads. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>> Hi, >>>>> >>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>>>> safepoint operation. There's no real way to tell from the stacks >>>>>> what it's stuck on. >>>>> >>>>> I cannot find a thread that is not considered safepoint safe or >>>>> is_ext_suspended (thread 146). So the handshake should go through. >>>>> The handshake will log a warning after a while, is there such >>>>> warning from the handshake operation? >>>>> >>>>> There are several threads competing with e.g. Threads_lock, and >>>>> threads waiting for GC and several other VM ops, could it just be >>>>> really slow? >>>>> >>>>> /Robbin >>>>> >>>>>> >>>>>> David >>>>>> >>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> You are right, thanks. >>>>>>> It means, this deadlock needs more analysis. >>>>>>> For completeness, the stack traces are in attachments. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint >>>>>>>> checks enabled, so all JavaThreads blocked trying to acquire it >>>>>>>> will be _thread_blocked and so safepoint-safe and so won't be >>>>>>>> holding up the safepoint. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test >>>>>>>>>> might be blocked because it invoke 2 jvmti methods. Can jvmti >>>>>>>>>> agent invoke jvmti methods from different threads? >>>>>>>>> >>>>>>>>> Yes, in general. >>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>> Below, one thread is enabling single stepping while another >>>>>>>>> thread is being suspended. >>>>>>>>> Both are blocked at a safepoint which is Okay in general but >>>>>>>>> not Okay if they hold any lock. >>>>>>>>> For instance, the thread #152 is holding the monitor >>>>>>>>> JvmtiThreadState. >>>>>>>>> >>>>>>>>> Also, I see a couple of more threads that are interesting as >>>>>>>>> well: >>>>>>>>> >>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>> >>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>> ev=0x2ae3984c9100) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>> >>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) >>>>>>>>> at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>> >>>>>>>>> #4? 0x00002ae393b512c1 in lock >>>>>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>> >>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>> >>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>> this=) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>> >>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) >>>>>>>>> at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>> >>>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>> >>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop >>>>>>>>> () at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>> >>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>> >>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >>>>>>>>> (this=0x2ae3984c7800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>> >>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>> >>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>> >>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>> >>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>> ev=0x2ae3984cbb00) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>> >>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) >>>>>>>>> at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>> >>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>> this=0x2ae398024f10) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>> >>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>> >>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>> this=) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>> >>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) >>>>>>>>> at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>> >>>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>> >>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop >>>>>>>>> () at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>> >>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>> >>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >>>>>>>>> (this=0x2ae3984ca800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>> >>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>> >>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>> >>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>> >>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>> ev=0x2ae460061c00) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>> >>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) >>>>>>>>> at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>> >>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>> this=0x2ae398024f10) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>> >>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>> >>>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>> this=) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>> >>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>> >>>>>>>>> #8? JvmtiEventController::thread_started >>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>> >>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>> >>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run >>>>>>>>> (this=0x2ae4600c2800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>> >>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>> >>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from >>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>> >>>>>>>>> >>>>>>>>> These two thread are blocked on the monitor >>>>>>>>> JvmtiThreadState_lock in the function ciEnv::cache_jvmti_state(). >>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>> >>>>>>>>> >>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>>> safepoint is waiting for? >>>>>>>>> >>>>>>>>> I think, this safepoint operation is waiting for all threads >>>>>>>>> that are blocked on the JvmtiThreadState_lock. >>>>>>>>> >>>>>>>>> Conclusion: >>>>>>>>> >>>>>>>>> The deadlock is: >>>>>>>>> >>>>>>>>> Thread #152: >>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>> >>>>>>>>> Many other threads: >>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>> ?? - can not reach the blocked at a safepoint state (all >>>>>>>>> threads have to reach this state for this safepoint to happen) >>>>>>>>> >>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>> >>>>>>>>> My guess is that this will stop to reproduce after if you turn >>>>>>>>> off the single stepping for thread #152. >>>>>>>>> Please, let me know about the results. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Assuming that crashes look like VM bugs I think it make sense >>>>>>>>>> to integrate jvmti changes but *don't* enabled jvmti module >>>>>>>>>> by default. >>>>>>>>> >>>>>>>>> This one is a deadlock. >>>>>>>>> However, the root cause is a race condition that can >>>>>>>>> potentially result in both deadlocks and crashes. >>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>> >>>>>>>>> >>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>> So anyone could easily run them to reproduce crashes. ?This >>>>>>>>>> test would be out of CI to don't introduce any bugs. Does it >>>>>>>>>> make sense? >>>>>>>>>> >>>>>>>>>> Consider hang - I think that it might be product bug since I >>>>>>>>>> don't see any locking on my monitors. But I am not sure. Is >>>>>>>>>> it possible that any my code jvmti agent prevent VM to get >>>>>>>>>> into safepoint? >>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>> >>>>>>>>> Yes, of course. >>>>>>>>> Let's find some time tomorrow. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>> >>>>>>>>> Analysis of stack traces is needed. >>>>>>>>> It is non-trivial in this particular case as there are so many >>>>>>>>> threads executed at the same time. >>>>>>>>> >>>>>>>>> >>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>> >>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>> >>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>>> ev=0x2ae454005800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>> >>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>> >>>>>>>>>> 8 >>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>> (this=this at entry=0x2ae398023c10, >>>>>>>>>> no_safepoint_check=, timeout=timeout at entry=0, >>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>> try=false) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>> >>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>> >>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>> >>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>> >>>>>>>>>> 47 >>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) >>>>>>>>>> at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>> >>>>>>>>>> nv.cpp:955 >>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>> >>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler >>>>>>>>>> (jvmti=0x2ae39801b270, env=, p=>>>>>>>>> out>) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>> >>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>> >>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>> >>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>> >>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>> >>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>> >>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>> >>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>>> ev=0x2ae3985e7400) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>> >>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>> >>>>>>>>>> 8 >>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>> (this=this at entry=0x2ae398023c10, >>>>>>>>>> no_safepoint_check=, timeout=timeout at entry=0, >>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>> try=false) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>> >>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>> (op=0x2ae42705f500) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>> >>>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>> ue) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>> >>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>> >>>>>>>>>> r.cpp:490 >>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>> >>>>>>>>>> :523 >>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>> >>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>>>>> env=0x2ae39801b270) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>> #11 JvmtiEventController::set_user_enabled >>>>>>>>>> (env=0x2ae39801b270, thread=0x0, >>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, enabled=) >>>>>>>>>> at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>>>> (this=this at entry=0x2ae39801b270, >>>>>>>>>> mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>> >>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>> event_thread=event_\ >>>>>>>>>> thread at entry=0x0) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>> >>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>> >>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>> (env=, this=) at >>>>>>>>>> /scratch/lmesnik/ws/h\ >>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>> >>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Leonid >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Leonid, >>>>>>>>>>> >>>>>>>>>>> There is an existing bug: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>> >>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>> >>>>>>>>>>>> Leonid >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> # >>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>>> Environment: >>>>>>>>>>>> # >>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>> # >>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>>>>>> (fastdebug build >>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed >>>>>>>>>>>> mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>> # Core dump will be written. Default location: Core dumps >>>>>>>>>>>> may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p >>>>>>>>>>>> %u %g %t e %P %I %h" (or dumping to >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>> >>>>>>>>>>>> # >>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>> # >>>>>>>>>>>> >>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>> >>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 >>>>>>>>>>>> -XX:MaxRAMPercentage=50 -XX:+CrashOnOutOfMemoryError >>>>>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>>> -XX:+FlightRecorder >>>>>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Host: scaaa118.us.oracle.com >>>>>>>>>>>> , Intel(R) Xeon(R) CPU >>>>>>>>>>>> E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux Server >>>>>>>>>>>> release 7.3 >>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds >>>>>>>>>>>> (0d 0h 0m 31s) >>>>>>>>>>>> >>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>> >>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>> >>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java >>>>>>>>>>>> code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned >>>>>>>>>>>> char*, void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>>>>>> __va_list_tag*)+0x2f >>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, >>>>>>>>>>>> char const*, char const*, ...)+0x100 >>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>> >>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, >>>>>>>>>>>> mode: safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>> >>> From mandy.chung at oracle.com Wed Oct 24 03:22:15 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 23 Oct 2018 20:22:15 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <43be9a19-d0c5-298a-9bcb-e98223f4566a@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> <5b6265b6-36b3-4317-1e6a-8ba51c8a48b3@oracle.com> <0560343b-94b4-2261-0f1d-a08d7067e97b@oracle.com> <43be9a19-d0c5-298a-9bcb-e98223f4566a@oracle.com> Message-ID: <385be5ad-c124-c9b2-9339-006683abd953@oracle.com> On 10/23/18 3:30 PM, dean.long at oracle.com wrote: > On 10/23/18 2:51 PM, David Holmes wrote: >> >>>> OK, but even if the regular benchmarks don't show a difference, I'd >>>> feel better if microbenchmarks were not affected.? What if I go >>>> back to the original approach and add locking: >>>> >>>> ?? static jlong get_live_thread_count()??????? { MutexLocker >>>> mu(Threads_lock); return _live_threads_count->get_value() - >>>> _exiting_threads_count; } >>>> ?? static jlong get_daemon_thread_count()????? { MutexLocker >>>> mu(Threads_lock); return _daemon_threads_count->get_value() - >>>> _exiting_daemon_threads_count; } >>>> >>>> along with the other cleanups around is_daemon and is_hidden_thread? >>>> >>> >>> Some micro-benchmarks like SecureRandomBench show a regression with >>> webrev.7.? I could go back to webrev.5 and then we shouldn't need >>> any locking in the get_*() functions. >> >> I don't see version 5 discussed but I took a look and it seems okay. > > Mandy had questions about the asserts in .5, and it seemed like we > could just set the perf counters to the same value as the atomic > counters, which resulted in .6.? I think the only problem with .6 is > that I set the perf counters in decrement_thread_counts without the > lock.? If I "sync" the perf counters to the atomic counters only in > add_thread and remove_thread, with the lock, then it's about the same > as .5, but without the asserts and parallel inc/dec.? If anyone likes > the sound of that, I can send out a new webrev. ThreadService::current_thread_exiting will decrement the atomic counters. add_thread will increase atomic counters and sync the perf counters with the atomic counters. remove_thread will decrement the atomic counters if thread is not exiting and update the perf counters to the atomic counters. I'm good with that. > Or we can go with webrev.5. > >> My only query with that version is that it appears the actual >> perfCounters no longer get read by anything - is that the case? >> > > There does seem to be code that references them, through their name > string.? That's a difference interface that I'm not familiar with, so > I didn't want to break it. The perf counters are exposed via jstat tool.? I don't know who relies on jstat to monitor thread counts.?? I suggest to check with the performance team if they depend on these counters.?? With JFR, I think we should re-examine whether these perf counters should stay. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Oct 24 05:34:03 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Oct 2018 15:34:03 +1000 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <43be9a19-d0c5-298a-9bcb-e98223f4566a@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> <5b6265b6-36b3-4317-1e6a-8ba51c8a48b3@oracle.com> <0560343b-94b4-2261-0f1d-a08d7067e97b@oracle.com> <43be9a19-d0c5-298a-9bcb-e98223f4566a@oracle.com> Message-ID: <98af2e32-b9e7-e06a-91fc-447baa445bed@oracle.com> On 24/10/2018 8:30 AM, dean.long at oracle.com wrote: > On 10/23/18 2:51 PM, David Holmes wrote: >> Hi Dean, >> >> On 24/10/2018 4:05 AM, dean.long at oracle.com wrote: >>> On 10/23/18 9:46 AM, dean.long at oracle.com wrote: >>>> On 10/22/18 3:31 PM, David Holmes wrote: >>>>> Sorry Dean I'm concerned about a thread termination bottleneck with >>>>> this. A simple microbenchmark that creates 500,000 threads that >>>>> have to run and terminate, shows a 15+% slowdown on my Linux box. I >>>>> tried to find some kind of real benchmarks that covers thread >>>>> termination but couldn't see anything specific. >>>>> >>>>> Can you at least run this through our performance system to see if >>>>> any of the regular benchmarks are affected. >>>>> >>>> >>>> OK, but even if the regular benchmarks don't show a difference, I'd >>>> feel better if microbenchmarks were not affected.? What if I go back >>>> to the original approach and add locking: >>>> >>>> ?? static jlong get_live_thread_count()??????? { MutexLocker >>>> mu(Threads_lock); return _live_threads_count->get_value() - >>>> _exiting_threads_count; } >>>> ?? static jlong get_daemon_thread_count()????? { MutexLocker >>>> mu(Threads_lock); return _daemon_threads_count->get_value() - >>>> _exiting_daemon_threads_count; } >>>> >>>> along with the other cleanups around is_daemon and is_hidden_thread? >>>> >>> >>> Some micro-benchmarks like SecureRandomBench show a regression with >>> webrev.7.? I could go back to webrev.5 and then we shouldn't need any >>> locking in the get_*() functions. >> >> I don't see version 5 discussed but I took a look and it seems okay. > > Mandy had questions about the asserts in .5, and it seemed like we could > just set the perf counters to the same value as the atomic counters, > which resulted in .6.? I think the only problem with .6 is that I set > the perf counters in decrement_thread_counts without the lock.? If I > "sync" the perf counters to the atomic counters only in add_thread and > remove_thread, with the lock, then it's about the same as .5, but > without the asserts and parallel inc/dec.? If anyone likes the sound of > that, I can send out a new webrev.? Or we can go with webrev.5. I'm not sure what the concern was with the asserts - if they mis-fire we'll know soon enough. So I'm okay with .5 >> My only query with that version is that it appears the actual >> perfCounters no longer get read by anything - is that the case? >> > > There does seem to be code that references them, through their name > string.? That's a difference interface that I'm not familiar with, so I > didn't want to break it. Right - they can be accessed directly through other means. I was concerned that the perfCounter was out of sync with get_live_thread-count() but that's already the case so not an issue. If all tests and benchmarks are happy I say go with version .5 Thanks, David > dl > >> Thanks, >> David >> >>> dl >>> >>>> dl >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 20/10/2018 1:28 PM, dean.long at oracle.com wrote: >>>>>> On 10/18/18 6:12 PM, Mandy Chung wrote: >>>>>>> >>>>>>> >>>>>>> On 10/18/18 12:27 AM, David Holmes wrote: >>>>>>>> Hi Dean, >>>>>>>> >>>>>>>> On 18/10/2018 2:06 PM, dean.long at oracle.com wrote: >>>>>>>>> >>>>>>>>> You're right, I missed that.? I think the right thing to do is >>>>>>>>> call current_thread_exiting while holding the Threads_lock. >>>>>>>>> Then we can get rid of the parallel atomic counters. So, here's >>>>>>>>> one more try: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~dlong/8021335/webrev.7/ >>>>>>>> >>>>>>>> Okay that is the simple and obvious solution that doesn't >>>>>>>> require split counts. So I have to ask Mandy if she recalls why >>>>>>>> this approach wasn't taken 15 years ago when the exit counts >>>>>>>> were added as part of: >>>>>>>> >>>>>>> >>>>>>> It has been so long.? I think it's likely an oversight. >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-4530538 ? >>>>>>>> >>>>>>>> Does taking the Threads_lock here cost too much and cause a >>>>>>>> thread termination bottleneck? >>>>>>> >>>>>>> If the contention on Threads_lock is not high (that seems to me), >>>>>>> it should be okay. ? I'm not close to the VM implementation (lot >>>>>>> of changes since then) and I don't have a definitive answer >>>>>>> unless I study the code closely.?? You and others have a better >>>>>>> judgement on this. >>>>>>> >>>>>>> AFAICT the change is okay. >>>>>>> >>>>>> >>>>>> Thanks Mandy.? David, OK to push? >>>>>> >>>>>> dl >>>>>> >>>>>>> Mandy >>>>>>> >>>>>>> >>>>>> >>>> >>> > From mandy.chung at oracle.com Wed Oct 24 06:04:30 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 23 Oct 2018 23:04:30 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <98af2e32-b9e7-e06a-91fc-447baa445bed@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> <5b6265b6-36b3-4317-1e6a-8ba51c8a48b3@oracle.com> <0560343b-94b4-2261-0f1d-a08d7067e97b@oracle.com> <43be9a19-d0c5-298a-9bcb-e98223f4566a@oracle.com> <98af2e32-b9e7-e06a-91fc-447baa445bed@oracle.com> Message-ID: <4febfc04-21c3-fd91-db83-54777ebd7ca2@oracle.com> On 10/23/18 10:34 PM, David Holmes wrote: > On 24/10/2018 8:30 AM, dean.long at oracle.com wrote: >> On 10/23/18 2:51 PM, David Holmes wrote: >>> Hi Dean, >>> >>> On 24/10/2018 4:05 AM, dean.long at oracle.com wrote: >>>> On 10/23/18 9:46 AM, dean.long at oracle.com wrote: >>>>> On 10/22/18 3:31 PM, David Holmes wrote: >>>>>> Sorry Dean I'm concerned about a thread termination bottleneck >>>>>> with this. A simple microbenchmark that creates 500,000 threads >>>>>> that have to run and terminate, shows a 15+% slowdown on my Linux >>>>>> box. I tried to find some kind of real benchmarks that covers >>>>>> thread termination but couldn't see anything specific. >>>>>> >>>>>> Can you at least run this through our performance system to see >>>>>> if any of the regular benchmarks are affected. >>>>>> >>>>> >>>>> OK, but even if the regular benchmarks don't show a difference, >>>>> I'd feel better if microbenchmarks were not affected.? What if I >>>>> go back to the original approach and add locking: >>>>> >>>>> ?? static jlong get_live_thread_count()??????? { MutexLocker >>>>> mu(Threads_lock); return _live_threads_count->get_value() - >>>>> _exiting_threads_count; } >>>>> ?? static jlong get_daemon_thread_count()????? { MutexLocker >>>>> mu(Threads_lock); return _daemon_threads_count->get_value() - >>>>> _exiting_daemon_threads_count; } >>>>> >>>>> along with the other cleanups around is_daemon and is_hidden_thread? >>>>> >>>> >>>> Some micro-benchmarks like SecureRandomBench show a regression with >>>> webrev.7.? I could go back to webrev.5 and then we shouldn't need >>>> any locking in the get_*() functions. >>> >>> I don't see version 5 discussed but I took a look and it seems okay. >> >> Mandy had questions about the asserts in .5, and it seemed like we >> could just set the perf counters to the same value as the atomic >> counters, which resulted in .6.? I think the only problem with .6 is >> that I set the perf counters in decrement_thread_counts without the >> lock.? If I "sync" the perf counters to the atomic counters only in >> add_thread and remove_thread, with the lock, then it's about the same >> as .5, but without the asserts and parallel inc/dec.? If anyone likes >> the sound of that, I can send out a new webrev.? Or we can go with >> webrev.5. > > I'm not sure what the concern was with the asserts - if they mis-fire > we'll know soon enough. So I'm okay with .5 > >>> My only query with that version is that it appears the actual >>> perfCounters no longer get read by anything - is that the case? >>> >> >> There does seem to be code that references them, through their name >> string.? That's a difference interface that I'm not familiar with, so >> I didn't want to break it. > > Right - they can be accessed directly through other means. I was > concerned that the perfCounter was out of sync with > get_live_thread-count() but that's already the case so not an issue. > > If all tests and benchmarks are happy I say go with version .5 > I have no objection to version .5 if most people prefer that.? My comment was that I don't think the asserts are necessary. Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Wed Oct 24 07:18:49 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 24 Oct 2018 09:18:49 +0200 Subject: The failure In-Reply-To: References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> Message-ID: <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> Hi, truncate: On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>> One thing I noticed which Robbin should be able to expand upon is that Thread >>> 101 is terminating and has called ThreadsSMRSupport::smr_delete and is >>> blocked here: >>> >>> ??// Wait for a release_stable_list() call before we check again. No >>> ??// safepoint check, no timeout, and not as suspend equivalent flag >>> ??// because this JavaThread is not on the Threads list. >>> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>> ???????????????????????????????????????? 0, >>> !Mutex::_as_suspend_equivalent_flag); >>> >>> As the comment says this thread is no longer on the Threads_list, but the >>> VM_HandshakeAllThreads is not a safepoint operation and does not hold the >>> Threads_lock, so is it possible this thread was captured by the >>> JavaThreadIteratorWithHandle being used by VM_HandshakeAllThreads, before it >>> got removed? If so we'd be hung waiting it for it handshake as it's not in a >>> "safepoint-safe" or suspend-equivalent state. In short: # VM Thread VM Thread is in a loop, takes Threads_lock, takes a new snapshot of the Threads_list, scans the list and process handshakes on behalf of safe threads. Releases snapshot and Threads_lock and checks if all handshakes are completed # An exiting thread A thread exiting thread removes it self from _THE_ threads list, but must stick around if it is on any snapshots of alive. When it is no on any list it will cancel the handshake. Since VM thread during the handshake takes a new snapshot every iteration any exiting can proceed since it will not be a the new snapshot. Thus cancel the handshake and VM thread can exit the loop (if this was the last handshake). Constraint: If any thread grabs a snapshot of threads list and later tries to take a lock which is 'used' by VM Thread or inside the handshake we can deadlock. Considering that looking at e.g. : JvmtiEnv::SuspendThreadList Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, this could deadlock AFAICT. Since the thread will rest on VMOperationRequest_lock with a Threads list snapshot but VM thread cannot finishes handshake until that snapshot is released. I suggest first step is to add something like this patch below and fix the obvious ones first. Note, I have not verified that is the problem you are seeing, I'm saying that this seem to be real issue. And considering how the stack traces looks, it may be this. You want me going through this, just assign a bug if there is one? /Robbin diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp --- a/src/hotspot/share/runtime/thread.hpp Tue Oct 23 13:27:41 2018 +0200 +++ b/src/hotspot/share/runtime/thread.hpp Wed Oct 24 09:13:17 2018 +0200 @@ -167,2 +167,6 @@ } + public: + bool have_threads_list(); + private: + // This field is enabled via -XX:+EnableThreadSMRStatistics: diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp --- a/src/hotspot/share/runtime/thread.inline.hpp Tue Oct 23 13:27:41 2018 +0200 +++ b/src/hotspot/share/runtime/thread.inline.hpp Wed Oct 24 09:13:17 2018 +0200 @@ -111,2 +111,6 @@ +inline bool Thread::have_threads_list() { + return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; +} + inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp --- a/src/hotspot/share/runtime/vmThread.cpp Tue Oct 23 13:27:41 2018 +0200 +++ b/src/hotspot/share/runtime/vmThread.cpp Wed Oct 24 09:13:17 2018 +0200 @@ -608,2 +608,3 @@ if (!t->is_VM_thread()) { + assert(t->have_threads_list(), "Deadlock if we have exiting threads and if vm thread is running an VM op."); // fatal/guarantee SkipGCALot sgcalot(t); // avoid re-entrant attempts to gc-a-lot >>> >>> David >>> ----- >>> >>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, skip it - sorry for the noise. >>>> It is hard to prove anything with current dump. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi David and Robbin, >>>>> >>>>> I have an idea that needs to be checked. >>>>> It can be almost the same deadlock scenario that I've already explained but >>>>> more sophisticated. >>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>>> Monitor::_safepoint_check_always does not help much. >>>>> It can be verified by checking what monitors are used by the blocked threads. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>> Hi, >>>>>> >>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a safepoint >>>>>>> operation. There's no real way to tell from the stacks what it's stuck on. >>>>>> >>>>>> I cannot find a thread that is not considered safepoint safe or >>>>>> is_ext_suspended (thread 146). So the handshake should go through. The >>>>>> handshake will log a warning after a while, is there such warning from the >>>>>> handshake operation? >>>>>> >>>>>> There are several threads competing with e.g. Threads_lock, and threads >>>>>> waiting for GC and several other VM ops, could it just be really slow? >>>>>> >>>>>> /Robbin >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> You are right, thanks. >>>>>>>> It means, this deadlock needs more analysis. >>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>>>>>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>>>>>>> _thread_blocked and so safepoint-safe and so won't be holding up the >>>>>>>>> safepoint. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>> Hi >>>>>>>>>>> >>>>>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test might be >>>>>>>>>>> blocked because it invoke 2 jvmti methods. Can jvmti agent invoke >>>>>>>>>>> jvmti methods from different threads? >>>>>>>>>> >>>>>>>>>> Yes, in general. >>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>> Below, one thread is enabling single stepping while another thread is >>>>>>>>>> being suspended. >>>>>>>>>> Both are blocked at a safepoint which is Okay in general but not Okay >>>>>>>>>> if they hold any lock. >>>>>>>>>> For instance, the thread #152 is holding the monitor JvmtiThreadState. >>>>>>>>>> >>>>>>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>>>>>> >>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>> >>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>> >>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>> >>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984c7is_ext_suspended800, >>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>> >>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>> >>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>> this=) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>> >>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>> >>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>> >>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>> >>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>> >>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c7800) >>>>>>>>>> at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>> >>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>> >>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>> >>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>> >>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>> >>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>> >>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>> this=) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>> >>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>> >>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>> >>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>> >>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>> >>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984ca800) >>>>>>>>>> at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>> >>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>> >>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>> >>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>> >>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>> >>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>> >>>>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>> this=) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>> >>>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>> >>>>>>>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>> >>>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>> >>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>> >>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c2800) >>>>>>>>>> at >>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> These two thread are blocked on the monitor JvmtiThreadState_lock in >>>>>>>>>> the function ciEnv::cache_jvmti_state(). >>>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>> What thread is blocking it? Or in reverse, what thread this safepoint >>>>>>>>>> is waiting for? >>>>>>>>>> >>>>>>>>>> I think, this safepoint operation is waiting for all threads that are >>>>>>>>>> blocked on the JvmtiThreadState_lock. >>>>>>>>>> >>>>>>>>>> Conclusion: >>>>>>>>>> >>>>>>>>>> The deadlock is: >>>>>>>>>> >>>>>>>>>> Thread #152: >>>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>>> >>>>>>>>>> Many other threads: >>>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>> ?? - can not reach the blocked at a safepoint state (all threads have >>>>>>>>>> to reach this state for this safepoint to happen) >>>>>>>>>> >>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>> >>>>>>>>>> My guess is that this will stop to reproduce after if you turn off the >>>>>>>>>> single stepping for thread #152. >>>>>>>>>> Please, let me know about the results. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>>>>>>> integrate jvmti changes but *don't* enabled jvmti module by default. >>>>>>>>>> >>>>>>>>>> This one is a deadlock. >>>>>>>>>> However, the root cause is a race condition that can potentially >>>>>>>>>> result in both deadlocks and crashes. >>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>>>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>>>>>>> >>>>>>>>>>> Consider hang - I think that it might be product bug since I don't >>>>>>>>>>> see any locking on my monitors. But I am not sure. Is it possible >>>>>>>>>>> that any my code jvmti agent prevent VM to get into safepoint? >>>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>>> >>>>>>>>>> Yes, of course. >>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>> >>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>> It is non-trivial in this particular case as there are so many threads >>>>>>>>>> executed at the same time. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>> >>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>> >>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>> >>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>> >>>>>>>>>>> 8 >>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=, >>>>>>>>>>> timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>> try=false) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>> >>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>> >>>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>> >>>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>> >>>>>>>>>>> 47 >>>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>> nv.cpp:955 >>>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >>>>>>>>>>> thread=0x2ae49929fdf8) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>> >>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>>>>>>> env=, p=) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>> >>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) >>>>>>>>>>> at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>> >>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, >>>>>>>>>>> __the_thread__=) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>> >>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>> >>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>> >>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) >>>>>>>>>>> at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>> >>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>> >>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>> >>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>> >>>>>>>>>>> 8 >>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=, >>>>>>>>>>> timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>> try=false) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>> >>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>> >>>>>>>>>>> #6 ?0x00002ae3939965f3 in JvmtiEnvThreadState::reset_current_location >>>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>>> ue) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>> >>>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>> >>>>>>>>>>> r.cpp:490 >>>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>> >>>>>>>>>>> :523 >>>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>> >>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) >>>>>>>>>>> at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>>>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>>>>>>>>>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>> >>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>> event_thread=event_\ >>>>>>>>>>> thread at entry=0x0) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>> >>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>> >>>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>>> (env=, this=) at /scratch/lmesnik/ws/h\ >>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>> >>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Leonid >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>> >>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth >>>>>>>>>>>>> out of sync >>>>>>>>>>>>> >>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>> >>>>>>>>>>>>> Leonid >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> # >>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>>>>>>> # >>>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>> # >>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug >>>>>>>>>>>>> build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, >>>>>>>>>>>>> tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>> # Core dump will be written. Default location: Core dumps may be >>>>>>>>>>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P >>>>>>>>>>>>> %I %h" (or dumping to >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>> >>>>>>>>>>>>> # >>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>> # >>>>>>>>>>>>> >>>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>>> >>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>>>>>>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false >>>>>>>>>>>>> -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>>>> -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >>>>>>>>>>>>> Linux Server release 7.3 >>>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d 0h >>>>>>>>>>>>> 0m 31s) >>>>>>>>>>>>> >>>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>>> >>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" [stack: >>>>>>>>>>>>> 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>> >>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>>>>>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char const*, >>>>>>>>>>>>> char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, >>>>>>>>>>>>> char const*, int, unsigned long)+0x2c3 >>>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, void*, >>>>>>>>>>>>> char const*, int, char const*, char const*, __va_list_tag*)+0x2f >>>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>>>>>>>>>> const*, char const*, ...)+0x100 >>>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>> >>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>> >>>> > From david.holmes at oracle.com Wed Oct 24 07:46:33 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 24 Oct 2018 17:46:33 +1000 Subject: The failure In-Reply-To: <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> Message-ID: <1796f4d0-eda7-8b96-6b14-ab68ebfcd2d1@oracle.com> Thanks Robbin! So you're no allowed to request a VM operation if you hold a ThreadsListHandle ? I suppose that is no different to not being able to request a VM operation whilst holding the Threads_lock. I suspect before ThreadSMR this may have been a case where we weren't ensuring a target thread could not terminate, and now with SMR we're ensuring that but potentially introducing a deadlock. I say potentially because obviously we don't deadlock every time we suspend threads. Cheers, David On 24/10/2018 5:18 PM, Robbin Ehn wrote: > Hi, truncate: > > On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>> One thing I noticed which Robbin should be able to expand upon is >>>> that Thread 101 is terminating and has called >>>> ThreadsSMRSupport::smr_delete and is blocked here: >>>> >>>> ??// Wait for a release_stable_list() call before we check again. No >>>> ??// safepoint check, no timeout, and not as suspend equivalent flag >>>> ??// because this JavaThread is not on the Threads list. >>>> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>> >>>> ???????????????????????????????????????? 0, >>>> !Mutex::_as_suspend_equivalent_flag); >>>> >>>> As the comment says this thread is no longer on the Threads_list, >>>> but the VM_HandshakeAllThreads is not a safepoint operation and does >>>> not hold the Threads_lock, so is it possible this thread was >>>> captured by the JavaThreadIteratorWithHandle being used by >>>> VM_HandshakeAllThreads, before it got removed? If so we'd be hung >>>> waiting it for it handshake as it's not in a "safepoint-safe" or >>>> suspend-equivalent state. > > In short: > # VM Thread > VM Thread is in a loop, takes Threads_lock, takes a new snapshot of the > Threads_list, scans the list and process handshakes on behalf of safe > threads. > Releases snapshot and Threads_lock and checks if all handshakes are > completed > > # An exiting thread > A thread exiting thread removes it self from _THE_ threads list, but > must stick around if it is on any snapshots of alive. When it is no on > any list it will cancel the handshake. > > Since VM thread during the handshake takes a new snapshot every > iteration any exiting can proceed since it will not be a the new > snapshot. Thus cancel the handshake and VM thread can exit the loop (if > this was the last handshake). > > Constraint: > If any thread grabs a snapshot of threads list and later tries to take a > lock which is 'used' by VM Thread or inside the handshake we can deadlock. > > Considering that looking at e.g. : JvmtiEnv::SuspendThreadList > Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, > this could deadlock AFAICT. Since the thread will rest on > VMOperationRequest_lock with a Threads list snapshot but VM thread > cannot finishes handshake until that snapshot is released. > > I suggest first step is to add something like this patch below and fix > the obvious ones first. > > Note, I have not verified that is the problem you are seeing, I'm saying > that this seem to be real issue. And considering how the stack traces > looks, it may be this. > > You want me going through this, just assign a bug if there is one? > > /Robbin > > diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp > --- a/src/hotspot/share/runtime/thread.hpp??? Tue Oct 23 13:27:41 2018 > +0200 > +++ b/src/hotspot/share/runtime/thread.hpp??? Wed Oct 24 09:13:17 2018 > +0200 > @@ -167,2 +167,6 @@ > ?? } > + public: > +? bool have_threads_list(); > + private: > + > ?? // This field is enabled via -XX:+EnableThreadSMRStatistics: > diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp > --- a/src/hotspot/share/runtime/thread.inline.hpp??? Tue Oct 23 13:27:41 > 2018 +0200 > +++ b/src/hotspot/share/runtime/thread.inline.hpp??? Wed Oct 24 09:13:17 > 2018 +0200 > @@ -111,2 +111,6 @@ > > +inline bool Thread::have_threads_list() { > +? return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; > +} > + > ?inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { > diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp > --- a/src/hotspot/share/runtime/vmThread.cpp??? Tue Oct 23 13:27:41 2018 > +0200 > +++ b/src/hotspot/share/runtime/vmThread.cpp??? Wed Oct 24 09:13:17 2018 > +0200 > @@ -608,2 +608,3 @@ > ?? if (!t->is_VM_thread()) { > +??? assert(t->have_threads_list(), "Deadlock if we have exiting threads > and if vm thread is running an VM op."); // fatal/guarantee > ???? SkipGCALot sgcalot(t);??? // avoid re-entrant attempts to gc-a-lot > > > > > >>>> >>>> David >>>> ----- >>>> >>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>> Please, skip it - sorry for the noise. >>>>> It is hard to prove anything with current dump. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David and Robbin, >>>>>> >>>>>> I have an idea that needs to be checked. >>>>>> It can be almost the same deadlock scenario that I've already >>>>>> explained but more sophisticated. >>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>>>> Monitor::_safepoint_check_always does not help much. >>>>>> It can be verified by checking what monitors are used by the >>>>>> blocked threads. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>>>>>> safepoint operation. There's no real way to tell from the stacks >>>>>>>> what it's stuck on. >>>>>>> >>>>>>> I cannot find a thread that is not considered safepoint safe or >>>>>>> is_ext_suspended (thread 146). So the handshake should go >>>>>>> through. The handshake will log a warning after a while, is there >>>>>>> such warning from the handshake operation? >>>>>>> >>>>>>> There are several threads competing with e.g. Threads_lock, and >>>>>>> threads waiting for GC and several other VM ops, could it just be >>>>>>> really slow? >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> You are right, thanks. >>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint >>>>>>>>>> checks enabled, so all JavaThreads blocked trying to acquire >>>>>>>>>> it will be _thread_blocked and so safepoint-safe and so won't >>>>>>>>>> be holding up the safepoint. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> Seems last version also crashes with 2 other different >>>>>>>>>>>> symptoms. >>>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test >>>>>>>>>>>> might be blocked because it invoke 2 jvmti methods. Can >>>>>>>>>>>> jvmti agent invoke jvmti methods from different threads? >>>>>>>>>>> >>>>>>>>>>> Yes, in general. >>>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>>> Below, one thread is enabling single stepping while another >>>>>>>>>>> thread is being suspended. >>>>>>>>>>> Both are blocked at a safepoint which is Okay in general but >>>>>>>>>>> not Okay if they hold any lock. >>>>>>>>>>> For instance, the thread #152 is holding the monitor >>>>>>>>>>> JvmtiThreadState. >>>>>>>>>>> >>>>>>>>>>> Also, I see a couple of more threads that are interesting as >>>>>>>>>>> well: >>>>>>>>>>> >>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>> >>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>> ev=0x2ae3984c9100) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>> >>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) >>>>>>>>>>> at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>> >>>>>>>>>>> #4? 0x00002ae393b512c1 in lock >>>>>>>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>> >>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>> >>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>> this=) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>> >>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) >>>>>>>>>>> at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>> >>>>>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>> >>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop >>>>>>>>>>> () at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>> >>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>> >>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>> (this=0x2ae3984c7800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>> >>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>> >>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>> >>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>> >>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>> ev=0x2ae3984cbb00) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>> >>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) >>>>>>>>>>> at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>> >>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>> >>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>> >>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>> this=) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>> >>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) >>>>>>>>>>> at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>> >>>>>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>> >>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop >>>>>>>>>>> () at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>> >>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>> >>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>> (this=0x2ae3984ca800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>> >>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>> >>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>> >>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>> >>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>> ev=0x2ae460061c00) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>> >>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) >>>>>>>>>>> at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>> >>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>> >>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>> >>>>>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>> this=) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>> >>>>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>>> >>>>>>>>>>> #8? JvmtiEventController::thread_started >>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>>> >>>>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>>> >>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run >>>>>>>>>>> (this=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>>> >>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>> >>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> These two thread are blocked on the monitor >>>>>>>>>>> JvmtiThreadState_lock in the function >>>>>>>>>>> ciEnv::cache_jvmti_state(). >>>>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>>>>> safepoint is waiting for? >>>>>>>>>>> >>>>>>>>>>> I think, this safepoint operation is waiting for all threads >>>>>>>>>>> that are blocked on the JvmtiThreadState_lock. >>>>>>>>>>> >>>>>>>>>>> Conclusion: >>>>>>>>>>> >>>>>>>>>>> The deadlock is: >>>>>>>>>>> >>>>>>>>>>> Thread #152: >>>>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>> >>>>>>>>>>> Many other threads: >>>>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>> ?? - can not reach the blocked at a safepoint state (all >>>>>>>>>>> threads have to reach this state for this safepoint to happen) >>>>>>>>>>> >>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>> >>>>>>>>>>> My guess is that this will stop to reproduce after if you >>>>>>>>>>> turn off the single stepping for thread #152. >>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make >>>>>>>>>>>> sense to integrate jvmti changes but *don't* enabled jvmti >>>>>>>>>>>> module by default. >>>>>>>>>>> >>>>>>>>>>> This one is a deadlock. >>>>>>>>>>> However, the root cause is a race condition that can >>>>>>>>>>> potentially result in both deadlocks and crashes. >>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>> So anyone could easily run them to reproduce crashes. ?This >>>>>>>>>>>> test would be out of CI to don't introduce any bugs. Does it >>>>>>>>>>>> make sense? >>>>>>>>>>>> >>>>>>>>>>>> Consider hang - I think that it might be product bug since I >>>>>>>>>>>> don't see any locking on my monitors. But I am not sure. Is >>>>>>>>>>>> it possible that any my code jvmti agent prevent VM to get >>>>>>>>>>>> into safepoint? >>>>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>>>> >>>>>>>>>>> Yes, of course. >>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>> >>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>> It is non-trivial in this particular case as there are so >>>>>>>>>>> many threads executed at the same time. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>> >>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>>>>> ev=0x2ae454005800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>> >>>>>>>>>>>> 8 >>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>> (this=this at entry=0x2ae398023c10, >>>>>>>>>>>> no_safepoint_check=, timeout=timeout at entry=0, >>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>> try=false) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>> >>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>> >>>>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>>> >>>>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>>> >>>>>>>>>>>> 47 >>>>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) >>>>>>>>>>>> at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>> >>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>>>>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>>> >>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler >>>>>>>>>>>> (jvmti=0x2ae39801b270, env=, p=>>>>>>>>>>> out>) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>>> >>>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>>> >>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>>> >>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>> >>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>> >>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> >>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>>>>> ev=0x2ae3985e7400) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>> >>>>>>>>>>>> 8 >>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>> (this=this at entry=0x2ae398023c10, >>>>>>>>>>>> no_safepoint_check=, timeout=timeout at entry=0, >>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>> try=false) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>> >>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>> (op=0x2ae42705f500) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>> >>>>>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>>>> ue) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>>> >>>>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>>> >>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>>> >>>>>>>>>>>> :523 >>>>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>>>>>>> env=0x2ae39801b270) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled >>>>>>>>>>>> (env=0x2ae39801b270, thread=0x0, >>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, enabled=) >>>>>>>>>>>> at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>>>>>> (this=this at entry=0x2ae39801b270, >>>>>>>>>>>> mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>>> >>>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>> event_thread=event_\ >>>>>>>>>>>> thread at entry=0x0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>>> >>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>>> >>>>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>>>> (env=, this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/h\ >>>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>>> >>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Leonid >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>> >>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>> Hi >>>>>>>>>>>>>> >>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> # >>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>>>>> Environment: >>>>>>>>>>>>>> # >>>>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>> # >>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>>>>>>>> (fastdebug build >>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed >>>>>>>>>>>>>> mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>> # Core dump will be written. Default location: Core dumps >>>>>>>>>>>>>> may be processed with "/usr/libexec/abrt-hook-ccpp %s %c >>>>>>>>>>>>>> %p %u %g %t e %P %I %h" (or dumping to >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>>> >>>>>>>>>>>>>> # >>>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>> # >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 >>>>>>>>>>>>>> -XX:MaxRAMPercentage=50 -XX:+CrashOnOutOfMemoryError >>>>>>>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC >>>>>>>>>>>>>> -XX:+PrintFlagsFinal -XX:+StartAttachListener >>>>>>>>>>>>>> -XX:NativeMemoryTracking=detail -XX:+FlightRecorder >>>>>>>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Host: scaaa118.us.oracle.com >>>>>>>>>>>>>> , Intel(R) Xeon(R) CPU >>>>>>>>>>>>>> E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux Server >>>>>>>>>>>>>> release 7.3 >>>>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 >>>>>>>>>>>>>> seconds (0d 0h 0m 31s) >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java >>>>>>>>>>>>>> code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, >>>>>>>>>>>>>> char const*, char const*, __va_list_tag*, Thread*, >>>>>>>>>>>>>> unsigned char*, void*, void*, char const*, int, unsigned >>>>>>>>>>>>>> long)+0x2c3 >>>>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>>>>>>>> __va_list_tag*)+0x2f >>>>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, >>>>>>>>>>>>>> char const*, char const*, ...)+0x100 >>>>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>> V ?[libjvm.so+0x119af99] >>>>>>>>>>>>>> ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>> >>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, >>>>>>>>>>>>>> mode: safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>> >>>>> >> From serguei.spitsyn at oracle.com Wed Oct 24 09:00:37 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Oct 2018 02:00:37 -0700 Subject: The failure In-Reply-To: <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> Message-ID: <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> Hi Robbin and David, There is no JvmtiEnv::SuspendThreadList call in the dumped stack traces. But there is an instance of the JvmtiEnv::SuspendThread which seems to be supporting your theory: Thread 136 (Thread 0x2ae494100700 (LWP 28023)): #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1? 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae454005800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 #2? 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 #3? Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 #4? 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 #5? 0x00002ae393de7867 in VMThread::execute (op=op at entry=0x2ae4940ffb10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 #6? 0x00002ae393d6a3bd in JavaThread::java_suspend (this=this at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 #7? 0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend (java_thread=java_thread at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:847 #8? 0x00002ae3939887ae in JvmtiEnv::SuspendThread (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:955 #9? 0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, thread=0x2ae49929fdf8) at /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:527 #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, env=, p=) at /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:274 #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 #13 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 The JavaThread::suspend() call from the stack trace above also holds a ThreadsListHandle while executing VMThread::execute(&vm_suspend): void JavaThread::java_suspend() { ? ThreadsListHandle tlh; ? if (!tlh.includes(this) || threadObj() == NULL || is_exiting()) { ??? return; ? } ? { MutexLockerEx ml(SR_lock(), Mutex::_no_safepoint_check_flag); ??? if (!is_external_suspend()) { ????? // a racing resume has cancelled us; bail out now ????? return; ??? } ??? // suspend is done ??? uint32_t debug_bits = 0; ??? // Warning: is_ext_suspend_completed() may temporarily drop the ??? // SR_lock to allow the thread to reach a stable thread state if ??? // it is currently in a transient thread state. ??? if (is_ext_suspend_completed(false /* !called_by_wait */, ???????????????????????????????? SuspendRetryDelay, &debug_bits)) { ????? return; ??? } ? } ? VM_ThreadSuspend vm_suspend; ? VMThread::execute(&vm_suspend); } I'll check with Leonid tomorrow if we can check if your patch below can fix this deadlock. Thanks, Serguei On 10/24/18 00:18, Robbin Ehn wrote: > Hi, truncate: > > On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>> One thing I noticed which Robbin should be able to expand upon is >>>> that Thread 101 is terminating and has called >>>> ThreadsSMRSupport::smr_delete and is blocked here: >>>> >>>> ??// Wait for a release_stable_list() call before we check again. No >>>> ??// safepoint check, no timeout, and not as suspend equivalent flag >>>> ??// because this JavaThread is not on the Threads list. >>>> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>> >>>> ???????????????????????????????????????? 0, >>>> !Mutex::_as_suspend_equivalent_flag); >>>> >>>> As the comment says this thread is no longer on the Threads_list, >>>> but the VM_HandshakeAllThreads is not a safepoint operation and >>>> does not hold the Threads_lock, so is it possible this thread was >>>> captured by the JavaThreadIteratorWithHandle being used by >>>> VM_HandshakeAllThreads, before it got removed? If so we'd be hung >>>> waiting it for it handshake as it's not in a "safepoint-safe" or >>>> suspend-equivalent state. > > In short: > # VM Thread > VM Thread is in a loop, takes Threads_lock, takes a new snapshot of > the Threads_list, scans the list and process handshakes on behalf of > safe threads. > Releases snapshot and Threads_lock and checks if all handshakes are > completed > > # An exiting thread > A thread exiting thread removes it self from _THE_ threads list, but > must stick around if it is on any snapshots of alive. When it is no on > any list it will cancel the handshake. > > Since VM thread during the handshake takes a new snapshot every > iteration any exiting can proceed since it will not be a the new > snapshot. Thus cancel the handshake and VM thread can exit the loop > (if this was the last handshake). > > Constraint: > If any thread grabs a snapshot of threads list and later tries to take > a lock which is 'used' by VM Thread or inside the handshake we can > deadlock. > > Considering that looking at e.g. : JvmtiEnv::SuspendThreadList > Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, > this could deadlock AFAICT. Since the thread will rest on > VMOperationRequest_lock with a Threads list snapshot but VM thread > cannot finishes handshake until that snapshot is released. > > I suggest first step is to add something like this patch below and fix > the obvious ones first. > > Note, I have not verified that is the problem you are seeing, I'm > saying that this seem to be real issue. And considering how the stack > traces looks, it may be this. > > You want me going through this, just assign a bug if there is one? > > /Robbin > > diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp > --- a/src/hotspot/share/runtime/thread.hpp??? Tue Oct 23 13:27:41 2018 > +0200 > +++ b/src/hotspot/share/runtime/thread.hpp??? Wed Oct 24 09:13:17 2018 > +0200 > @@ -167,2 +167,6 @@ > ?? } > + public: > +? bool have_threads_list(); > + private: > + > ?? // This field is enabled via -XX:+EnableThreadSMRStatistics: > diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp > --- a/src/hotspot/share/runtime/thread.inline.hpp??? Tue Oct 23 > 13:27:41 2018 +0200 > +++ b/src/hotspot/share/runtime/thread.inline.hpp??? Wed Oct 24 > 09:13:17 2018 +0200 > @@ -111,2 +111,6 @@ > > +inline bool Thread::have_threads_list() { > +? return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; > +} > + > ?inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { > diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp > --- a/src/hotspot/share/runtime/vmThread.cpp??? Tue Oct 23 13:27:41 > 2018 +0200 > +++ b/src/hotspot/share/runtime/vmThread.cpp??? Wed Oct 24 09:13:17 > 2018 +0200 > @@ -608,2 +608,3 @@ > ?? if (!t->is_VM_thread()) { > +??? assert(t->have_threads_list(), "Deadlock if we have exiting > threads and if vm thread is running an VM op."); // fatal/guarantee > ???? SkipGCALot sgcalot(t);??? // avoid re-entrant attempts to gc-a-lot > > > > > >>>> >>>> David >>>> ----- >>>> >>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>> Please, skip it - sorry for the noise. >>>>> It is hard to prove anything with current dump. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David and Robbin, >>>>>> >>>>>> I have an idea that needs to be checked. >>>>>> It can be almost the same deadlock scenario that I've already >>>>>> explained but more sophisticated. >>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>>>> Monitor::_safepoint_check_always does not help much. >>>>>> It can be verified by checking what monitors are used by the >>>>>> blocked threads. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>> Hi, >>>>>>> >>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>>>>>> safepoint operation. There's no real way to tell from the >>>>>>>> stacks what it's stuck on. >>>>>>> >>>>>>> I cannot find a thread that is not considered safepoint safe or >>>>>>> is_ext_suspended (thread 146). So the handshake should go >>>>>>> through. The handshake will log a warning after a while, is >>>>>>> there such warning from the handshake operation? >>>>>>> >>>>>>> There are several threads competing with e.g. Threads_lock, and >>>>>>> threads waiting for GC and several other VM ops, could it just >>>>>>> be really slow? >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> You are right, thanks. >>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint >>>>>>>>>> checks enabled, so all JavaThreads blocked trying to acquire >>>>>>>>>> it will be _thread_blocked and so safepoint-safe and so won't >>>>>>>>>> be holding up the safepoint. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> Seems last version also crashes with 2 other different >>>>>>>>>>>> symptoms. >>>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test >>>>>>>>>>>> might be blocked because it invoke 2 jvmti methods. Can >>>>>>>>>>>> jvmti agent invoke jvmti methods from different threads? >>>>>>>>>>> >>>>>>>>>>> Yes, in general. >>>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>>> Below, one thread is enabling single stepping while another >>>>>>>>>>> thread is being suspended. >>>>>>>>>>> Both are blocked at a safepoint which is Okay in general but >>>>>>>>>>> not Okay if they hold any lock. >>>>>>>>>>> For instance, the thread #152 is holding the monitor >>>>>>>>>>> JvmtiThreadState. >>>>>>>>>>> >>>>>>>>>>> Also, I see a couple of more threads that are interesting as >>>>>>>>>>> well: >>>>>>>>>>> >>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>> >>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>> ev=0x2ae3984c9100) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>> >>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, >>>>>>>>>>> Self=0x2ae3984c7800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>> >>>>>>>>>>> #4? 0x00002ae393b512c1 in lock >>>>>>>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) >>>>>>>>>>> at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>> >>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>> >>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>> this=) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>> >>>>>>>>>>> #7? ciEnv::cache_jvmti_state >>>>>>>>>>> (this=this at entry=0x2ae40b78eb30) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>> >>>>>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>> >>>>>>>>>>> #9? 0x00002ae3935d4f48 in >>>>>>>>>>> CompileBroker::compiler_thread_loop () at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>> >>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>> >>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>> (this=0x2ae3984c7800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>> >>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>> >>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>> >>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>> ev=0x2ae3984cbb00) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>> >>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, >>>>>>>>>>> Self=0x2ae3984ca800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>> >>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>> >>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>> >>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>> this=) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>> >>>>>>>>>>> #7? ciEnv::cache_jvmti_state >>>>>>>>>>> (this=this at entry=0x2ae40b88fb30) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>> >>>>>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>> >>>>>>>>>>> #9? 0x00002ae3935d4f48 in >>>>>>>>>>> CompileBroker::compiler_thread_loop () at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>> >>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>> >>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>> (this=0x2ae3984ca800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>> >>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>> >>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>> >>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>> ev=0x2ae460061c00) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>> >>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, >>>>>>>>>>> Self=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>> >>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>> >>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>> >>>>>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>> this=) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>> >>>>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>>> >>>>>>>>>>> #8? JvmtiEventController::thread_started >>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>>> >>>>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>>> >>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run >>>>>>>>>>> (this=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>>> >>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> These two thread are blocked on the monitor >>>>>>>>>>> JvmtiThreadState_lock in the function >>>>>>>>>>> ciEnv::cache_jvmti_state(). >>>>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>>>>> safepoint is waiting for? >>>>>>>>>>> >>>>>>>>>>> I think, this safepoint operation is waiting for all threads >>>>>>>>>>> that are blocked on the JvmtiThreadState_lock. >>>>>>>>>>> >>>>>>>>>>> Conclusion: >>>>>>>>>>> >>>>>>>>>>> The deadlock is: >>>>>>>>>>> >>>>>>>>>>> Thread #152: >>>>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>> >>>>>>>>>>> Many other threads: >>>>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>> ?? - can not reach the blocked at a safepoint state (all >>>>>>>>>>> threads have to reach this state for this safepoint to happen) >>>>>>>>>>> >>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>> >>>>>>>>>>> My guess is that this will stop to reproduce after if you >>>>>>>>>>> turn off the single stepping for thread #152. >>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make >>>>>>>>>>>> sense to integrate jvmti changes but *don't* enabled jvmti >>>>>>>>>>>> module by default. >>>>>>>>>>> >>>>>>>>>>> This one is a deadlock. >>>>>>>>>>> However, the root cause is a race condition that can >>>>>>>>>>> potentially result in both deadlocks and crashes. >>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>> So anyone could easily run them to reproduce crashes. ?This >>>>>>>>>>>> test would be out of CI to don't introduce any bugs. Does >>>>>>>>>>>> it make sense? >>>>>>>>>>>> >>>>>>>>>>>> Consider hang - I think that it might be product bug since >>>>>>>>>>>> I don't see any locking on my monitors. But I am not sure. >>>>>>>>>>>> Is it possible that any my code jvmti agent prevent VM to >>>>>>>>>>>> get into safepoint? >>>>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>>>> >>>>>>>>>>> Yes, of course. >>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>> >>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>> It is non-trivial in this particular case as there are so >>>>>>>>>>> many threads executed at the same time. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>> >>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>>>>> ev=0x2ae454005800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>> >>>>>>>>>>>> 8 >>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>> (this=this at entry=0x2ae398023c10, >>>>>>>>>>>> no_safepoint_check=, >>>>>>>>>>>> timeout=timeout at entry=0, >>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>> try=false) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>> >>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>> >>>>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>>> >>>>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>>> >>>>>>>>>>>> 47 >>>>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>>>> (this=this at entry=0x2ae39801b270, >>>>>>>>>>>> java_thread=0x2ae3985f2000) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>> >>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>>>>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>>> >>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler >>>>>>>>>>>> (jvmti=0x2ae39801b270, env=, p=>>>>>>>>>>> out>) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>>> >>>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>>> >>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>>> >>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>> >>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>> >>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> >>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>>>>> ev=0x2ae3985e7400) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>> >>>>>>>>>>>> 8 >>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>> (this=this at entry=0x2ae398023c10, >>>>>>>>>>>> no_safepoint_check=, >>>>>>>>>>>> timeout=timeout at entry=0, >>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>> try=false) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>> >>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>> (op=0x2ae42705f500) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>> >>>>>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>>>> ue) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>>> >>>>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>>> >>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>>> >>>>>>>>>>>> :523 >>>>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>>>>>>> env=0x2ae39801b270) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled >>>>>>>>>>>> (env=0x2ae39801b270, thread=0x0, >>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>>>>>>>>>>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>> #12 0x00002ae393987d2d in >>>>>>>>>>>> JvmtiEnv::SetEventNotificationMode >>>>>>>>>>>> (this=this at entry=0x2ae39801b270, >>>>>>>>>>>> mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>>> >>>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>> event_thread=event_\ >>>>>>>>>>>> thread at entry=0x0) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>>> >>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>>> >>>>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>>>> (env=, this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/h\ >>>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>>> >>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Leonid >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>> >>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>> Hi >>>>>>>>>>>>>> >>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> # >>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>>>>> Environment: >>>>>>>>>>>>>> # >>>>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>> # >>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>>>>>>>> (fastdebug build >>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, >>>>>>>>>>>>>> mixed mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>> # Core dump will be written. Default location: Core dumps >>>>>>>>>>>>>> may be processed with "/usr/libexec/abrt-hook-ccpp %s %c >>>>>>>>>>>>>> %p %u %g %t e %P %I %h" (or dumping to >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>>> >>>>>>>>>>>>>> # >>>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>> # >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 >>>>>>>>>>>>>> -XX:MaxRAMPercentage=50 -XX:+CrashOnOutOfMemoryError >>>>>>>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>>>>> -XX:+FlightRecorder >>>>>>>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Host: scaaa118.us.oracle.com >>>>>>>>>>>>>> , Intel(R) Xeon(R) CPU >>>>>>>>>>>>>> E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux Server >>>>>>>>>>>>>> release 7.3 >>>>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 >>>>>>>>>>>>>> seconds (0d 0h 0m 31s) >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM >>>>>>>>>>>>>> Thread" [stack: 0x00002af44f10a000,0x00002af44f20a000] >>>>>>>>>>>>>> [id=13962] _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java >>>>>>>>>>>>>> code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, >>>>>>>>>>>>>> char const*, char const*, __va_list_tag*, Thread*, >>>>>>>>>>>>>> unsigned char*, void*, void*, char const*, int, unsigned >>>>>>>>>>>>>> long)+0x2c3 >>>>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] >>>>>>>>>>>>>> ?VMError::report_and_die(Thread*, void*, char const*, >>>>>>>>>>>>>> int, char const*, char const*, __va_list_tag*)+0x2f >>>>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, >>>>>>>>>>>>>> int, char const*, char const*, ...)+0x100 >>>>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>> V ?[libjvm.so+0x119af99] >>>>>>>>>>>>>> ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>> >>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, >>>>>>>>>>>>>> mode: safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>> >>>>> >> From robbin.ehn at oracle.com Wed Oct 24 09:10:20 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 24 Oct 2018 11:10:20 +0200 Subject: The failure In-Reply-To: <1796f4d0-eda7-8b96-6b14-ab68ebfcd2d1@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> <1796f4d0-eda7-8b96-6b14-ab68ebfcd2d1@oracle.com> Message-ID: On 24/10/2018 09:46, David Holmes wrote: > Thanks Robbin! So you're no allowed to request a VM operation if you hold a > ThreadsListHandle ? I suppose that is no different to not being able to request > a VM operation whilst holding the Threads_lock. Yes, exactly. /Robbin > > I suspect before ThreadSMR this may have been a case where we weren't ensuring a > target thread could not terminate, and now with SMR we're ensuring that but > potentially introducing a deadlock. I say potentially because obviously we don't > deadlock every time we suspend threads. > > Cheers, > David > > On 24/10/2018 5:18 PM, Robbin Ehn wrote: >> Hi, truncate: >> >> On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>>> One thing I noticed which Robbin should be able to expand upon is that >>>>> Thread 101 is terminating and has called ThreadsSMRSupport::smr_delete and >>>>> is blocked here: >>>>> >>>>> ??// Wait for a release_stable_list() call before we check again. No >>>>> ??// safepoint check, no timeout, and not as suspend equivalent flag >>>>> ??// because this JavaThread is not on the Threads list. >>>>> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>> ???????????????????????????????????????? 0, >>>>> !Mutex::_as_suspend_equivalent_flag); >>>>> >>>>> As the comment says this thread is no longer on the Threads_list, but the >>>>> VM_HandshakeAllThreads is not a safepoint operation and does not hold the >>>>> Threads_lock, so is it possible this thread was captured by the >>>>> JavaThreadIteratorWithHandle being used by VM_HandshakeAllThreads, before >>>>> it got removed? If so we'd be hung waiting it for it handshake as it's not >>>>> in a "safepoint-safe" or suspend-equivalent state. >> >> In short: >> # VM Thread >> VM Thread is in a loop, takes Threads_lock, takes a new snapshot of the >> Threads_list, scans the list and process handshakes on behalf of safe threads. >> Releases snapshot and Threads_lock and checks if all handshakes are completed >> >> # An exiting thread >> A thread exiting thread removes it self from _THE_ threads list, but must >> stick around if it is on any snapshots of alive. When it is no on any list it >> will cancel the handshake. >> >> Since VM thread during the handshake takes a new snapshot every iteration any >> exiting can proceed since it will not be a the new snapshot. Thus cancel the >> handshake and VM thread can exit the loop (if this was the last handshake). >> >> Constraint: >> If any thread grabs a snapshot of threads list and later tries to take a lock >> which is 'used' by VM Thread or inside the handshake we can deadlock. >> >> Considering that looking at e.g. : JvmtiEnv::SuspendThreadList >> Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, this >> could deadlock AFAICT. Since the thread will rest on VMOperationRequest_lock >> with a Threads list snapshot but VM thread cannot finishes handshake until >> that snapshot is released. >> >> I suggest first step is to add something like this patch below and fix the >> obvious ones first. >> >> Note, I have not verified that is the problem you are seeing, I'm saying that >> this seem to be real issue. And considering how the stack traces looks, it may >> be this. >> >> You want me going through this, just assign a bug if there is one? >> >> /Robbin >> >> diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp >> --- a/src/hotspot/share/runtime/thread.hpp??? Tue Oct 23 13:27:41 2018 +0200 >> +++ b/src/hotspot/share/runtime/thread.hpp??? Wed Oct 24 09:13:17 2018 +0200 >> @@ -167,2 +167,6 @@ >> ??? } >> + public: >> +? bool have_threads_list(); >> + private: >> + >> ??? // This field is enabled via -XX:+EnableThreadSMRStatistics: >> diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp >> --- a/src/hotspot/share/runtime/thread.inline.hpp??? Tue Oct 23 13:27:41 2018 >> +0200 >> +++ b/src/hotspot/share/runtime/thread.inline.hpp??? Wed Oct 24 09:13:17 2018 >> +0200 >> @@ -111,2 +111,6 @@ >> >> +inline bool Thread::have_threads_list() { >> +? return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; >> +} >> + >> ??inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { >> diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp >> --- a/src/hotspot/share/runtime/vmThread.cpp??? Tue Oct 23 13:27:41 2018 +0200 >> +++ b/src/hotspot/share/runtime/vmThread.cpp??? Wed Oct 24 09:13:17 2018 +0200 >> @@ -608,2 +608,3 @@ >> ??? if (!t->is_VM_thread()) { >> +??? assert(t->have_threads_list(), "Deadlock if we have exiting threads and >> if vm thread is running an VM op."); // fatal/guarantee >> ????? SkipGCALot sgcalot(t);??? // avoid re-entrant attempts to gc-a-lot >> >> >> >> >> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, skip it - sorry for the noise. >>>>>> It is hard to prove anything with current dump. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi David and Robbin, >>>>>>> >>>>>>> I have an idea that needs to be checked. >>>>>>> It can be almost the same deadlock scenario that I've already explained >>>>>>> but more sophisticated. >>>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>>>>> Monitor::_safepoint_check_always does not help much. >>>>>>> It can be verified by checking what monitors are used by the blocked >>>>>>> threads. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>>>>>>> safepoint operation. There's no real way to tell from the stacks what >>>>>>>>> it's stuck on. >>>>>>>> >>>>>>>> I cannot find a thread that is not considered safepoint safe or >>>>>>>> is_ext_suspended (thread 146). So the handshake should go through. The >>>>>>>> handshake will log a warning after a while, is there such warning from >>>>>>>> the handshake operation? >>>>>>>> >>>>>>>> There are several threads competing with e.g. Threads_lock, and threads >>>>>>>> waiting for GC and several other VM ops, could it just be really slow? >>>>>>>> >>>>>>>> /Robbin >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> You are right, thanks. >>>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>>>>>>>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>>>>>>>>> _thread_blocked and so safepoint-safe and so won't be holding up the >>>>>>>>>>> safepoint. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test might be >>>>>>>>>>>>> blocked because it invoke 2 jvmti methods. Can jvmti agent invoke >>>>>>>>>>>>> jvmti methods from different threads? >>>>>>>>>>>> >>>>>>>>>>>> Yes, in general. >>>>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>>>> Below, one thread is enabling single stepping while another thread >>>>>>>>>>>> is being suspended. >>>>>>>>>>>> Both are blocked at a safepoint which is Okay in general but not >>>>>>>>>>>> Okay if they hold any lock. >>>>>>>>>>>> For instance, the thread #152 is holding the monitor JvmtiThreadState. >>>>>>>>>>>> >>>>>>>>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>>>>>>>> >>>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984c7is_ext_suspended800, >>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>> this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>> >>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> >>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>> this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>> >>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> >>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>> this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>>>> >>>>>>>>>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> >>>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> These two thread are blocked on the monitor JvmtiThreadState_lock in >>>>>>>>>>>> the function ciEnv::cache_jvmti_state(). >>>>>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>>>>>> safepoint is waiting for? >>>>>>>>>>>> >>>>>>>>>>>> I think, this safepoint operation is waiting for all threads that >>>>>>>>>>>> are blocked on the JvmtiThreadState_lock. >>>>>>>>>>>> >>>>>>>>>>>> Conclusion: >>>>>>>>>>>> >>>>>>>>>>>> The deadlock is: >>>>>>>>>>>> >>>>>>>>>>>> Thread #152: >>>>>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>>> >>>>>>>>>>>> Many other threads: >>>>>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>>>>>>>>> have to reach this state for this safepoint to happen) >>>>>>>>>>>> >>>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>>> >>>>>>>>>>>> My guess is that this will stop to reproduce after if you turn off >>>>>>>>>>>> the single stepping for thread #152. >>>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>>>>>>>>> integrate jvmti changes but *don't* enabled jvmti module by default. >>>>>>>>>>>> >>>>>>>>>>>> This one is a deadlock. >>>>>>>>>>>> However, the root cause is a race condition that can potentially >>>>>>>>>>>> result in both deadlocks and crashes. >>>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>>>>>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>>>>>>>>> >>>>>>>>>>>>> Consider hang - I think that it might be product bug since I don't >>>>>>>>>>>>> see any locking on my monitors. But I am not sure. Is it possible >>>>>>>>>>>>> that any my code jvmti agent prevent VM to get into safepoint? >>>>>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>>>>> >>>>>>>>>>>> Yes, of course. >>>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>>> >>>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>>> It is non-trivial in this particular case as there are so many >>>>>>>>>>>> threads executed at the same time. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>> >>>>>>>>>>>>> 8 >>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>> try=false) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>> >>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>> >>>>>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>>>> >>>>>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>>>> >>>>>>>>>>>>> 47 >>>>>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >>>>>>>>>>>>> thread=0x2ae49929fdf8) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>>>> >>>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>>>>>>>>> env=, p=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>>>> >>>>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) >>>>>>>>>>>>> at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>> >>>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>> >>>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>> >>>>>>>>>>>>> 8 >>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>> try=false) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>> >>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>> >>>>>>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>>>>> ue) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>>>> >>>>>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>>>> >>>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>>>> >>>>>>>>>>>>> :523 >>>>>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) >>>>>>>>>>>>> at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>>>>>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>>>>>>>>>>>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>> event_thread=event_\ >>>>>>>>>>>>> thread at entry=0x0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>>>> >>>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>>>> >>>>>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>>>>> (env=, this=) at /scratch/lmesnik/ws/h\ >>>>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>>>> >>>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Leonid >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug >>>>>>>>>>>>>>> build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, >>>>>>>>>>>>>>> tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>>> # Core dump will be written. Default location: Core dumps may be >>>>>>>>>>>>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e >>>>>>>>>>>>>>> %P %I %h" (or dumping to >>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>>>>>>>>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false >>>>>>>>>>>>>>> -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>>>>>> -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>>>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >>>>>>>>>>>>>>> Linux Server release 7.3 >>>>>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d >>>>>>>>>>>>>>> 0h 0m 31s) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>>>>>>>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>>>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>>>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, void*, >>>>>>>>>>>>>>> char const*, int, char const*, char const*, __va_list_tag*)+0x2f >>>>>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>>>>>>>>>>>> const*, char const*, ...)+0x100 >>>>>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>>>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>> From robbin.ehn at oracle.com Wed Oct 24 09:18:32 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 24 Oct 2018 11:18:32 +0200 Subject: The failure In-Reply-To: <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> Message-ID: <12382d41-fbc6-f352-b162-3eaf67a97601@oracle.com> Hi Serguei, On 24/10/2018 11:00, serguei.spitsyn at oracle.com wrote: > Hi Robbin and David, > > There is no JvmtiEnv::SuspendThreadList call in the dumped stack traces. > But there is an instance of the JvmtiEnv::SuspendThread which seems to be > supporting your theory: Sorry, I did mean any place we take a ThreadsListHandle and call ::execute with that handle still alive. That was just first one I saw and used it as an example. > void JavaThread::java_suspend() { You are correct in this particular case it seems to be this one, but we must fix _all_ of them. That why I suggested adding the assert. And maybe an additional assert in Mutex on having a threadslist while locking the Threads_lock. > I'll check with Leonid tomorrow if we can check if your patch below can fix this > deadlock. It wouldn't fix the deadlock it would assert, so we still need to locate and fix all the places. Maybe it's just a couple. /Robbin > > Thanks, > Serguei > > > On 10/24/18 00:18, Robbin Ehn wrote: >> Hi, truncate: >> >> On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>>> One thing I noticed which Robbin should be able to expand upon is that >>>>> Thread 101 is terminating and has called ThreadsSMRSupport::smr_delete and >>>>> is blocked here: >>>>> >>>>> ??// Wait for a release_stable_list() call before we check again. No >>>>> ??// safepoint check, no timeout, and not as suspend equivalent flag >>>>> ??// because this JavaThread is not on the Threads list. >>>>> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>> ???????????????????????????????????????? 0, >>>>> !Mutex::_as_suspend_equivalent_flag); >>>>> >>>>> As the comment says this thread is no longer on the Threads_list, but the >>>>> VM_HandshakeAllThreads is not a safepoint operation and does not hold the >>>>> Threads_lock, so is it possible this thread was captured by the >>>>> JavaThreadIteratorWithHandle being used by VM_HandshakeAllThreads, before >>>>> it got removed? If so we'd be hung waiting it for it handshake as it's not >>>>> in a "safepoint-safe" or suspend-equivalent state. >> >> In short: >> # VM Thread >> VM Thread is in a loop, takes Threads_lock, takes a new snapshot of the >> Threads_list, scans the list and process handshakes on behalf of safe threads. >> Releases snapshot and Threads_lock and checks if all handshakes are completed >> >> # An exiting thread >> A thread exiting thread removes it self from _THE_ threads list, but must >> stick around if it is on any snapshots of alive. When it is no on any list it >> will cancel the handshake. >> >> Since VM thread during the handshake takes a new snapshot every iteration any >> exiting can proceed since it will not be a the new snapshot. Thus cancel the >> handshake and VM thread can exit the loop (if this was the last handshake). >> >> Constraint: >> If any thread grabs a snapshot of threads list and later tries to take a lock >> which is 'used' by VM Thread or inside the handshake we can deadlock. >> >> Considering that looking at e.g. : JvmtiEnv::SuspendThreadList >> Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, this >> could deadlock AFAICT. Since the thread will rest on VMOperationRequest_lock >> with a Threads list snapshot but VM thread cannot finishes handshake until >> that snapshot is released. >> >> I suggest first step is to add something like this patch below and fix the >> obvious ones first. >> >> Note, I have not verified that is the problem you are seeing, I'm saying that >> this seem to be real issue. And considering how the stack traces looks, it may >> be this. >> >> You want me going through this, just assign a bug if there is one? >> >> /Robbin >> >> diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp >> --- a/src/hotspot/share/runtime/thread.hpp??? Tue Oct 23 13:27:41 2018 +0200 >> +++ b/src/hotspot/share/runtime/thread.hpp??? Wed Oct 24 09:13:17 2018 +0200 >> @@ -167,2 +167,6 @@ >> ?? } >> + public: >> +? bool have_threads_list(); >> + private: >> + >> ?? // This field is enabled via -XX:+EnableThreadSMRStatistics: >> diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp >> --- a/src/hotspot/share/runtime/thread.inline.hpp??? Tue Oct 23 13:27:41 2018 >> +0200 >> +++ b/src/hotspot/share/runtime/thread.inline.hpp??? Wed Oct 24 09:13:17 2018 >> +0200 >> @@ -111,2 +111,6 @@ >> >> +inline bool Thread::have_threads_list() { >> +? return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; >> +} >> + >> ?inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { >> diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp >> --- a/src/hotspot/share/runtime/vmThread.cpp??? Tue Oct 23 13:27:41 2018 +0200 >> +++ b/src/hotspot/share/runtime/vmThread.cpp??? Wed Oct 24 09:13:17 2018 +0200 >> @@ -608,2 +608,3 @@ >> ?? if (!t->is_VM_thread()) { >> +??? assert(t->have_threads_list(), "Deadlock if we have exiting threads and >> if vm thread is running an VM op."); // fatal/guarantee >> ???? SkipGCALot sgcalot(t);??? // avoid re-entrant attempts to gc-a-lot >> >> >> >> >> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, skip it - sorry for the noise. >>>>>> It is hard to prove anything with current dump. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi David and Robbin, >>>>>>> >>>>>>> I have an idea that needs to be checked. >>>>>>> It can be almost the same deadlock scenario that I've already explained >>>>>>> but more sophisticated. >>>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>>>>> Monitor::_safepoint_check_always does not help much. >>>>>>> It can be verified by checking what monitors are used by the blocked >>>>>>> threads. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>>>>>>> safepoint operation. There's no real way to tell from the stacks what >>>>>>>>> it's stuck on. >>>>>>>> >>>>>>>> I cannot find a thread that is not considered safepoint safe or >>>>>>>> is_ext_suspended (thread 146). So the handshake should go through. The >>>>>>>> handshake will log a warning after a while, is there such warning from >>>>>>>> the handshake operation? >>>>>>>> >>>>>>>> There are several threads competing with e.g. Threads_lock, and threads >>>>>>>> waiting for GC and several other VM ops, could it just be really slow? >>>>>>>> >>>>>>>> /Robbin >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> You are right, thanks. >>>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>>>>>>>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>>>>>>>>> _thread_blocked and so safepoint-safe and so won't be holding up the >>>>>>>>>>> safepoint. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test might be >>>>>>>>>>>>> blocked because it invoke 2 jvmti methods. Can jvmti agent invoke >>>>>>>>>>>>> jvmti methods from different threads? >>>>>>>>>>>> >>>>>>>>>>>> Yes, in general. >>>>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>>>> Below, one thread is enabling single stepping while another thread >>>>>>>>>>>> is being suspended. >>>>>>>>>>>> Both are blocked at a safepoint which is Okay in general but not >>>>>>>>>>>> Okay if they hold any lock. >>>>>>>>>>>> For instance, the thread #152 is holding the monitor JvmtiThreadState. >>>>>>>>>>>> >>>>>>>>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>>>>>>>> >>>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984c7is_ext_suspended800, >>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>> this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>> >>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> >>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>> this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>> >>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> >>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>> this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>>>> >>>>>>>>>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> >>>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> These two thread are blocked on the monitor JvmtiThreadState_lock in >>>>>>>>>>>> the function ciEnv::cache_jvmti_state(). >>>>>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>>>>>> safepoint is waiting for? >>>>>>>>>>>> >>>>>>>>>>>> I think, this safepoint operation is waiting for all threads that >>>>>>>>>>>> are blocked on the JvmtiThreadState_lock. >>>>>>>>>>>> >>>>>>>>>>>> Conclusion: >>>>>>>>>>>> >>>>>>>>>>>> The deadlock is: >>>>>>>>>>>> >>>>>>>>>>>> Thread #152: >>>>>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>>> >>>>>>>>>>>> Many other threads: >>>>>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>>>>>>>>> have to reach this state for this safepoint to happen) >>>>>>>>>>>> >>>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>>> >>>>>>>>>>>> My guess is that this will stop to reproduce after if you turn off >>>>>>>>>>>> the single stepping for thread #152. >>>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>>>>>>>>> integrate jvmti changes but *don't* enabled jvmti module by default. >>>>>>>>>>>> >>>>>>>>>>>> This one is a deadlock. >>>>>>>>>>>> However, the root cause is a race condition that can potentially >>>>>>>>>>>> result in both deadlocks and crashes. >>>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>>>>>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>>>>>>>>> >>>>>>>>>>>>> Consider hang - I think that it might be product bug since I don't >>>>>>>>>>>>> see any locking on my monitors. But I am not sure. Is it possible >>>>>>>>>>>>> that any my code jvmti agent prevent VM to get into safepoint? >>>>>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>>>>> >>>>>>>>>>>> Yes, of course. >>>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>>> >>>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>>> It is non-trivial in this particular case as there are so many >>>>>>>>>>>> threads executed at the same time. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>> >>>>>>>>>>>>> 8 >>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>> try=false) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>> >>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>> >>>>>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>>>> >>>>>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>>>> >>>>>>>>>>>>> 47 >>>>>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >>>>>>>>>>>>> thread=0x2ae49929fdf8) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>>>> >>>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>>>>>>>>> env=, p=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>>>> >>>>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) >>>>>>>>>>>>> at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>> >>>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>> >>>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>> >>>>>>>>>>>>> 8 >>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>> try=false) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>> >>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>> >>>>>>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>>>>> ue) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>>>> >>>>>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>>>> >>>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>>>> >>>>>>>>>>>>> :523 >>>>>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) >>>>>>>>>>>>> at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>>>>>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>>>>>>>>>>>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>> event_thread=event_\ >>>>>>>>>>>>> thread at entry=0x0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>>>> >>>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>>>> >>>>>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>>>>> (env=, this=) at /scratch/lmesnik/ws/h\ >>>>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>>>> >>>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Leonid >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug >>>>>>>>>>>>>>> build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, >>>>>>>>>>>>>>> tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>>> # Core dump will be written. Default location: Core dumps may be >>>>>>>>>>>>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e >>>>>>>>>>>>>>> %P %I %h" (or dumping to >>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>>>>>>>>> -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false >>>>>>>>>>>>>>> -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>>>>>> -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>>>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >>>>>>>>>>>>>>> Linux Server release 7.3 >>>>>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d >>>>>>>>>>>>>>> 0h 0m 31s) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>>>>>>>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>>>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>>>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, void*, >>>>>>>>>>>>>>> char const*, int, char const*, char const*, __va_list_tag*)+0x2f >>>>>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>>>>>>>>>>>> const*, char const*, ...)+0x100 >>>>>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>>>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>> > From thomas.schatzl at oracle.com Wed Oct 24 09:57:37 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 24 Oct 2018 11:57:37 +0200 Subject: RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: <208c3313a6ce24a97d121abf718b0b9dbf6ab023.camel@oracle.com> References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> <208c3313a6ce24a97d121abf718b0b9dbf6ab023.camel@oracle.com> Message-ID: <51c03ea06f29f1f22235c1a9ebb95e81820bb180.camel@oracle.com> Hi again, On Tue, 2018-10-23 at 15:37 +0200, Thomas Schatzl wrote: > Hi Paul, > > sorry for the long wait. > > On Mon, 2018-10-08 at 23:49 +0000, Hohensee, Paul wrote: > > 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/ > > Note that I reviewed the latest change at > > http://cr.openjdk.java.net/~phh/8196989/webrev.04/ > > Currently pushing this through our testing. There are several failures that I think can be directly attributed to this change: jdk tests (run jtreg from test/jdk) com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotification Test.java: "notifications have not been sent for java.lang:name=G1 Mixed, type=GarbageCollector" com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotification ContentTest.java: fails with a NullPointerException I can reproduce these two locally when running without any additional options. They seem to only occur with G1. hotspot tests (run jtreg from test/hotspot) java/lang/management/MemoryMXBean/MemoryTest.java: "Number of heap pools = 3, but expected 5" Note that the test may be called with other collectors than G1 from outside, just not with ZGC as per the @requires tag, i.e. with -vmoption:-XX:+UseParallelGC. Thanks, Thomas From thomas.schatzl at oracle.com Wed Oct 24 10:39:21 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 24 Oct 2018 12:39:21 +0200 Subject: RFR: 8196989: Revamp G1 JMX MemoryPool and GarbageCollector MXBean definitions In-Reply-To: <51c03ea06f29f1f22235c1a9ebb95e81820bb180.camel@oracle.com> References: <8C241BB9-2089-491B-A27E-57C4F43FBA9E@amazon.com> <208c3313a6ce24a97d121abf718b0b9dbf6ab023.camel@oracle.com> <51c03ea06f29f1f22235c1a9ebb95e81820bb180.camel@oracle.com> Message-ID: Hi, On Wed, 2018-10-24 at 11:57 +0200, Thomas Schatzl wrote: > Hi again, > > On Tue, 2018-10-23 at 15:37 +0200, Thomas Schatzl wrote: > > Hi Paul, > > > > sorry for the long wait. > > > > On Mon, 2018-10-08 at 23:49 +0000, Hohensee, Paul wrote: > > > 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/ > > > > Note that I reviewed the latest change at > > > > http://cr.openjdk.java.net/~phh/8196989/webrev.04/ > > > > Currently pushing this through our testing. > > There are several failures that I think can be directly attributed to > this change: > > jdk tests (run jtreg from test/jdk) > > com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificati > onTest.java: "notifications have not been sent for java.lang:name=G1 > Mixed, type=GarbageCollector" > com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificati > onContentTest.java: fails with a NullPointerException > > I can reproduce these two locally when running without any additional > options. They seem to only occur with G1. > > hotspot tests (run jtreg from test/hotspot) > > java/lang/management/MemoryMXBean/MemoryTest.java: "Number of heap > pools = 3, but expected 5" > > Note that the test may be called with other collectors than G1 from > outside, just not with ZGC as per the @requires tag, i.e. with > -vmoption:-XX:+UseParallelGC. Also vmTestbase/nsk/monitoring/MemoryNotificationInfo/from/from001/TestDescr iption.java from the same location starts to time out with the changes. Thanks, Thomas From robbin.ehn at oracle.com Wed Oct 24 10:45:41 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 24 Oct 2018 12:45:41 +0200 Subject: The failure In-Reply-To: <12382d41-fbc6-f352-b162-3eaf67a97601@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> <12382d41-fbc6-f352-b162-3eaf67a97601@oracle.com> Message-ID: Hi sorry, the assert should be assert(!t->have_threads_list(),....) We should not have a threads list :) /Robbin On 24/10/2018 11:18, Robbin Ehn wrote: > Hi Serguei, > > On 24/10/2018 11:00, serguei.spitsyn at oracle.com wrote: >> Hi Robbin and David, >> >> There is no JvmtiEnv::SuspendThreadList call in the dumped stack traces. >> But there is an instance of the JvmtiEnv::SuspendThread which seems to be >> supporting your theory: > > Sorry, I did mean any place we take a ThreadsListHandle and call ::execute with > that handle still alive. That was just first one I saw and used it as an example. >> void JavaThread::java_suspend() { > > You are correct in this particular case it seems to be this one, but we must fix > _all_ of them. That why I suggested adding the assert. And maybe an additional > assert in Mutex on having a threadslist while locking the Threads_lock. > >> I'll check with Leonid tomorrow if we can check if your patch below can fix >> this deadlock. > > It wouldn't fix the deadlock it would assert, so we still need to locate and fix > all the places. Maybe it's just a couple. > > /Robbin > >> >> Thanks, >> Serguei >> >> >> On 10/24/18 00:18, Robbin Ehn wrote: >>> Hi, truncate: >>> >>> On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>>>> One thing I noticed which Robbin should be able to expand upon is that >>>>>> Thread 101 is terminating and has called ThreadsSMRSupport::smr_delete and >>>>>> is blocked here: >>>>>> >>>>>> ??// Wait for a release_stable_list() call before we check again. No >>>>>> ??// safepoint check, no timeout, and not as suspend equivalent flag >>>>>> ??// because this JavaThread is not on the Threads list. >>>>>> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>> ???????????????????????????????????????? 0, >>>>>> !Mutex::_as_suspend_equivalent_flag); >>>>>> >>>>>> As the comment says this thread is no longer on the Threads_list, but the >>>>>> VM_HandshakeAllThreads is not a safepoint operation and does not hold the >>>>>> Threads_lock, so is it possible this thread was captured by the >>>>>> JavaThreadIteratorWithHandle being used by VM_HandshakeAllThreads, before >>>>>> it got removed? If so we'd be hung waiting it for it handshake as it's not >>>>>> in a "safepoint-safe" or suspend-equivalent state. >>> >>> In short: >>> # VM Thread >>> VM Thread is in a loop, takes Threads_lock, takes a new snapshot of the >>> Threads_list, scans the list and process handshakes on behalf of safe threads. >>> Releases snapshot and Threads_lock and checks if all handshakes are completed >>> >>> # An exiting thread >>> A thread exiting thread removes it self from _THE_ threads list, but must >>> stick around if it is on any snapshots of alive. When it is no on any list it >>> will cancel the handshake. >>> >>> Since VM thread during the handshake takes a new snapshot every iteration any >>> exiting can proceed since it will not be a the new snapshot. Thus cancel the >>> handshake and VM thread can exit the loop (if this was the last handshake). >>> >>> Constraint: >>> If any thread grabs a snapshot of threads list and later tries to take a lock >>> which is 'used' by VM Thread or inside the handshake we can deadlock. >>> >>> Considering that looking at e.g. : JvmtiEnv::SuspendThreadList >>> Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, this >>> could deadlock AFAICT. Since the thread will rest on VMOperationRequest_lock >>> with a Threads list snapshot but VM thread cannot finishes handshake until >>> that snapshot is released. >>> >>> I suggest first step is to add something like this patch below and fix the >>> obvious ones first. >>> >>> Note, I have not verified that is the problem you are seeing, I'm saying that >>> this seem to be real issue. And considering how the stack traces looks, it >>> may be this. >>> >>> You want me going through this, just assign a bug if there is one? >>> >>> /Robbin >>> >>> diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp >>> --- a/src/hotspot/share/runtime/thread.hpp??? Tue Oct 23 13:27:41 2018 +0200 >>> +++ b/src/hotspot/share/runtime/thread.hpp??? Wed Oct 24 09:13:17 2018 +0200 >>> @@ -167,2 +167,6 @@ >>> ?? } >>> + public: >>> +? bool have_threads_list(); >>> + private: >>> + >>> ?? // This field is enabled via -XX:+EnableThreadSMRStatistics: >>> diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp >>> --- a/src/hotspot/share/runtime/thread.inline.hpp??? Tue Oct 23 13:27:41 2018 >>> +0200 >>> +++ b/src/hotspot/share/runtime/thread.inline.hpp??? Wed Oct 24 09:13:17 2018 >>> +0200 >>> @@ -111,2 +111,6 @@ >>> >>> +inline bool Thread::have_threads_list() { >>> +? return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; >>> +} >>> + >>> ?inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { >>> diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp >>> --- a/src/hotspot/share/runtime/vmThread.cpp??? Tue Oct 23 13:27:41 2018 +0200 >>> +++ b/src/hotspot/share/runtime/vmThread.cpp??? Wed Oct 24 09:13:17 2018 +0200 >>> @@ -608,2 +608,3 @@ >>> ?? if (!t->is_VM_thread()) { >>> +??? assert(t->have_threads_list(), "Deadlock if we have exiting threads and >>> if vm thread is running an VM op."); // fatal/guarantee >>> ???? SkipGCALot sgcalot(t);??? // avoid re-entrant attempts to gc-a-lot >>> >>> >>> >>> >>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, skip it - sorry for the noise. >>>>>>> It is hard to prove anything with current dump. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi David and Robbin, >>>>>>>> >>>>>>>> I have an idea that needs to be checked. >>>>>>>> It can be almost the same deadlock scenario that I've already explained >>>>>>>> but more sophisticated. >>>>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>>>>>> Monitor::_safepoint_check_always does not help much. >>>>>>>> It can be verified by checking what monitors are used by the blocked >>>>>>>> threads. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>>>>>>>> safepoint operation. There's no real way to tell from the stacks what >>>>>>>>>> it's stuck on. >>>>>>>>> >>>>>>>>> I cannot find a thread that is not considered safepoint safe or >>>>>>>>> is_ext_suspended (thread 146). So the handshake should go through. The >>>>>>>>> handshake will log a warning after a while, is there such warning from >>>>>>>>> the handshake operation? >>>>>>>>> >>>>>>>>> There are several threads competing with e.g. Threads_lock, and threads >>>>>>>>> waiting for GC and several other VM ops, could it just be really slow? >>>>>>>>> >>>>>>>>> /Robbin >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> You are right, thanks. >>>>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>> >>>>>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>>>>>>>>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>>>>>>>>>> _thread_blocked and so safepoint-safe and so won't be holding up the >>>>>>>>>>>> safepoint. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>>>> Hi >>>>>>>>>>>>>> >>>>>>>>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test might >>>>>>>>>>>>>> be blocked because it invoke 2 jvmti methods. Can jvmti agent >>>>>>>>>>>>>> invoke jvmti methods from different threads? >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, in general. >>>>>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>>>>> Below, one thread is enabling single stepping while another thread >>>>>>>>>>>>> is being suspended. >>>>>>>>>>>>> Both are blocked at a safepoint which is Okay in general but not >>>>>>>>>>>>> Okay if they hold any lock. >>>>>>>>>>>>> For instance, the thread #152 is holding the monitor JvmtiThreadState. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>> >>>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock >>>>>>>>>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>> >>>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>> >>>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>>> this=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>> >>>>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>>> >>>>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>> >>>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>> >>>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>> >>>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>> >>>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>>> this=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>> >>>>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>>> >>>>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>> >>>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>> >>>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>> >>>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>> >>>>>>>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>>> this=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>> >>>>>>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>>>>> >>>>>>>>>>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>>>>> >>>>>>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>>>>> >>>>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> These two thread are blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>>> in the function ciEnv::cache_jvmti_state(). >>>>>>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>>>>>>> safepoint is waiting for? >>>>>>>>>>>>> >>>>>>>>>>>>> I think, this safepoint operation is waiting for all threads that >>>>>>>>>>>>> are blocked on the JvmtiThreadState_lock. >>>>>>>>>>>>> >>>>>>>>>>>>> Conclusion: >>>>>>>>>>>>> >>>>>>>>>>>>> The deadlock is: >>>>>>>>>>>>> >>>>>>>>>>>>> Thread #152: >>>>>>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>>>> >>>>>>>>>>>>> Many other threads: >>>>>>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>>>>>>>>>> have to reach this state for this safepoint to happen) >>>>>>>>>>>>> >>>>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>>>> >>>>>>>>>>>>> My guess is that this will stop to reproduce after if you turn off >>>>>>>>>>>>> the single stepping for thread #152. >>>>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>>>>>>>>>> integrate jvmti changes but *don't* enabled jvmti module by default. >>>>>>>>>>>>> >>>>>>>>>>>>> This one is a deadlock. >>>>>>>>>>>>> However, the root cause is a race condition that can potentially >>>>>>>>>>>>> result in both deadlocks and crashes. >>>>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>>>>>>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Consider hang - I think that it might be product bug since I don't >>>>>>>>>>>>>> see any locking on my monitors. But I am not sure. Is it possible >>>>>>>>>>>>>> that any my code jvmti agent prevent VM to get into safepoint? >>>>>>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, of course. >>>>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>>>> >>>>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>>>> It is non-trivial in this particular case as there are so many >>>>>>>>>>>>> threads executed at the same time. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) >>>>>>>>>>>>>> at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 8 >>>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>>> try=false) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 47 >>>>>>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >>>>>>>>>>>>>> thread=0x2ae49929fdf8) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>>>>>>>>>> env=, p=) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) >>>>>>>>>>>>>> at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 8 >>>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>>> try=false) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>>>>>> ue) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> :523 >>>>>>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>>>>>>>>> env=0x2ae39801b270) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>>>>>>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>>>>>>>>>>>>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>>> event_thread=event_\ >>>>>>>>>>>>>> thread at entry=0x0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>>>>>> (env=, this=) at /scratch/lmesnik/ws/h\ >>>>>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug >>>>>>>>>>>>>>>> build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, >>>>>>>>>>>>>>>> tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>>>> # Core dump will be written. Default location: Core dumps may be >>>>>>>>>>>>>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e >>>>>>>>>>>>>>>> %P %I %h" (or dumping to >>>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>>>>>>>>>> -XX:+CrashOnOutOfMemoryError >>>>>>>>>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>>>>>>> -XX:+FlightRecorder >>>>>>>>>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>>>>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >>>>>>>>>>>>>>>> Linux Server release 7.3 >>>>>>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d >>>>>>>>>>>>>>>> 0h 0m 31s) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>>>>>>>>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>>>>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>>>>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>>>>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>>>>>>>>>> __va_list_tag*)+0x2f >>>>>>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>>>>>>>>>>>>> const*, char const*, ...)+0x100 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>>>>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>> >>>> >> From jcbeyler at google.com Wed Oct 24 16:40:40 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 24 Oct 2018 09:40:40 -0700 Subject: RFR (M) 8212884: Remove the assignments in ifs for vmTestbase/[a-s] Message-ID: Hi all, Here is the first webrev to extract assignments from if test clauses. It should be relatively straightforward to review. I tested all the tests changed and they pass on my dev machine. Most changes were done via the script I put in the bug, I had to do a few clean-ups and corner cases as well. Webrev: http://cr.openjdk.java.net/~jcbeyler/8212884/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212884 Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Oct 24 17:40:30 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 24 Oct 2018 10:40:30 -0700 Subject: RFR (M) 8212884: Remove the assignments in ifs for vmTestbase/[a-s] In-Reply-To: References: Message-ID: <0b562d7e-a2a5-6211-49cb-4c48f4ca8fef@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Oct 24 20:00:24 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 24 Oct 2018 13:00:24 -0700 Subject: RFR (M) 8212884: Remove the assignments in ifs for vmTestbase/[a-s] In-Reply-To: <0b562d7e-a2a5-6211-49cb-4c48f4ca8fef@oracle.com> References: <0b562d7e-a2a5-6211-49cb-4c48f4ca8fef@oracle.com> Message-ID: Hi Chris, thanks for the review! I created https://bugs.openjdk.java.net/browse/JDK-8212939 for the remaining spaces missing after an if/while/for/switch and between ){ in the case of an if: jint Agent_Initialize(JavaVM *vm, char *options, void *reserved){ Thanks, Jc On Wed, Oct 24, 2018 at 10:40 AM Chris Plummer wrote: > Hi JC, > > Overall looks good. Just a couple of minor things. I don't need to see > another webrev. > > In Abort.cpp, Callbacks.cpp, ConcreteKlassFilter.cpp, > HeapFilter.cpp.frames, NonConcreteKlassFilter.cpp, and > threadend002.cpp.frames you need to add a space after the "if": > > 130 if(!NSK_VERIFY(jvmti != NULL)) { > > In em01t002.cpp, indent of 2nd line isn't correct: > > 74 methodID = jni_env->GetMethodID( > 75 klass, "loadClass", > "(Ljava/lang/String;)Ljava/lang/Class;"); > > thanks, > > Chris > > On 10/24/18 9:40 AM, JC Beyler wrote: > > Hi all, > > Here is the first webrev to extract assignments from if test clauses. It > should be relatively straightforward to review. > > I tested all the tests changed and they pass on my dev machine. > > Most changes were done via the script I put in the bug, I had to do a few > clean-ups and corner cases as well. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212884/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212884 > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Oct 24 20:00:57 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 24 Oct 2018 13:00:57 -0700 Subject: RFR (L) 8212770: Remove spaces before/after () for vmTestbase/jvmti/[s-u] In-Reply-To: References: Message-ID: Hi all, Anybody else want to review this? We can close the book on spaces before/after () once this one goes in :) Jc On Mon, Oct 22, 2018 at 1:37 PM Alex Menkov wrote: > LGTM. > > --alex > > On 10/22/2018 11:29, JC Beyler wrote: > > Hi all, > > > > Here is the next webrev (second out of 3) to remove the spaces > > after/before () from vmTestbase. It is straightforward and I generated > > the webrev with white-space changes showing up of course: > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212770/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212770 > > > > Could I please get some reviews? > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Oct 24 21:16:29 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Oct 2018 14:16:29 -0700 Subject: The failure In-Reply-To: <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> Message-ID: <729a8616-6a66-a9d5-3876-7d1366fc5da4@oracle.com> Leonid confirmed this deadlock is not reproducible if the Kitchensink agent_sampler is disabled. Also, applying the patch from Robbin (with agent_sampler enabled) hit new assert that has caught another case in JvmtiEnv::GetStackTrace with the same pattern: With proposed patch issue reproduced with hs_err (file in attachement): # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:607), pid=26188, tid=26325 # assert(!t->have_threads_list()) failed: Deadlock if we have exiting threads and if vm thread is running an VM op. # # JRE version: Java(TM) SE Runtime Environment (12.0) (slowdebug build 12-internal+0-2018-10-24-2022348.lmesnik.hs-bigapps) # Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 12-internal+0-2018-10-24-2022348.lmesnik.hs-bigapps, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) # Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping to /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/core.26188) # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+PrintFlagsFinal -XX:+StartAttachListener -XX:NativeMemoryTracking=detail -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/java.io.tmpdir -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/user.home -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so applications.kitchensink.process.stress.Main /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/kitchensink.final.properties Host: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux Server release 7.3 Time: Wed Oct 24 13:28:30 2018 PDT elapsed time: 3 seconds (0d 0h 0m 3s) --------------- T H R E A D --------------- Current thread (0x00002b9f68006000): JavaThread "Jvmti-AgentSampler" daemon [_thread_in_vm, id=26325, stack(0x00002b9f88808000,0x00002b9f88909000)] _threads_hazard_ptr=0x00002b9f68008e30, _nested_threads_hazard_ptr_cnt=0 Stack: [0x00002b9f88808000,0x00002b9f88909000], sp=0x00002b9f88907440, free space=1021k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x12a04bb] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6a5 V [libjvm.so+0x129fdb3] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x57 V [libjvm.so+0x8ca5ab] report_vm_error(char const*, int, char const*, char const*, ...)+0x152 V [libjvm.so+0x12e485b] VMThread::execute(VM_Operation*)+0x99 V [libjvm.so+0xdbec54] JvmtiEnv::GetStackTrace(JavaThread*, int, int, _jvmtiFrameInfo*, int*)+0xc0 V [libjvm.so+0xd677cf] jvmti_GetStackTrace+0x2c2 C [libJvmtiStressModule.so+0x302d] trace_stack+0xa9 C [libJvmtiStressModule.so+0x3daf] agent_sampler+0x21f V [libjvm.so+0xddf595] JvmtiAgentThread::call_start_function()+0x67 V [libjvm.so+0xddf52a] JvmtiAgentThread::start_function_wrapper(JavaThread*, Thread*)+0xf2 V [libjvm.so+0x1218945] JavaThread::thread_main_inner()+0x17f V [libjvm.so+0x12187ad] JavaThread::run()+0x273 V [libjvm.so+0x100e4ee] thread_native_entry(Thread*)+0x192 Leonid attached the full hs_err log to the bug report. Thanks, Serguei On 10/24/18 02:00, serguei.spitsyn at oracle.com wrote: > Hi Robbin and David, > > There is no JvmtiEnv::SuspendThreadList call in the dumped stack traces. > But there is an instance of the JvmtiEnv::SuspendThread which seems to > be supporting your theory: > > Thread 136 (Thread 0x2ae494100700 (LWP 28023)): > #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1? 0x00002ae393ba8d63 in os::PlatformEvent::park > (this=this at entry=0x2ae454005800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > #2? 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > #3? Monitor::IWait (this=this at entry=0x2ae398023c10, > Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 > #4? 0x00002ae393b51f2e in Monitor::wait > (this=this at entry=0x2ae398023c10, no_safepoint_check=, > timeout=timeout at entry=0, > as_suspend_equivalent=as_suspend_equivalent at entry=false) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 > #5? 0x00002ae393de7867 in VMThread::execute > (op=op at entry=0x2ae4940ffb10) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 > #6? 0x00002ae393d6a3bd in JavaThread::java_suspend > (this=this at entry=0x2ae3985f2000) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 > #7? 0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend > (java_thread=java_thread at entry=0x2ae3985f2000) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:847 > #8? 0x00002ae3939887ae in JvmtiEnv::SuspendThread > (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:955 > #9? 0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, > thread=0x2ae49929fdf8) at > /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:527 > #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, > env=, p=) at > /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:274 > #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 > #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, > __the_thread__=) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 > #13 0x00002ae393d7338a in JavaThread::thread_main_inner > (this=this at entry=0x2ae454004800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 > #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 > > #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) > at > /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 > #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 > #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 > > > The JavaThread::suspend() call from the stack trace above also holds a > ThreadsListHandle while executing VMThread::execute(&vm_suspend): > > void JavaThread::java_suspend() { > ? ThreadsListHandle tlh; > ? if (!tlh.includes(this) || threadObj() == NULL || is_exiting()) { > ??? return; > ? } > > ? { MutexLockerEx ml(SR_lock(), Mutex::_no_safepoint_check_flag); > ??? if (!is_external_suspend()) { > ????? // a racing resume has cancelled us; bail out now > ????? return; > ??? } > > ??? // suspend is done > ??? uint32_t debug_bits = 0; > ??? // Warning: is_ext_suspend_completed() may temporarily drop the > ??? // SR_lock to allow the thread to reach a stable thread state if > ??? // it is currently in a transient thread state. > ??? if (is_ext_suspend_completed(false /* !called_by_wait */, > ???????????????????????????????? SuspendRetryDelay, &debug_bits)) { > ????? return; > ??? } > ? } > > ? VM_ThreadSuspend vm_suspend; > ? VMThread::execute(&vm_suspend); > } > > > I'll check with Leonid tomorrow if we can check if your patch below > can fix this deadlock. > > Thanks, > Serguei > > > On 10/24/18 00:18, Robbin Ehn wrote: >> Hi, truncate: >> >> On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>>> One thing I noticed which Robbin should be able to expand upon is >>>>> that Thread 101 is terminating and has called >>>>> ThreadsSMRSupport::smr_delete and is blocked here: >>>>> >>>>> ??// Wait for a release_stable_list() call before we check again. No >>>>> ??// safepoint check, no timeout, and not as suspend equivalent flag >>>>> ??// because this JavaThread is not on the Threads list. >>>>> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>> >>>>> ???????????????????????????????????????? 0, >>>>> !Mutex::_as_suspend_equivalent_flag); >>>>> >>>>> As the comment says this thread is no longer on the Threads_list, >>>>> but the VM_HandshakeAllThreads is not a safepoint operation and >>>>> does not hold the Threads_lock, so is it possible this thread was >>>>> captured by the JavaThreadIteratorWithHandle being used by >>>>> VM_HandshakeAllThreads, before it got removed? If so we'd be hung >>>>> waiting it for it handshake as it's not in a "safepoint-safe" or >>>>> suspend-equivalent state. >> >> In short: >> # VM Thread >> VM Thread is in a loop, takes Threads_lock, takes a new snapshot of >> the Threads_list, scans the list and process handshakes on behalf of >> safe threads. >> Releases snapshot and Threads_lock and checks if all handshakes are >> completed >> >> # An exiting thread >> A thread exiting thread removes it self from _THE_ threads list, but >> must stick around if it is on any snapshots of alive. When it is no >> on any list it will cancel the handshake. >> >> Since VM thread during the handshake takes a new snapshot every >> iteration any exiting can proceed since it will not be a the new >> snapshot. Thus cancel the handshake and VM thread can exit the loop >> (if this was the last handshake). >> >> Constraint: >> If any thread grabs a snapshot of threads list and later tries to >> take a lock which is 'used' by VM Thread or inside the handshake we >> can deadlock. >> >> Considering that looking at e.g. : JvmtiEnv::SuspendThreadList >> Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, >> this could deadlock AFAICT. Since the thread will rest on >> VMOperationRequest_lock with a Threads list snapshot but VM thread >> cannot finishes handshake until that snapshot is released. >> >> I suggest first step is to add something like this patch below and >> fix the obvious ones first. >> >> Note, I have not verified that is the problem you are seeing, I'm >> saying that this seem to be real issue. And considering how the stack >> traces looks, it may be this. >> >> You want me going through this, just assign a bug if there is one? >> >> /Robbin >> >> diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp >> --- a/src/hotspot/share/runtime/thread.hpp??? Tue Oct 23 13:27:41 >> 2018 +0200 >> +++ b/src/hotspot/share/runtime/thread.hpp??? Wed Oct 24 09:13:17 >> 2018 +0200 >> @@ -167,2 +167,6 @@ >> ?? } >> + public: >> +? bool have_threads_list(); >> + private: >> + >> ?? // This field is enabled via -XX:+EnableThreadSMRStatistics: >> diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp >> --- a/src/hotspot/share/runtime/thread.inline.hpp??? Tue Oct 23 >> 13:27:41 2018 +0200 >> +++ b/src/hotspot/share/runtime/thread.inline.hpp??? Wed Oct 24 >> 09:13:17 2018 +0200 >> @@ -111,2 +111,6 @@ >> >> +inline bool Thread::have_threads_list() { >> +? return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; >> +} >> + >> ?inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { >> diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp >> --- a/src/hotspot/share/runtime/vmThread.cpp??? Tue Oct 23 13:27:41 >> 2018 +0200 >> +++ b/src/hotspot/share/runtime/vmThread.cpp??? Wed Oct 24 09:13:17 >> 2018 +0200 >> @@ -608,2 +608,3 @@ >> ?? if (!t->is_VM_thread()) { >> +??? assert(t->have_threads_list(), "Deadlock if we have exiting >> threads and if vm thread is running an VM op."); // fatal/guarantee >> ???? SkipGCALot sgcalot(t);??? // avoid re-entrant attempts to gc-a-lot >> >> >> >> >> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, skip it - sorry for the noise. >>>>>> It is hard to prove anything with current dump. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi David and Robbin, >>>>>>> >>>>>>> I have an idea that needs to be checked. >>>>>>> It can be almost the same deadlock scenario that I've already >>>>>>> explained but more sophisticated. >>>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>>>>> Monitor::_safepoint_check_always does not help much. >>>>>>> It can be verified by checking what monitors are used by the >>>>>>> blocked threads. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not >>>>>>>>> a safepoint operation. There's no real way to tell from the >>>>>>>>> stacks what it's stuck on. >>>>>>>> >>>>>>>> I cannot find a thread that is not considered safepoint safe or >>>>>>>> is_ext_suspended (thread 146). So the handshake should go >>>>>>>> through. The handshake will log a warning after a while, is >>>>>>>> there such warning from the handshake operation? >>>>>>>> >>>>>>>> There are several threads competing with e.g. Threads_lock, and >>>>>>>> threads waiting for GC and several other VM ops, could it just >>>>>>>> be really slow? >>>>>>>> >>>>>>>> /Robbin >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> You are right, thanks. >>>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint >>>>>>>>>>> checks enabled, so all JavaThreads blocked trying to acquire >>>>>>>>>>> it will be _thread_blocked and so safepoint-safe and so >>>>>>>>>>> won't be holding up the safepoint. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> Seems last version also crashes with 2 other different >>>>>>>>>>>>> symptoms. >>>>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test >>>>>>>>>>>>> might be blocked because it invoke 2 jvmti methods. Can >>>>>>>>>>>>> jvmti agent invoke jvmti methods from different threads? >>>>>>>>>>>> >>>>>>>>>>>> Yes, in general. >>>>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>>>> Below, one thread is enabling single stepping while another >>>>>>>>>>>> thread is being suspended. >>>>>>>>>>>> Both are blocked at a safepoint which is Okay in general >>>>>>>>>>>> but not Okay if they hold any lock. >>>>>>>>>>>> For instance, the thread #152 is holding the monitor >>>>>>>>>>>> JvmtiThreadState. >>>>>>>>>>>> >>>>>>>>>>>> Also, I see a couple of more threads that are interesting >>>>>>>>>>>> as well: >>>>>>>>>>>> >>>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>>> ev=0x2ae3984c9100) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, >>>>>>>>>>>> Self=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock >>>>>>>>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) >>>>>>>>>>>> at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker >>>>>>>>>>>> (mutex=0x2ae398024f10, this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? ciEnv::cache_jvmti_state >>>>>>>>>>>> (this=this at entry=0x2ae40b78eb30) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>> >>>>>>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae3935d4f48 in >>>>>>>>>>>> CompileBroker::compiler_thread_loop () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>>> (this=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>> >>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>>> ev=0x2ae3984cbb00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, >>>>>>>>>>>> Self=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker >>>>>>>>>>>> (mutex=0x2ae398024f10, this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? ciEnv::cache_jvmti_state >>>>>>>>>>>> (this=this at entry=0x2ae40b88fb30) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>> >>>>>>>>>>>> #8? 0x00002ae3935d3294 in >>>>>>>>>>>> CompileBroker::invoke_compiler_on_method >>>>>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae3935d4f48 in >>>>>>>>>>>> CompileBroker::compiler_thread_loop () at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>>> (this=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>> >>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () >>>>>>>>>>>> from /lib64/libpthread.so.0 >>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>> >>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, >>>>>>>>>>>> ev=0x2ae460061c00) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>> >>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, >>>>>>>>>>>> Self=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>> >>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>> >>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>> >>>>>>>>>>>> #6? 0x00002ae393999682 in MutexLocker >>>>>>>>>>>> (mutex=0x2ae398024f10, this=) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>> >>>>>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>>>> >>>>>>>>>>>> #8? JvmtiEventController::thread_started >>>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>>>> >>>>>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>>>> >>>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run >>>>>>>>>>>> (this=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>>>> >>>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> These two thread are blocked on the monitor >>>>>>>>>>>> JvmtiThreadState_lock in the function >>>>>>>>>>>> ciEnv::cache_jvmti_state(). >>>>>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>>>>> JvmtiExport::post_thread_start and blocked on the same >>>>>>>>>>>> monitor. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>>>>>> safepoint is waiting for? >>>>>>>>>>>> >>>>>>>>>>>> I think, this safepoint operation is waiting for all >>>>>>>>>>>> threads that are blocked on the JvmtiThreadState_lock. >>>>>>>>>>>> >>>>>>>>>>>> Conclusion: >>>>>>>>>>>> >>>>>>>>>>>> The deadlock is: >>>>>>>>>>>> >>>>>>>>>>>> Thread #152: >>>>>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>>> >>>>>>>>>>>> Many other threads: >>>>>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>> ?? - can not reach the blocked at a safepoint state (all >>>>>>>>>>>> threads have to reach this state for this safepoint to happen) >>>>>>>>>>>> >>>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>>> >>>>>>>>>>>> My guess is that this will stop to reproduce after if you >>>>>>>>>>>> turn off the single stepping for thread #152. >>>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make >>>>>>>>>>>>> sense to integrate jvmti changes but *don't* enabled jvmti >>>>>>>>>>>>> module by default. >>>>>>>>>>>> >>>>>>>>>>>> This one is a deadlock. >>>>>>>>>>>> However, the root cause is a race condition that can >>>>>>>>>>>> potentially result in both deadlocks and crashes. >>>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>>> So anyone could easily run them to reproduce crashes. >>>>>>>>>>>>> ?This test would be out of CI to don't introduce any bugs. >>>>>>>>>>>>> Does it make sense? >>>>>>>>>>>>> >>>>>>>>>>>>> Consider hang - I think that it might be product bug since >>>>>>>>>>>>> I don't see any locking on my monitors. But I am not sure. >>>>>>>>>>>>> Is it possible that any my code jvmti agent prevent VM to >>>>>>>>>>>>> get into safepoint? >>>>>>>>>>>>> Could we discuss it tomorrow or his week when you have a >>>>>>>>>>>>> time? >>>>>>>>>>>> >>>>>>>>>>>> Yes, of course. >>>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>>> >>>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>>> It is non-trivial in this particular case as there are so >>>>>>>>>>>> many threads executed at the same time. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 >>>>>>>>>>>>> () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>>>>>> ev=0x2ae454005800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>> >>>>>>>>>>>>> 8 >>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>> no_safepoint_check=, >>>>>>>>>>>>> timeout=timeout at entry=0, >>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>> try=false) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>> >>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>> >>>>>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>>>> >>>>>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>>>> >>>>>>>>>>>>> 47 >>>>>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, >>>>>>>>>>>>> java_thread=0x2ae3985f2000) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>>> >>>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread >>>>>>>>>>>>> (env=0x2ae39801b270, thread=0x2ae49929fdf8) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>>>> >>>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler >>>>>>>>>>>>> (jvmti=0x2ae39801b270, env=, p=>>>>>>>>>>>> out>) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>>>> >>>>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>> >>>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run >>>>>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>> >>>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 >>>>>>>>>>>>> () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, >>>>>>>>>>>>> ev=0x2ae3985e7400) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>> >>>>>>>>>>>>> 8 >>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>> no_safepoint_check=, >>>>>>>>>>>>> timeout=timeout at entry=0, >>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>> try=false) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>> >>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>>> (op=0x2ae42705f500) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>> >>>>>>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>>>>> ue) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>>>> >>>>>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>>>> >>>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>>>> >>>>>>>>>>>>> :523 >>>>>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>>>>>>>> env=0x2ae39801b270) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled >>>>>>>>>>>>> (env=0x2ae39801b270, thread=0x0, >>>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>>>>>>>>>>>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>>> #12 0x00002ae393987d2d in >>>>>>>>>>>>> JvmtiEnv::SetEventNotificationMode >>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, >>>>>>>>>>>>> mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>> event_thread=event_\ >>>>>>>>>>>>> thread at entry=0x0) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>>>> >>>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>>>> >>>>>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>>>>> (env=, this=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/h\ >>>>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>>>> >>>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Leonid >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >>>>>>>>>>>>>>> Environment: >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >>>>>>>>>>>>>>> (fastdebug build >>>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, >>>>>>>>>>>>>>> mixed mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>>> # Core dump will be written. Default location: Core >>>>>>>>>>>>>>> dumps may be processed with "/usr/libexec/abrt-hook-ccpp >>>>>>>>>>>>>>> %s %c %p %u %g %t e %P %I %h" (or dumping to >>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>>> # >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 >>>>>>>>>>>>>>> -XX:MaxRAMPercentage=50 -XX:+CrashOnOutOfMemoryError >>>>>>>>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>>>>>> -XX:+FlightRecorder >>>>>>>>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Host: scaaa118.us.oracle.com >>>>>>>>>>>>>>> , Intel(R) Xeon(R) CPU >>>>>>>>>>>>>>> E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux Server >>>>>>>>>>>>>>> release 7.3 >>>>>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 >>>>>>>>>>>>>>> seconds (0d 0h 0m 31s) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM >>>>>>>>>>>>>>> Thread" [stack: 0x00002af44f10a000,0x00002af44f20a000] >>>>>>>>>>>>>>> [id=13962] _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled >>>>>>>>>>>>>>> Java code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, >>>>>>>>>>>>>>> char const*, char const*, __va_list_tag*, Thread*, >>>>>>>>>>>>>>> unsigned char*, void*, void*, char const*, int, unsigned >>>>>>>>>>>>>>> long)+0x2c3 >>>>>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] >>>>>>>>>>>>>>> ?VMError::report_and_die(Thread*, void*, char const*, >>>>>>>>>>>>>>> int, char const*, char const*, __va_list_tag*)+0x2f >>>>>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, >>>>>>>>>>>>>>> int, char const*, char const*, ...)+0x100 >>>>>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] >>>>>>>>>>>>>>> ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>>> V ?[libjvm.so+0x119af99] >>>>>>>>>>>>>>> ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>>>>> V ?[libjvm.so+0x14e8300] >>>>>>>>>>>>>>> ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, >>>>>>>>>>>>>>> mode: safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> >>> > From dean.long at oracle.com Wed Oct 24 21:18:00 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 24 Oct 2018 14:18:00 -0700 Subject: RFR(S) 8021335: Missing synchronization when reading counters for live threads and peak thread count In-Reply-To: <4febfc04-21c3-fd91-db83-54777ebd7ca2@oracle.com> References: <3345d539-54e0-c048-ddf7-d2919edc585c@oracle.com> <90728cf7-3711-e91c-cf9a-534c8d5fca15@oracle.com> <78dedbbf-cfc0-6910-dc28-ee7eec0f5373@oracle.com> <88d9ae30-d08c-8bab-35a5-b4601f452883@oracle.com> <5b6265b6-36b3-4317-1e6a-8ba51c8a48b3@oracle.com> <0560343b-94b4-2261-0f1d-a08d7067e97b@oracle.com> <43be9a19-d0c5-298a-9bcb-e98223f4566a@oracle.com> <98af2e32-b9e7-e06a-91fc-447baa445bed@oracle.com> <4febfc04-21c3-fd91-db83-54777ebd7ca2@oracle.com> Message-ID: <57b7cbe0-78ed-4a27-b1b0-3f733321ecee@oracle.com> On 10/23/18 11:04 PM, Mandy Chung wrote: > > > On 10/23/18 10:34 PM, David Holmes wrote: >> On 24/10/2018 8:30 AM, dean.long at oracle.com wrote: >>> On 10/23/18 2:51 PM, David Holmes wrote: >>>> Hi Dean, >>>> >>>> On 24/10/2018 4:05 AM, dean.long at oracle.com wrote: >>>>> On 10/23/18 9:46 AM, dean.long at oracle.com wrote: >>>>>> On 10/22/18 3:31 PM, David Holmes wrote: >>>>>>> Sorry Dean I'm concerned about a thread termination bottleneck >>>>>>> with this. A simple microbenchmark that creates 500,000 threads >>>>>>> that have to run and terminate, shows a 15+% slowdown on my >>>>>>> Linux box. I tried to find some kind of real benchmarks that >>>>>>> covers thread termination but couldn't see anything specific. >>>>>>> >>>>>>> Can you at least run this through our performance system to see >>>>>>> if any of the regular benchmarks are affected. >>>>>>> >>>>>> >>>>>> OK, but even if the regular benchmarks don't show a difference, >>>>>> I'd feel better if microbenchmarks were not affected.? What if I >>>>>> go back to the original approach and add locking: >>>>>> >>>>>> ?? static jlong get_live_thread_count()??????? { MutexLocker >>>>>> mu(Threads_lock); return _live_threads_count->get_value() - >>>>>> _exiting_threads_count; } >>>>>> ?? static jlong get_daemon_thread_count()????? { MutexLocker >>>>>> mu(Threads_lock); return _daemon_threads_count->get_value() - >>>>>> _exiting_daemon_threads_count; } >>>>>> >>>>>> along with the other cleanups around is_daemon and is_hidden_thread? >>>>>> >>>>> >>>>> Some micro-benchmarks like SecureRandomBench show a regression >>>>> with webrev.7.? I could go back to webrev.5 and then we shouldn't >>>>> need any locking in the get_*() functions. >>>> >>>> I don't see version 5 discussed but I took a look and it seems okay. >>> >>> Mandy had questions about the asserts in .5, and it seemed like we >>> could just set the perf counters to the same value as the atomic >>> counters, which resulted in .6.? I think the only problem with .6 is >>> that I set the perf counters in decrement_thread_counts without the >>> lock.? If I "sync" the perf counters to the atomic counters only in >>> add_thread and remove_thread, with the lock, then it's about the >>> same as .5, but without the asserts and parallel inc/dec.? If anyone >>> likes the sound of that, I can send out a new webrev.? Or we can go >>> with webrev.5. >> >> I'm not sure what the concern was with the asserts - if they mis-fire >> we'll know soon enough. So I'm okay with .5 >> >>>> My only query with that version is that it appears the actual >>>> perfCounters no longer get read by anything - is that the case? >>>> >>> >>> There does seem to be code that references them, through their name >>> string.? That's a difference interface that I'm not familiar with, >>> so I didn't want to break it. >> >> Right - they can be accessed directly through other means. I was >> concerned that the perfCounter was out of sync with >> get_live_thread-count() but that's already the case so not an issue. >> >> If all tests and benchmarks are happy I say go with version .5 >> > > I have no objection to version .5 if most people prefer that.? My > comment was that I don't think the asserts are necessary. > OK, I'll rerun some performance benchmarks and push .5 if the results look OK.? David, can you send me your micro-benchmark? Thanks for the reviews! dl > Mandy -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed Oct 24 21:26:30 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 24 Oct 2018 14:26:30 -0700 Subject: RFR (M) 8212884: Remove the assignments in ifs for vmTestbase/[a-s] In-Reply-To: References: Message-ID: <9a3c6943-05d4-a11b-9873-937a711c494a@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Oct 24 21:57:51 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 24 Oct 2018 14:57:51 -0700 Subject: RFR (L) 8212770: Remove spaces before/after () for vmTestbase/jvmti/[s-u] In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Oct 24 22:53:20 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Oct 2018 15:53:20 -0700 Subject: Review Request JDK-8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData Message-ID: <72e2a94e-cdb1-ddc5-c248-96e9b2e57591@oracle.com> This patch fixes the regression introduced by JDK-8198253 in 11. It turns out that NetBeans uses the internal sun.management API to convert ThreadInfo to CompositeData for performance reason. ThreadInfoCompositeData::toCompositeData is no longer used in JDK since JMX added the MXBean support in JDK 6. The fix for JDK-8212197 resolves one issue reported [1] but not the bug in ThreadInfoCompositeData::toCompositeData. Sven has filed an issue in NetBeans to replace the use of JDK internal API. Webrev: http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/ Thanks Mandy [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html [2] https://issues.apache.org/jira/browse/NETBEANS-1478 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Wed Oct 24 23:23:20 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 24 Oct 2018 16:23:20 -0700 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: Message-ID: <652f7ad1-4aa4-3753-2393-5a679717f40a@oracle.com> Hi Sven, Do you have the performance numbers comparing the use of this internal API vs MBeanServer::invoke to convert ThreadInfo to CompositeData? ThreadInfo is converted to an open data via MXBean support but not toCompositeData method NB is using. CompositeData is designed for interoperability between a JMX compliant client and a running JVM of different runtime version.? Hence it's intended to be converted through a mbean server.? I think we should first look into the performance of MBeanServer::invoke and it can be improved. Mandy On 10/20/18 6:40 AM, Sven Reimers wrote: > Hi Mandy, > > I think the main problem here is that there is no simple was to do > > CompositeData data = ThreadInfo.toCompositeData(threadInfo) > > using an ?official API (there is only ThreadInfo.from(CompositeData..). > > Do you think it may be a good idea to add such a method? We are using > this approach due to performance reasons (details can be found on the > original NetBeans issue > ). > > Thanks > > Sven > > On Wed, Oct 17, 2018 at 11:48 AM Sven Reimers > wrote: > > 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 >>>> >> > > > > -- > 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 jcbeyler at google.com Thu Oct 25 02:54:05 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 24 Oct 2018 19:54:05 -0700 Subject: RFR (L) 8212770: Remove spaces before/after () for vmTestbase/jvmti/[s-u] In-Reply-To: References: Message-ID: Hi Chris, I inlined my answers: On Wed, Oct 24, 2018 at 2:58 PM Chris Plummer wrote: > Hi JC, > > Overall looks pretty good: > > I see some cases of changes on lines where there is an assignment in a > conditional. Will these conflict with your other webrev? > > if (!NSK_JNI_VERIFY(jni, (root = > - jni->GetStaticObjectField(debugeeClass, rootFieldID)) != > NULL )) { > + jni->GetStaticObjectField(debugeeClass, rootFieldID)) != > NULL)) { > > Yes they might, I was going to go with the first that goes through and send an incremental for the other one. To be honest, I kind of was expecting perhaps some more conversation about extracting the assignments that I'd have time to fix the conflicts without anyone really noticing :) > I noticed a number of cases of checking if a boolean result is true or > false. I brought this up once before. I forgot if you filed a separate CR > for it: > > - if (nsk_jvmti_parseOptions(options) == NSK_FALSE ) { > + if (nsk_jvmti_parseOptions(options) == NSK_FALSE) { > > I can't find it so I created: https://bugs.openjdk.java.net/browse/JDK-8212959 > The following is missing a space. This piece of code is probably > replicated at least a dozen times. > > - if ( rc!= JNI_OK ) { > + if (rc!= JNI_OK) { > > And a missing space here also. Only saw it in one place. > > - if ( (strcmp(name, CLASS_NAME) ==0 ) && (redefineNumber == 0) ) { > + if ((strcmp(name, CLASS_NAME) ==0) && (redefineNumber == 0)) { > > There's a double space here: > > - if ( nsk_jvmti_redefineClass(jvmti_env, klass, fileName) == > NSK_TRUE ) { > + if (nsk_jvmti_redefineClass(jvmti_env, klass, fileName) == > NSK_TRUE) { > > For all of these, I created: https://bugs.openjdk.java.net/browse/JDK-8212960 Let me know if these answer your issues and if therefore I can push webrev.00 in your opinion. Then I'll work on the potential conflicts for the other webrev, Jc thanks, > > Chris > > On 10/24/18 1:00 PM, JC Beyler wrote: > > Hi all, > > Anybody else want to review this? We can close the book on spaces > before/after () once this one goes in :) > Jc > > On Mon, Oct 22, 2018 at 1:37 PM Alex Menkov > wrote: > >> LGTM. >> >> --alex >> >> On 10/22/2018 11:29, JC Beyler wrote: >> > Hi all, >> > >> > Here is the next webrev (second out of 3) to remove the spaces >> > after/before () from vmTestbase. It is straightforward and I generated >> > the webrev with white-space changes showing up of course: >> > >> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212770/webrev.00/ >> > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8212770 >> > >> > Could I please get some reviews? >> > >> > Thanks, >> > Jc >> > > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Oct 25 04:32:05 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 24 Oct 2018 21:32:05 -0700 Subject: RFR (L) 8212770: Remove spaces before/after () for vmTestbase/jvmti/[s-u] In-Reply-To: References: Message-ID: <98a6d09a-884e-18bb-ef32-00543d4ea2ca@oracle.com> An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Thu Oct 25 09:52:23 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 25 Oct 2018 10:52:23 +0100 Subject: Review Request JDK-8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData In-Reply-To: <72e2a94e-cdb1-ddc5-c248-96e9b2e57591@oracle.com> References: <72e2a94e-cdb1-ddc5-c248-96e9b2e57591@oracle.com> Message-ID: Hi Mandy, I agree that this looks more robust and will be better for long term maintainability. I'm just surprised that 156 static CompositeType compositeType() { 157 return STACK_TRACE_ELEMENT_COMPOSITE_TYPE; 158 } is no longer (or was never) needed in StackTraceElementCompositeData when 146 static CompositeType v5CompositeType() { 147 return V5_COMPOSITE_TYPE; 148 } appears to still be needed. Otherwise, this looks good to me. best regards, -- daniel On 24/10/2018 23:53, Mandy Chung wrote: > This patch fixes the regression introduced by JDK-8198253 in 11. > It turns out that NetBeans uses the internal sun.management API to > convert ThreadInfo to CompositeData for performance reason. > ThreadInfoCompositeData::toCompositeData is no longer used > in JDK since JMX added the MXBean support in JDK 6. The fix for > JDK-8212197 resolves one issue reported [1] but not the bug in > ThreadInfoCompositeData::toCompositeData. Sven has filed an > issue in NetBeans to replace the use of JDK internal API. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/ > > Thanks > Mandy > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html > [2] https://issues.apache.org/jira/browse/NETBEANS-1478 From robbin.ehn at oracle.com Thu Oct 25 13:15:42 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 25 Oct 2018 15:15:42 +0200 Subject: For-Test: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <729a8616-6a66-a9d5-3876-7d1366fc5da4@oracle.com> References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> <729a8616-6a66-a9d5-3876-7d1366fc5da4@oracle.com> Message-ID: Hi, here is a fix, which allows ThreadsList to be used over a VM operation. http://cr.openjdk.java.net/~rehn/8212933/v1_handshak_vm_cancel/webrev/ Please test it out. /Robbin On 10/24/18 11:16 PM, serguei.spitsyn at oracle.com wrote: > Leonid confirmed this deadlock is not reproducible if the Kitchensink > agent_sampler is disabled. > Also, applying the patch from Robbin (with agent_sampler enabled) hit new assert > that has caught another case in JvmtiEnv::GetStackTrace with the same pattern: > > With proposed patch issue reproduced with hs_err (file in attachement): > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:607), pid=26188, > tid=26325 > # assert(!t->have_threads_list()) failed: Deadlock if we have exiting threads > and if vm thread is running an VM op. > # > # JRE version: Java(TM) SE Runtime Environment (12.0) (slowdebug build > 12-internal+0-2018-10-24-2022348.lmesnik.hs-bigapps) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug > 12-internal+0-2018-10-24-2022348.lmesnik.hs-bigapps, mixed mode, sharing, > tiered, compressed oops, g1 gc, linux-amd64) > # Core dump will be written. Default location: Core dumps may be processed with > "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping to > /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/core.26188) > > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- S U M M A R Y ------------ > > Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 > -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false > -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData > -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags > -XX:+DisableExplicitGC -XX:+PrintFlagsFinal -XX:+StartAttachListener > -XX:NativeMemoryTracking=detail -XX:+FlightRecorder > --add-exports=java.base/java.lang=ALL-UNNAMED > --add-opens=java.base/java.lang=ALL-UNNAMED > --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED > --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED > -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/java.io.tmpdir > -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/user.home > -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so > applications.kitchensink.process.stress.Main > /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/kitchensink.final.properties > > > Host: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux > Server release 7.3 > Time: Wed Oct 24 13:28:30 2018 PDT elapsed time: 3 seconds (0d 0h 0m 3s) > > --------------- T H R E A D --------------- > > Current thread (0x00002b9f68006000): JavaThread "Jvmti-AgentSampler" daemon > [_thread_in_vm, id=26325, stack(0x00002b9f88808000,0x00002b9f88909000)] > _threads_hazard_ptr=0x00002b9f68008e30, _nested_threads_hazard_ptr_cnt=0 > > Stack: [0x00002b9f88808000,0x00002b9f88909000], sp=0x00002b9f88907440, free > space=1021k > Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, > Vv=VM code, C=native code) > V [libjvm.so+0x12a04bb] VMError::report_and_die(int, char const*, char const*, > __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, > unsigned long)+0x6a5 > V [libjvm.so+0x129fdb3] VMError::report_and_die(Thread*, void*, char const*, > int, char const*, char const*, __va_list_tag*)+0x57 > V [libjvm.so+0x8ca5ab] report_vm_error(char const*, int, char const*, char > const*, ...)+0x152 > V [libjvm.so+0x12e485b] VMThread::execute(VM_Operation*)+0x99 > V [libjvm.so+0xdbec54] JvmtiEnv::GetStackTrace(JavaThread*, int, int, > _jvmtiFrameInfo*, int*)+0xc0 > V [libjvm.so+0xd677cf] jvmti_GetStackTrace+0x2c2 > C [libJvmtiStressModule.so+0x302d] trace_stack+0xa9 > C [libJvmtiStressModule.so+0x3daf] agent_sampler+0x21f > V [libjvm.so+0xddf595] JvmtiAgentThread::call_start_function()+0x67 > V [libjvm.so+0xddf52a] JvmtiAgentThread::start_function_wrapper(JavaThread*, > Thread*)+0xf2 > V [libjvm.so+0x1218945] JavaThread::thread_main_inner()+0x17f > V [libjvm.so+0x12187ad] JavaThread::run()+0x273 > V [libjvm.so+0x100e4ee] thread_native_entry(Thread*)+0x192 > > > > Leonid attached the full hs_err log to the bug report. > > Thanks, > Serguei > > > On 10/24/18 02:00, serguei.spitsyn at oracle.com wrote: >> Hi Robbin and David, >> >> There is no JvmtiEnv::SuspendThreadList call in the dumped stack traces. >> But there is an instance of the JvmtiEnv::SuspendThread which seems to be >> supporting your theory: >> >> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >> /lib64/libpthread.so.0 >> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >> (this=this at entry=0x2ae454005800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >> #2? 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >> #3? Monitor::IWait (this=this at entry=0x2ae398023c10, >> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 >> #4? 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, >> no_safepoint_check=, timeout=timeout at entry=0, >> as_suspend_equivalent=as_suspend_equivalent at entry=false) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >> #5? 0x00002ae393de7867 in VMThread::execute (op=op at entry=0x2ae4940ffb10) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >> #6? 0x00002ae393d6a3bd in JavaThread::java_suspend >> (this=this at entry=0x2ae3985f2000) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >> #7? 0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >> (java_thread=java_thread at entry=0x2ae3985f2000) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:847 >> #8? 0x00002ae3939887ae in JvmtiEnv::SuspendThread >> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:955 >> #9? 0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >> thread=0x2ae49929fdf8) at >> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:527 >> >> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, env=> out>, p=) at >> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:274 >> >> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >> #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, >> __the_thread__=) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >> (this=this at entry=0x2ae454004800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >> #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) at >> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >> >> >> The JavaThread::suspend() call from the stack trace above also holds a >> ThreadsListHandle while executing VMThread::execute(&vm_suspend): >> >> void JavaThread::java_suspend() { >> ? ThreadsListHandle tlh; >> ? if (!tlh.includes(this) || threadObj() == NULL || is_exiting()) { >> ??? return; >> ? } >> >> ? { MutexLockerEx ml(SR_lock(), Mutex::_no_safepoint_check_flag); >> ??? if (!is_external_suspend()) { >> ????? // a racing resume has cancelled us; bail out now >> ????? return; >> ??? } >> >> ??? // suspend is done >> ??? uint32_t debug_bits = 0; >> ??? // Warning: is_ext_suspend_completed() may temporarily drop the >> ??? // SR_lock to allow the thread to reach a stable thread state if >> ??? // it is currently in a transient thread state. >> ??? if (is_ext_suspend_completed(false /* !called_by_wait */, >> ???????????????????????????????? SuspendRetryDelay, &debug_bits)) { >> ????? return; >> ??? } >> ? } >> >> ? VM_ThreadSuspend vm_suspend; >> ? VMThread::execute(&vm_suspend); >> } >> >> >> I'll check with Leonid tomorrow if we can check if your patch below can fix >> this deadlock. >> >> Thanks, >> Serguei >> >> >> On 10/24/18 00:18, Robbin Ehn wrote: >>> Hi, truncate: >>> >>> On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>>>> One thing I noticed which Robbin should be able to expand upon is that >>>>>> Thread 101 is terminating and has called ThreadsSMRSupport::smr_delete and >>>>>> is blocked here: >>>>>> >>>>>> ??// Wait for a release_stable_list() call before we check again. No >>>>>> ??// safepoint check, no timeout, and not as suspend equivalent flag >>>>>> ??// because this JavaThread is not on the Threads list. >>>>>> ??ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>> ???????????????????????????????????????? 0, >>>>>> !Mutex::_as_suspend_equivalent_flag); >>>>>> >>>>>> As the comment says this thread is no longer on the Threads_list, but the >>>>>> VM_HandshakeAllThreads is not a safepoint operation and does not hold the >>>>>> Threads_lock, so is it possible this thread was captured by the >>>>>> JavaThreadIteratorWithHandle being used by VM_HandshakeAllThreads, before >>>>>> it got removed? If so we'd be hung waiting it for it handshake as it's not >>>>>> in a "safepoint-safe" or suspend-equivalent state. >>> >>> In short: >>> # VM Thread >>> VM Thread is in a loop, takes Threads_lock, takes a new snapshot of the >>> Threads_list, scans the list and process handshakes on behalf of safe threads. >>> Releases snapshot and Threads_lock and checks if all handshakes are completed >>> >>> # An exiting thread >>> A thread exiting thread removes it self from _THE_ threads list, but must >>> stick around if it is on any snapshots of alive. When it is no on any list it >>> will cancel the handshake. >>> >>> Since VM thread during the handshake takes a new snapshot every iteration any >>> exiting can proceed since it will not be a the new snapshot. Thus cancel the >>> handshake and VM thread can exit the loop (if this was the last handshake). >>> >>> Constraint: >>> If any thread grabs a snapshot of threads list and later tries to take a lock >>> which is 'used' by VM Thread or inside the handshake we can deadlock. >>> >>> Considering that looking at e.g. : JvmtiEnv::SuspendThreadList >>> Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, this >>> could deadlock AFAICT. Since the thread will rest on VMOperationRequest_lock >>> with a Threads list snapshot but VM thread cannot finishes handshake until >>> that snapshot is released. >>> >>> I suggest first step is to add something like this patch below and fix the >>> obvious ones first. >>> >>> Note, I have not verified that is the problem you are seeing, I'm saying that >>> this seem to be real issue. And considering how the stack traces looks, it >>> may be this. >>> >>> You want me going through this, just assign a bug if there is one? >>> >>> /Robbin >>> >>> diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp >>> --- a/src/hotspot/share/runtime/thread.hpp??? Tue Oct 23 13:27:41 2018 +0200 >>> +++ b/src/hotspot/share/runtime/thread.hpp??? Wed Oct 24 09:13:17 2018 +0200 >>> @@ -167,2 +167,6 @@ >>> ?? } >>> + public: >>> +? bool have_threads_list(); >>> + private: >>> + >>> ?? // This field is enabled via -XX:+EnableThreadSMRStatistics: >>> diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp >>> --- a/src/hotspot/share/runtime/thread.inline.hpp??? Tue Oct 23 13:27:41 2018 >>> +0200 >>> +++ b/src/hotspot/share/runtime/thread.inline.hpp??? Wed Oct 24 09:13:17 2018 >>> +0200 >>> @@ -111,2 +111,6 @@ >>> >>> +inline bool Thread::have_threads_list() { >>> +? return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; >>> +} >>> + >>> ?inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { >>> diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp >>> --- a/src/hotspot/share/runtime/vmThread.cpp??? Tue Oct 23 13:27:41 2018 +0200 >>> +++ b/src/hotspot/share/runtime/vmThread.cpp??? Wed Oct 24 09:13:17 2018 +0200 >>> @@ -608,2 +608,3 @@ >>> ?? if (!t->is_VM_thread()) { >>> +??? assert(t->have_threads_list(), "Deadlock if we have exiting threads and >>> if vm thread is running an VM op."); // fatal/guarantee >>> ???? SkipGCALot sgcalot(t);??? // avoid re-entrant attempts to gc-a-lot >>> >>> >>> >>> >>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, skip it - sorry for the noise. >>>>>>> It is hard to prove anything with current dump. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi David and Robbin, >>>>>>>> >>>>>>>> I have an idea that needs to be checked. >>>>>>>> It can be almost the same deadlock scenario that I've already explained >>>>>>>> but more sophisticated. >>>>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >>>>>>>> Monitor::_safepoint_check_always does not help much. >>>>>>>> It can be verified by checking what monitors are used by the blocked >>>>>>>> threads. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a >>>>>>>>>> safepoint operation. There's no real way to tell from the stacks what >>>>>>>>>> it's stuck on. >>>>>>>>> >>>>>>>>> I cannot find a thread that is not considered safepoint safe or >>>>>>>>> is_ext_suspended (thread 146). So the handshake should go through. The >>>>>>>>> handshake will log a warning after a while, is there such warning from >>>>>>>>> the handshake operation? >>>>>>>>> >>>>>>>>> There are several threads competing with e.g. Threads_lock, and threads >>>>>>>>> waiting for GC and several other VM ops, could it just be really slow? >>>>>>>>> >>>>>>>>> /Robbin >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> You are right, thanks. >>>>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>> >>>>>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint checks >>>>>>>>>>>> enabled, so all JavaThreads blocked trying to acquire it will be >>>>>>>>>>>> _thread_blocked and so safepoint-safe and so won't be holding up the >>>>>>>>>>>> safepoint. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>>>> Hi >>>>>>>>>>>>>> >>>>>>>>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also it might hangs with ?stack attached. ?Seems that test might >>>>>>>>>>>>>> be blocked because it invoke 2 jvmti methods. Can jvmti agent >>>>>>>>>>>>>> invoke jvmti methods from different threads? >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, in general. >>>>>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>>>>> Below, one thread is enabling single stepping while another thread >>>>>>>>>>>>> is being suspended. >>>>>>>>>>>>> Both are blocked at a safepoint which is Okay in general but not >>>>>>>>>>>>> Okay if they hold any lock. >>>>>>>>>>>>> For instance, the thread #152 is holding the monitor JvmtiThreadState. >>>>>>>>>>>>> >>>>>>>>>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae3984c9100) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>> >>>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock >>>>>>>>>>>>> (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>> >>>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>> >>>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>>> this=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>> >>>>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>>>>> (task=task at entry=0x2ae48800ff40) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>>> >>>>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>> (this=this at entry=0x2ae3984c7800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>> >>>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae3984c7800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae3984cbb00) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>> >>>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >>>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>> >>>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>> >>>>>>>>>>>>> #6? 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>>> this=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>> >>>>>>>>>>>>> #7? ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>>> #8? 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method >>>>>>>>>>>>> (task=task at entry=0x2ae49c00a670) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>>> >>>>>>>>>>>>> #9? 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>> (this=this at entry=0x2ae3984ca800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>> >>>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae3984ca800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>>>> #0? 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>> #1? 0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>> (this=this at entry=0x2ae460061c00) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>> >>>>>>>>>>>>> #2? 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>> >>>>>>>>>>>>> #3? Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>> >>>>>>>>>>>>> #4? 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >>>>>>>>>>>>> this=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>> >>>>>>>>>>>>> #5? Monitor::lock (this=this at entry=0x2ae398024f10) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>> >>>>>>>>>>>>> #6? 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, >>>>>>>>>>>>> this=) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>> >>>>>>>>>>>>> #7? thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>>>>> >>>>>>>>>>>>> #8? JvmtiEventController::thread_started (thread=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>>>>> >>>>>>>>>>>>> #9? 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >>>>>>>>>>>>> (thread=thread at entry=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>>>>> >>>>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>>>>> >>>>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>> (thread=0x2ae4600c2800) at >>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>> >>>>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> These two thread are blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>>> in the function ciEnv::cache_jvmti_state(). >>>>>>>>>>>>> Also, there are many threads (like #51) that are executing >>>>>>>>>>>>> JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>>>> What thread is blocking it? Or in reverse, what thread this >>>>>>>>>>>>> safepoint is waiting for? >>>>>>>>>>>>> >>>>>>>>>>>>> I think, this safepoint operation is waiting for all threads that >>>>>>>>>>>>> are blocked on the JvmtiThreadState_lock. >>>>>>>>>>>>> >>>>>>>>>>>>> Conclusion: >>>>>>>>>>>>> >>>>>>>>>>>>> The deadlock is: >>>>>>>>>>>>> >>>>>>>>>>>>> Thread #152: >>>>>>>>>>>>> ?? - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>>>> ?? - blocked in the VM_GetCurrentLocation in the function >>>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>>>> >>>>>>>>>>>>> Many other threads: >>>>>>>>>>>>> ?? - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>>> ?? - can not reach the blocked at a safepoint state (all threads >>>>>>>>>>>>> have to reach this state for this safepoint to happen) >>>>>>>>>>>>> >>>>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>>>> >>>>>>>>>>>>> My guess is that this will stop to reproduce after if you turn off >>>>>>>>>>>>> the single stepping for thread #152. >>>>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make sense to >>>>>>>>>>>>>> integrate jvmti changes but *don't* enabled jvmti module by default. >>>>>>>>>>>>> >>>>>>>>>>>>> This one is a deadlock. >>>>>>>>>>>>> However, the root cause is a race condition that can potentially >>>>>>>>>>>>> result in both deadlocks and crashes. >>>>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>>>> So anyone could easily run them to reproduce crashes. ?This test >>>>>>>>>>>>>> would be out of CI to don't introduce any bugs. Does it make sense? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Consider hang - I think that it might be product bug since I don't >>>>>>>>>>>>>> see any locking on my monitors. But I am not sure. Is it possible >>>>>>>>>>>>>> that any my code jvmti agent prevent VM to get into safepoint? >>>>>>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, of course. >>>>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>>>> >>>>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>>>> It is non-trivial in this particular case as there are so many >>>>>>>>>>>>> threads executed at the same time. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>>> (this=this at entry=0x2ae454005800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) >>>>>>>>>>>>>> at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>>> Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 8 >>>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>>> try=false) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute >>>>>>>>>>>>>> (op=op at entry=0x2ae4940ffb10) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #6 ?0x00002ae393d6a3bd in JavaThread::java_suspend >>>>>>>>>>>>>> (this=this at entry=0x2ae3985f2000) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #7 ?0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >>>>>>>>>>>>>> (java_thread=java_thread at entry=0x2ae3985f2000) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 47 >>>>>>>>>>>>>> #8 ?0x00002ae3939887ae in JvmtiEnv::SuspendThread >>>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>>>> #9 ?0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >>>>>>>>>>>>>> thread=0x2ae49929fdf8) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >>>>>>>>>>>>>> env=, p=) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function >>>>>>>>>>>>>> (this=0x2ae454004800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >>>>>>>>>>>>>> (thread=0x2ae454004800, __the_thread__=) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >>>>>>>>>>>>>> (this=this at entry=0x2ae454004800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >>>>>>>>>>>>>> (thread=0x2ae454004800) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>>>> #0 ?0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >>>>>>>>>>>>>> /lib64/libpthread.so.0 >>>>>>>>>>>>>> #1 ?0x00002ae393ba8d63 in os::PlatformEvent::park >>>>>>>>>>>>>> (this=this at entry=0x2ae3985e7400) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #2 ?0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) >>>>>>>>>>>>>> at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #3 ?Monitor::IWait (this=this at entry=0x2ae398023c10, >>>>>>>>>>>>>> Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> 8 >>>>>>>>>>>>>> #4 ?0x00002ae393b51f2e in Monitor::wait >>>>>>>>>>>>>> (this=this at entry=0x2ae398023c10, no_safepoint_check=>>>>>>>>>>>>> out>, timeout=timeout at entry=0, >>>>>>>>>>>>>> as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>>> try=false) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #5 ?0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #6 ?0x00002ae3939965f3 in >>>>>>>>>>>>>> JvmtiEnvThreadState::reset_current_location >>>>>>>>>>>>>> (this=this at entry=0x2ae6bc000d80, >>>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>>> enabled=enabled at entry=tr\ >>>>>>>>>>>>>> ue) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #7 ?0x00002ae393997acf in recompute_env_thread_enabled >>>>>>>>>>>>>> (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>>>> #8 ?JvmtiEventControllerPrivate::recompute_thread_enabled >>>>>>>>>>>>>> (state=state at entry=0x2ae6bc000cd0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>>>>> >>>>>>>>>>>>>> :523 >>>>>>>>>>>>>> #9 ?0x00002ae393998168 in >>>>>>>>>>>>>> JvmtiEventControllerPrivate::recompute_enabled () at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, >>>>>>>>>>>>>> event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >>>>>>>>>>>>>> env=0x2ae39801b270) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, >>>>>>>>>>>>>> thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=>>>>>>>>>>>>> out>) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode >>>>>>>>>>>>>> (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode >>>>>>>>>>>>>> (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, >>>>>>>>>>>>>> event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >>>>>>>>>>>>>> event_thread=event_\ >>>>>>>>>>>>>> thread at entry=0x0) at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #15 0x00002ae394d98070 in >>>>>>>>>>>>>> Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >>>>>>>>>>>>>> (env=, this=) at /scratch/lmesnik/ws/h\ >>>>>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>>>>> >>>>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> # ?Internal Error >>>>>>>>>>>>>>>> (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >>>>>>>>>>>>>>>> pid=13926, tid=13962 >>>>>>>>>>>>>>>> # ?assert(_cur_stack_depth == count_frames()) failed: >>>>>>>>>>>>>>>> cur_stack_depth out of sync >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug >>>>>>>>>>>>>>>> build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug >>>>>>>>>>>>>>>> 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, >>>>>>>>>>>>>>>> tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>>>> # Core dump will be written. Default location: Core dumps may be >>>>>>>>>>>>>>>> processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e >>>>>>>>>>>>>>>> %P %I %h" (or dumping to >>>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --------------- ?S U M M A R Y ------------ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >>>>>>>>>>>>>>>> -XX:+CrashOnOutOfMemoryError >>>>>>>>>>>>>>>> -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >>>>>>>>>>>>>>>> -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >>>>>>>>>>>>>>>> -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >>>>>>>>>>>>>>>> -XX:+DisableExplicitGC -XX:+PrintFlagsFinal >>>>>>>>>>>>>>>> -XX:+StartAttachListener -XX:NativeMemoryTracking=detail >>>>>>>>>>>>>>>> -XX:+FlightRecorder >>>>>>>>>>>>>>>> --add-exports=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>>> --add-opens=java.base/java.lang=ALL-UNNAMED >>>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >>>>>>>>>>>>>>>> --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >>>>>>>>>>>>>>>> -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >>>>>>>>>>>>>>>> -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >>>>>>>>>>>>>>>> -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >>>>>>>>>>>>>>>> applications.kitchensink.process.stress.Main >>>>>>>>>>>>>>>> /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Host: scaaa118.us.oracle.com , >>>>>>>>>>>>>>>> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >>>>>>>>>>>>>>>> Linux Server release 7.3 >>>>>>>>>>>>>>>> Time: Tue Oct ?9 16:06:07 2018 PDT elapsed time: 31 seconds (0d >>>>>>>>>>>>>>>> 0h 0m 31s) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --------------- ?T H R E A D ?--------------- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): ?VMThread "VM Thread" >>>>>>>>>>>>>>>> [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >>>>>>>>>>>>>>>> _threads_hazard_ptr=0x00002af4ac090eb0, >>>>>>>>>>>>>>>> _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >>>>>>>>>>>>>>>> ?sp=0x00002af44f208720, ?free space=1017k >>>>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, >>>>>>>>>>>>>>>> j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>>>> V ?[libjvm.so+0x18c4923] ?VMError::report_and_die(int, char >>>>>>>>>>>>>>>> const*, char const*, __va_list_tag*, Thread*, unsigned char*, >>>>>>>>>>>>>>>> void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x18c56ef] ?VMError::report_and_die(Thread*, >>>>>>>>>>>>>>>> void*, char const*, int, char const*, char const*, >>>>>>>>>>>>>>>> __va_list_tag*)+0x2f >>>>>>>>>>>>>>>> V ?[libjvm.so+0xb55aa0] ?report_vm_error(char const*, int, char >>>>>>>>>>>>>>>> const*, char const*, ...)+0x100 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x11f2cfe] ?JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>>>> V ?[libjvm.so+0x11f3257] >>>>>>>>>>>>>>>> ?JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x119af99] ?VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x1908982] ?VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x19040be] >>>>>>>>>>>>>>>> ?VMThread::evaluate_operation(VM_Operation*) [clone >>>>>>>>>>>>>>>> .constprop.51]+0x18e >>>>>>>>>>>>>>>> V ?[libjvm.so+0x1904960] ?VMThread::loop()+0x4c0 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x1904f53] ?VMThread::run()+0xd3 >>>>>>>>>>>>>>>> V ?[libjvm.so+0x14e8300] ?thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: >>>>>>>>>>>>>>>> safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>> >>>> >> > From jcbeyler at google.com Thu Oct 25 15:44:01 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 25 Oct 2018 08:44:01 -0700 Subject: RFR (L) 8212770: Remove spaces before/after () for vmTestbase/jvmti/[s-u] In-Reply-To: <98a6d09a-884e-18bb-ef32-00543d4ea2ca@oracle.com> References: <98a6d09a-884e-18bb-ef32-00543d4ea2ca@oracle.com> Message-ID: Thanks Chris, Pushed then! Jc On Wed, Oct 24, 2018 at 9:32 PM Chris Plummer wrote: > Hi JC, > > webrev.00 is fine since you have bugs filed for the rest. > > thanks, > > Chris > > On 10/24/18 7:54 PM, JC Beyler wrote: > > Hi Chris, > > I inlined my answers: > > On Wed, Oct 24, 2018 at 2:58 PM Chris Plummer > wrote: > >> Hi JC, >> >> Overall looks pretty good: >> >> I see some cases of changes on lines where there is an assignment in a >> conditional. Will these conflict with your other webrev? >> >> if (!NSK_JNI_VERIFY(jni, (root = >> - jni->GetStaticObjectField(debugeeClass, rootFieldID)) != >> NULL )) { >> + jni->GetStaticObjectField(debugeeClass, rootFieldID)) != >> NULL)) { >> >> > Yes they might, I was going to go with the first that goes through and > send an incremental for the other one. To be honest, I kind of was > expecting perhaps some more conversation about extracting the assignments > that I'd have time to fix the conflicts without anyone really noticing :) > > >> I noticed a number of cases of checking if a boolean result is true or >> false. I brought this up once before. I forgot if you filed a separate CR >> for it: >> >> - if (nsk_jvmti_parseOptions(options) == NSK_FALSE ) { >> + if (nsk_jvmti_parseOptions(options) == NSK_FALSE) { >> >> > I can't find it so I created: > https://bugs.openjdk.java.net/browse/JDK-8212959 > > > >> The following is missing a space. This piece of code is probably >> replicated at least a dozen times. >> >> - if ( rc!= JNI_OK ) { >> + if (rc!= JNI_OK) { >> >> And a missing space here also. Only saw it in one place. >> >> - if ( (strcmp(name, CLASS_NAME) ==0 ) && (redefineNumber == 0) ) { >> + if ((strcmp(name, CLASS_NAME) ==0) && (redefineNumber == 0)) { >> >> There's a double space here: >> >> - if ( nsk_jvmti_redefineClass(jvmti_env, klass, fileName) == >> NSK_TRUE ) { >> + if (nsk_jvmti_redefineClass(jvmti_env, klass, fileName) == >> NSK_TRUE) { >> >> > For all of these, I created: > https://bugs.openjdk.java.net/browse/JDK-8212960 > > Let me know if these answer your issues and if therefore I can push > webrev.00 in your opinion. Then I'll work on the potential conflicts for > the other webrev, > Jc > > thanks, >> >> Chris >> >> On 10/24/18 1:00 PM, JC Beyler wrote: >> >> Hi all, >> >> Anybody else want to review this? We can close the book on spaces >> before/after () once this one goes in :) >> Jc >> >> On Mon, Oct 22, 2018 at 1:37 PM Alex Menkov >> wrote: >> >>> LGTM. >>> >>> --alex >>> >>> On 10/22/2018 11:29, JC Beyler wrote: >>> > Hi all, >>> > >>> > Here is the next webrev (second out of 3) to remove the spaces >>> > after/before () from vmTestbase. It is straightforward and I generated >>> > the webrev with white-space changes showing up of course: >>> > >>> > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212770/webrev.00/ >>> > >>> > Bug: https://bugs.openjdk.java.net/browse/JDK-8212770 >>> > >>> > Could I please get some reviews? >>> > >>> > Thanks, >>> > Jc >>> >> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Thu Oct 25 15:53:57 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Oct 2018 08:53:57 -0700 Subject: Review Request JDK-8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData In-Reply-To: References: <72e2a94e-cdb1-ddc5-c248-96e9b2e57591@oracle.com> Message-ID: <556704db-0614-4859-e61b-201ebe0c96e8@oracle.com> On 10/25/18 2:52 AM, Daniel Fuchs wrote: > Hi Mandy, > > I agree that this looks more robust and will be better for > long term maintainability. I'm just surprised that > > ?156???? static CompositeType compositeType() { > ?157???????? return STACK_TRACE_ELEMENT_COMPOSITE_TYPE; > ?158???? } > > is no longer (or was never) needed in StackTraceElementCompositeData > when > > ?146???? static CompositeType v5CompositeType() { > ?147???????? return V5_COMPOSITE_TYPE; > ?148???? } > > appears to still be needed. > It's used by MonitorInfoCompositeInfo and ThreadInfoCompositeInfo to build their CompositeType of older version.? For the current version, it gets it from MappedMXBeanType.toOpenType and hence no need for compositeType(). > Otherwise, this looks good to me. Thanks for the review. Mandy > > best regards, > > -- daniel > > On 24/10/2018 23:53, Mandy Chung wrote: >> This patch fixes the regression introduced by JDK-8198253 in 11. >> It turns out that NetBeans uses the internal sun.management API to >> convert ThreadInfo to CompositeData for performance reason. >> ThreadInfoCompositeData::toCompositeData is no longer used >> in JDK since JMX added the MXBean support in JDK 6. The fix for >> JDK-8212197 resolves one issue reported [1] but not the bug in >> ThreadInfoCompositeData::toCompositeData. Sven has filed an >> issue in NetBeans to replace the use of JDK internal API. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/ >> >> Thanks >> Mandy >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html >> [2] https://issues.apache.org/jira/browse/NETBEANS-1478 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu Oct 25 16:00:29 2018 From: jcbeyler at google.com (JC Beyler) Date: Thu, 25 Oct 2018 09:00:29 -0700 Subject: RFR (M) 8212884: Remove the assignments in ifs for vmTestbase/[a-s] In-Reply-To: <9a3c6943-05d4-a11b-9873-937a711c494a@oracle.com> References: <9a3c6943-05d4-a11b-9873-937a711c494a@oracle.com> Message-ID: Hi all, For reference, after the space removal webrev has been pushed, this webrev had a tiny conflict (as Chris had guessed) in one file: test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp You can see the old change vs the new change, it is trivial to see it is ok: - http://cr.openjdk.java.net/~jcbeyler/8212884/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.udiff.html - http://cr.openjdk.java.net/~jcbeyler/8212884/webrev.01/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/ap04t003.cpp.udiff.html The full webrev is here: Webrev: http://cr.openjdk.java.net/~jcbeyler/8212884/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8212884 If I could have a final LGTM, that would be awesome! Jc On Wed, Oct 24, 2018 at 2:26 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Jc, > > It looks great! > Your AI-enabled conversion scripts are smart! :) > > Thanks, > Serguei > > On 10/24/18 09:40, JC Beyler wrote: > > Hi all, > > Here is the first webrev to extract assignments from if test clauses. It > should be relatively straightforward to review. > > I tested all the tests changed and they pass on my dev machine. > > Most changes were done via the script I put in the bug, I had to do a few > clean-ups and corner cases as well. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212884/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8212884 > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sven.reimers at gmail.com Thu Oct 25 16:32:41 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 25 Oct 2018 09:32:41 -0700 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: <652f7ad1-4aa4-3753-2393-5a679717f40a@oracle.com> References: <652f7ad1-4aa4-3753-2393-5a679717f40a@oracle.com> Message-ID: Hi Mandy, I think I would like to get rid of this way of collecting profile data for NetBeans IDE (all applications based on the NetBeans Platform). I talked to Marcus Hirt and he suggested to use JFR from 11 onwards - I think this is a very good idea and with this, the old code will just be a fallback if JFR is not applicable. What do you think? Sven On Wed, Oct 24, 2018 at 4:22 PM Mandy Chung wrote: > Hi Sven, > > Do you have the performance numbers comparing the use of this > internal API vs MBeanServer::invoke to convert ThreadInfo to > CompositeData? > > ThreadInfo is converted to an open data via MXBean support > but not toCompositeData method NB is using. > CompositeData is designed for interoperability between a > JMX compliant client and a running JVM of different runtime > version. Hence it's intended to be converted through a mbean > server. I think we should first look into the performance > of MBeanServer::invoke and it can be improved. > > Mandy > > > On 10/20/18 6:40 AM, Sven Reimers wrote: > > Hi Mandy, > > I think the main problem here is that there is no simple was to do > > CompositeData data = ThreadInfo.toCompositeData(threadInfo) > > using an official API (there is only ThreadInfo.from(CompositeData..). > > Do you think it may be a good idea to add such a method? We are using this > approach due to performance reasons (details can be found on the original NetBeans > issue > > ). > > Thanks > > Sven > > On Wed, Oct 17, 2018 at 11:48 AM Sven Reimers > wrote: > >> 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 >>> >>> >>> >>> > > -- > 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 > > > -- 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 mandy.chung at oracle.com Thu Oct 25 16:36:58 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Oct 2018 09:36:58 -0700 Subject: Probable bug within sun.management.StackTraceElementCompositeData In-Reply-To: References: <652f7ad1-4aa4-3753-2393-5a679717f40a@oracle.com> Message-ID: <7ba5853b-91c7-23c1-4733-c0f868874b83@oracle.com> Using JFR is a good idea. Mandy On 10/25/18 9:32 AM, Sven Reimers wrote: > Hi Mandy, > > I think I would like to get rid of this way of collecting profile data > for NetBeans IDE (all applications based on the NetBeans Platform). I > talked to Marcus Hirt and he suggested to use JFR from 11 onwards - I > think this is a very good idea and with this, the old code will just > be a fallback if JFR is not applicable. > > What?do you think? > > Sven > > On Wed, Oct 24, 2018 at 4:22 PM Mandy Chung > wrote: > > Hi Sven, > > Do you have the performance numbers comparing the use of this > internal API vs MBeanServer::invoke to convert ThreadInfo to > CompositeData? > > ThreadInfo is converted to an open data via MXBean support > but not toCompositeData method NB is using. > CompositeData is designed for interoperability between a > JMX compliant client and a running JVM of different runtime > version.? Hence it's intended to be converted through a mbean > server.? I think we should first look into the performance > of MBeanServer::invoke and it can be improved. > > Mandy > > > On 10/20/18 6:40 AM, Sven Reimers wrote: >> Hi Mandy, >> >> I think the main problem here is that there is no simple was to do >> >> CompositeData data = ThreadInfo.toCompositeData(threadInfo) >> >> using an ?official API (there is only >> ThreadInfo.from(CompositeData..). >> >> Do you think it may be a good idea to add such a method? We are >> using this approach due to performance reasons (details can be >> found on the original NetBeans issue >> ). >> >> Thanks >> >> Sven >> >> On Wed, Oct 17, 2018 at 11:48 AM Sven Reimers >> > wrote: >> >> 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 >>>>> >>> >> >> >> >> -- >> 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 > > > > -- > 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 serguei.spitsyn at oracle.com Thu Oct 25 16:38:03 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Oct 2018 09:38:03 -0700 Subject: RFR (M) 8212884: Remove the assignments in ifs for vmTestbase/[a-s] In-Reply-To: References: <9a3c6943-05d4-a11b-9873-937a711c494a@oracle.com> Message-ID: <462ecc44-d226-1342-14f7-ac55ba4af376@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu Oct 25 17:05:56 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 25 Oct 2018 10:05:56 -0700 Subject: RFR (M) 8212884: Remove the assignments in ifs for vmTestbase/[a-s] In-Reply-To: <462ecc44-d226-1342-14f7-ac55ba4af376@oracle.com> References: <9a3c6943-05d4-a11b-9873-937a711c494a@oracle.com> <462ecc44-d226-1342-14f7-ac55ba4af376@oracle.com> Message-ID: <7f824920-7bda-792d-f28d-22e05427944c@oracle.com> An HTML attachment was scrubbed... URL: From sven.reimers at gmail.com Thu Oct 25 17:09:09 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 25 Oct 2018 10:09:09 -0700 Subject: Review Request JDK-8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData In-Reply-To: <556704db-0614-4859-e61b-201ebe0c96e8@oracle.com> References: <72e2a94e-cdb1-ddc5-c248-96e9b2e57591@oracle.com> <556704db-0614-4859-e61b-201ebe0c96e8@oracle.com> Message-ID: Hi, jus tested the suggested fix against jdk12 head with NetBeans 10VC1 and self sampling works as expected. Thanks for your hard work. Sven On Thu, Oct 25, 2018 at 8:52 AM Mandy Chung wrote: > > > On 10/25/18 2:52 AM, Daniel Fuchs wrote: > > Hi Mandy, > > I agree that this looks more robust and will be better for > long term maintainability. I'm just surprised that > > 156 static CompositeType compositeType() { > 157 return STACK_TRACE_ELEMENT_COMPOSITE_TYPE; > 158 } > > is no longer (or was never) needed in StackTraceElementCompositeData > when > > 146 static CompositeType v5CompositeType() { > 147 return V5_COMPOSITE_TYPE; > 148 } > > appears to still be needed. > > > It's used by MonitorInfoCompositeInfo and ThreadInfoCompositeInfo to build > their CompositeType of older version. For the current version, it gets it > from MappedMXBeanType.toOpenType and hence no need for compositeType(). > > Otherwise, this looks good to me. > > > Thanks for the review. > > Mandy > > > best regards, > > -- daniel > > On 24/10/2018 23:53, Mandy Chung wrote: > > This patch fixes the regression introduced by JDK-8198253 in 11. > It turns out that NetBeans uses the internal sun.management API to > convert ThreadInfo to CompositeData for performance reason. > ThreadInfoCompositeData::toCompositeData is no longer used > in JDK since JMX added the MXBean support in JDK 6. The fix for > JDK-8212197 resolves one issue reported [1] but not the bug in > ThreadInfoCompositeData::toCompositeData. Sven has filed an > issue in NetBeans to replace the use of JDK internal API. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/ > > Thanks > Mandy > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html > [2] https://issues.apache.org/jira/browse/NETBEANS-1478 > > > > -- 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 mandy.chung at oracle.com Thu Oct 25 17:12:09 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Oct 2018 10:12:09 -0700 Subject: Review Request JDK-8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData In-Reply-To: References: <72e2a94e-cdb1-ddc5-c248-96e9b2e57591@oracle.com> <556704db-0614-4859-e61b-201ebe0c96e8@oracle.com> Message-ID: Thanks for verifying the fix, Sven. Mandy On 10/25/18 10:09 AM, Sven Reimers wrote: > Hi, > > jus tested the suggested fix against jdk12 head with NetBeans 10VC1 > and self sampling works as expected. > > Thanks for your hard work. > > Sven > > On Thu, Oct 25, 2018 at 8:52 AM Mandy Chung > wrote: > > > > On 10/25/18 2:52 AM, Daniel Fuchs wrote: >> Hi Mandy, >> >> I agree that this looks more robust and will be better for >> long term maintainability. I'm just surprised that >> >> ?156???? static CompositeType compositeType() { >> ?157???????? return STACK_TRACE_ELEMENT_COMPOSITE_TYPE; >> ?158???? } >> >> is no longer (or was never) needed in StackTraceElementCompositeData >> when >> >> ?146???? static CompositeType v5CompositeType() { >> ?147???????? return V5_COMPOSITE_TYPE; >> ?148???? } >> >> appears to still be needed. >> > > It's used by MonitorInfoCompositeInfo and ThreadInfoCompositeInfo > to build their CompositeType of older version.? For the current > version, it gets it from MappedMXBeanType.toOpenType and hence no > need for compositeType(). > >> Otherwise, this looks good to me. > > Thanks for the review. > > Mandy > >> >> best regards, >> >> -- daniel >> >> On 24/10/2018 23:53, Mandy Chung wrote: >>> This patch fixes the regression introduced by JDK-8198253 in 11. >>> It turns out that NetBeans uses the internal sun.management API to >>> convert ThreadInfo to CompositeData for performance reason. >>> ThreadInfoCompositeData::toCompositeData is no longer used >>> in JDK since JMX added the MXBean support in JDK 6. The fix for >>> JDK-8212197 resolves one issue reported [1] but not the bug in >>> ThreadInfoCompositeData::toCompositeData. Sven has filed an >>> issue in NetBeans to replace the use of JDK internal API. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/ >>> >>> >>> >>> Thanks >>> Mandy >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html >>> [2] https://issues.apache.org/jira/browse/NETBEANS-1478 >> > > > > -- > 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 sven.reimers at gmail.com Thu Oct 25 17:16:24 2018 From: sven.reimers at gmail.com (Sven Reimers) Date: Thu, 25 Oct 2018 10:16:24 -0700 Subject: Review Request JDK-8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData In-Reply-To: References: <72e2a94e-cdb1-ddc5-c248-96e9b2e57591@oracle.com> <556704db-0614-4859-e61b-201ebe0c96e8@oracle.com> Message-ID: Hi Mandy, will this be backported to 11? Sven On Thu, Oct 25, 2018 at 10:10 AM Mandy Chung wrote: > Thanks for verifying the fix, Sven. > > Mandy > > On 10/25/18 10:09 AM, Sven Reimers wrote: > > Hi, > > jus tested the suggested fix against jdk12 head with NetBeans 10VC1 and > self sampling works as expected. > > Thanks for your hard work. > > Sven > > On Thu, Oct 25, 2018 at 8:52 AM Mandy Chung > wrote: > >> >> >> On 10/25/18 2:52 AM, Daniel Fuchs wrote: >> >> Hi Mandy, >> >> I agree that this looks more robust and will be better for >> long term maintainability. I'm just surprised that >> >> 156 static CompositeType compositeType() { >> 157 return STACK_TRACE_ELEMENT_COMPOSITE_TYPE; >> 158 } >> >> is no longer (or was never) needed in StackTraceElementCompositeData >> when >> >> 146 static CompositeType v5CompositeType() { >> 147 return V5_COMPOSITE_TYPE; >> 148 } >> >> appears to still be needed. >> >> >> It's used by MonitorInfoCompositeInfo and ThreadInfoCompositeInfo to >> build their CompositeType of older version. For the current version, it >> gets it from MappedMXBeanType.toOpenType and hence no need for >> compositeType(). >> >> Otherwise, this looks good to me. >> >> >> Thanks for the review. >> >> Mandy >> >> >> best regards, >> >> -- daniel >> >> On 24/10/2018 23:53, Mandy Chung wrote: >> >> This patch fixes the regression introduced by JDK-8198253 in 11. >> It turns out that NetBeans uses the internal sun.management API to >> convert ThreadInfo to CompositeData for performance reason. >> ThreadInfoCompositeData::toCompositeData is no longer used >> in JDK since JMX added the MXBean support in JDK 6. The fix for >> JDK-8212197 resolves one issue reported [1] but not the bug in >> ThreadInfoCompositeData::toCompositeData. Sven has filed an >> issue in NetBeans to replace the use of JDK internal API. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/ >> >> Thanks >> Mandy >> [1] >> http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html >> [2] https://issues.apache.org/jira/browse/NETBEANS-1478 >> >> >> >> > > -- > 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 > > > -- 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 mandy.chung at oracle.com Thu Oct 25 18:29:11 2018 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 25 Oct 2018 11:29:11 -0700 Subject: Review Request JDK-8212795: ThreadInfoCompositeData.toCompositeData fails to map ThreadInfo to CompositeData In-Reply-To: References: <72e2a94e-cdb1-ddc5-c248-96e9b2e57591@oracle.com> <556704db-0614-4859-e61b-201ebe0c96e8@oracle.com> Message-ID: I have requested backport to 11u and pending for approval. Mandy On 10/25/18 10:16 AM, Sven Reimers wrote: > Hi Mandy, > > will this be backported to 11? > > Sven > > On Thu, Oct 25, 2018 at 10:10 AM Mandy Chung > wrote: > > Thanks for verifying the fix, Sven. > > Mandy > > On 10/25/18 10:09 AM, Sven Reimers wrote: >> Hi, >> >> jus tested the suggested fix against jdk12 head with NetBeans >> 10VC1 and self sampling works as expected. >> >> Thanks for your hard work. >> >> Sven >> >> On Thu, Oct 25, 2018 at 8:52 AM Mandy Chung >> > wrote: >> >> >> >> On 10/25/18 2:52 AM, Daniel Fuchs wrote: >>> Hi Mandy, >>> >>> I agree that this looks more robust and will be better for >>> long term maintainability. I'm just surprised that >>> >>> ?156???? static CompositeType compositeType() { >>> ?157???????? return STACK_TRACE_ELEMENT_COMPOSITE_TYPE; >>> ?158???? } >>> >>> is no longer (or was never) needed in >>> StackTraceElementCompositeData >>> when >>> >>> ?146???? static CompositeType v5CompositeType() { >>> ?147???????? return V5_COMPOSITE_TYPE; >>> ?148???? } >>> >>> appears to still be needed. >>> >> >> It's used by MonitorInfoCompositeInfo and >> ThreadInfoCompositeInfo to build their CompositeType of older >> version.? For the current version, it gets it from >> MappedMXBeanType.toOpenType and hence no need for >> compositeType(). >> >>> Otherwise, this looks good to me. >> >> Thanks for the review. >> >> Mandy >> >>> >>> best regards, >>> >>> -- daniel >>> >>> On 24/10/2018 23:53, Mandy Chung wrote: >>>> This patch fixes the regression introduced by JDK-8198253 >>>> in 11. >>>> It turns out that NetBeans uses the internal sun.management >>>> API to >>>> convert ThreadInfo to CompositeData for performance reason. >>>> ThreadInfoCompositeData::toCompositeData is no longer used >>>> in JDK since JMX added the MXBean support in JDK 6. The fix >>>> for >>>> JDK-8212197 resolves one issue reported [1] but not the bug in >>>> ThreadInfoCompositeData::toCompositeData. Sven has filed an >>>> issue in NetBeans to replace the use of JDK internal API. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212795/webrev.00/ >>>> >>>> >>>> >>>> Thanks >>>> Mandy >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-October/025512.html >>>> [2] https://issues.apache.org/jira/browse/NETBEANS-1478 >>> >> >> >> >> -- >> 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 > > > > -- > 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 leonid.mesnik at oracle.com Thu Oct 25 20:11:07 2018 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 25 Oct 2018 13:11:07 -0700 Subject: For-Test: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> <729a8616-6a66-a9d5-3876-7d1366fc5da4@oracle.com> Message-ID: Testing is still in progress, out of 30min tests passed and 8 hours tasks are still running. http://java-dev.se.oracle.com:10067/mdash/jobs/lmesnik-ks-short-test-20181025-1842-7762?search=result.status%3APASSED I haven't run any other tests. Leonid > On Oct 25, 2018, at 6:15 AM, Robbin Ehn wrote: > > Hi, here is a fix, which allows ThreadsList to be used over a VM operation. > > http://cr.openjdk.java.net/~rehn/8212933/v1_handshak_vm_cancel/webrev/ > > Please test it out. > > /Robbin > > On 10/24/18 11:16 PM, serguei.spitsyn at oracle.com wrote: >> Leonid confirmed this deadlock is not reproducible if the Kitchensink agent_sampler is disabled. >> Also, applying the patch from Robbin (with agent_sampler enabled) hit new assert >> that has caught another case in JvmtiEnv::GetStackTrace with the same pattern: >> With proposed patch issue reproduced with hs_err (file in attachement): >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:607), pid=26188, tid=26325 >> # assert(!t->have_threads_list()) failed: Deadlock if we have exiting threads and if vm thread is running an VM op. >> # >> # JRE version: Java(TM) SE Runtime Environment (12.0) (slowdebug build 12-internal+0-2018-10-24-2022348.lmesnik.hs-bigapps) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 12-internal+0-2018-10-24-2022348.lmesnik.hs-bigapps, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) >> # Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping to /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/core.26188) # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.java.com/bugreport/crash.jsp >> # >> --------------- S U M M A R Y ------------ >> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+PrintFlagsFinal -XX:+StartAttachListener -XX:NativeMemoryTracking=detail -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/java.io.tmpdir -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/user.home -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so applications.kitchensink.process.stress.Main /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/kitchensink.final.properties Host: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux Server release 7.3 >> Time: Wed Oct 24 13:28:30 2018 PDT elapsed time: 3 seconds (0d 0h 0m 3s) >> --------------- T H R E A D --------------- >> Current thread (0x00002b9f68006000): JavaThread "Jvmti-AgentSampler" daemon [_thread_in_vm, id=26325, stack(0x00002b9f88808000,0x00002b9f88909000)] _threads_hazard_ptr=0x00002b9f68008e30, _nested_threads_hazard_ptr_cnt=0 >> Stack: [0x00002b9f88808000,0x00002b9f88909000], sp=0x00002b9f88907440, free space=1021k >> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >> V [libjvm.so+0x12a04bb] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6a5 >> V [libjvm.so+0x129fdb3] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x57 >> V [libjvm.so+0x8ca5ab] report_vm_error(char const*, int, char const*, char const*, ...)+0x152 >> V [libjvm.so+0x12e485b] VMThread::execute(VM_Operation*)+0x99 >> V [libjvm.so+0xdbec54] JvmtiEnv::GetStackTrace(JavaThread*, int, int, _jvmtiFrameInfo*, int*)+0xc0 >> V [libjvm.so+0xd677cf] jvmti_GetStackTrace+0x2c2 >> C [libJvmtiStressModule.so+0x302d] trace_stack+0xa9 >> C [libJvmtiStressModule.so+0x3daf] agent_sampler+0x21f >> V [libjvm.so+0xddf595] JvmtiAgentThread::call_start_function()+0x67 >> V [libjvm.so+0xddf52a] JvmtiAgentThread::start_function_wrapper(JavaThread*, Thread*)+0xf2 >> V [libjvm.so+0x1218945] JavaThread::thread_main_inner()+0x17f >> V [libjvm.so+0x12187ad] JavaThread::run()+0x273 >> V [libjvm.so+0x100e4ee] thread_native_entry(Thread*)+0x192 >> Leonid attached the full hs_err log to the bug report. >> Thanks, >> Serguei >> On 10/24/18 02:00, serguei.spitsyn at oracle.com wrote: >>> Hi Robbin and David, >>> >>> There is no JvmtiEnv::SuspendThreadList call in the dumped stack traces. >>> But there is an instance of the JvmtiEnv::SuspendThread which seems to be supporting your theory: >>> >>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae454005800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>> #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>> #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 >>> #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at entry=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>> #5 0x00002ae393de7867 in VMThread::execute (op=op at entry=0x2ae4940ffb10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>> #6 0x00002ae393d6a3bd in JavaThread::java_suspend (this=this at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>> #7 0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend (java_thread=java_thread at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:847 >>> #8 0x00002ae3939887ae in JvmtiEnv::SuspendThread (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:955 >>> #9 0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, thread=0x2ae49929fdf8) at /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:527 >>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, env=, p=) at /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:274 >>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>> #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>> #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>> >>> >>> The JavaThread::suspend() call from the stack trace above also holds a ThreadsListHandle while executing VMThread::execute(&vm_suspend): >>> >>> void JavaThread::java_suspend() { >>> ThreadsListHandle tlh; >>> if (!tlh.includes(this) || threadObj() == NULL || is_exiting()) { >>> return; >>> } >>> >>> { MutexLockerEx ml(SR_lock(), Mutex::_no_safepoint_check_flag); >>> if (!is_external_suspend()) { >>> // a racing resume has cancelled us; bail out now >>> return; >>> } >>> >>> // suspend is done >>> uint32_t debug_bits = 0; >>> // Warning: is_ext_suspend_completed() may temporarily drop the >>> // SR_lock to allow the thread to reach a stable thread state if >>> // it is currently in a transient thread state. >>> if (is_ext_suspend_completed(false /* !called_by_wait */, >>> SuspendRetryDelay, &debug_bits)) { >>> return; >>> } >>> } >>> >>> VM_ThreadSuspend vm_suspend; >>> VMThread::execute(&vm_suspend); >>> } >>> >>> >>> I'll check with Leonid tomorrow if we can check if your patch below can fix this deadlock. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/24/18 00:18, Robbin Ehn wrote: >>>> Hi, truncate: >>>> >>>> On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>>>>> One thing I noticed which Robbin should be able to expand upon is that Thread 101 is terminating and has called ThreadsSMRSupport::smr_delete and is blocked here: >>>>>>> >>>>>>> // Wait for a release_stable_list() call before we check again. No >>>>>>> // safepoint check, no timeout, and not as suspend equivalent flag >>>>>>> // because this JavaThread is not on the Threads list. >>>>>>> ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>>> 0, !Mutex::_as_suspend_equivalent_flag); >>>>>>> >>>>>>> As the comment says this thread is no longer on the Threads_list, but the VM_HandshakeAllThreads is not a safepoint operation and does not hold the Threads_lock, so is it possible this thread was captured by the JavaThreadIteratorWithHandle being used by VM_HandshakeAllThreads, before it got removed? If so we'd be hung waiting it for it handshake as it's not in a "safepoint-safe" or suspend-equivalent state. >>>> >>>> In short: >>>> # VM Thread >>>> VM Thread is in a loop, takes Threads_lock, takes a new snapshot of the Threads_list, scans the list and process handshakes on behalf of safe threads. >>>> Releases snapshot and Threads_lock and checks if all handshakes are completed >>>> >>>> # An exiting thread >>>> A thread exiting thread removes it self from _THE_ threads list, but must stick around if it is on any snapshots of alive. When it is no on any list it will cancel the handshake. >>>> >>>> Since VM thread during the handshake takes a new snapshot every iteration any exiting can proceed since it will not be a the new snapshot. Thus cancel the handshake and VM thread can exit the loop (if this was the last handshake). >>>> >>>> Constraint: >>>> If any thread grabs a snapshot of threads list and later tries to take a lock which is 'used' by VM Thread or inside the handshake we can deadlock. >>>> >>>> Considering that looking at e.g. : JvmtiEnv::SuspendThreadList >>>> Which calls VMThread::execute(&tsj); with a ThreadsListHandle alive, this could deadlock AFAICT. Since the thread will rest on VMOperationRequest_lock with a Threads list snapshot but VM thread cannot finishes handshake until that snapshot is released. >>>> >>>> I suggest first step is to add something like this patch below and fix the obvious ones first. >>>> >>>> Note, I have not verified that is the problem you are seeing, I'm saying that this seem to be real issue. And considering how the stack traces looks, it may be this. >>>> >>>> You want me going through this, just assign a bug if there is one? >>>> >>>> /Robbin >>>> >>>> diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp >>>> --- a/src/hotspot/share/runtime/thread.hpp Tue Oct 23 13:27:41 2018 +0200 >>>> +++ b/src/hotspot/share/runtime/thread.hpp Wed Oct 24 09:13:17 2018 +0200 >>>> @@ -167,2 +167,6 @@ >>>> } >>>> + public: >>>> + bool have_threads_list(); >>>> + private: >>>> + >>>> // This field is enabled via -XX:+EnableThreadSMRStatistics: >>>> diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp >>>> --- a/src/hotspot/share/runtime/thread.inline.hpp Tue Oct 23 13:27:41 2018 +0200 >>>> +++ b/src/hotspot/share/runtime/thread.inline.hpp Wed Oct 24 09:13:17 2018 +0200 >>>> @@ -111,2 +111,6 @@ >>>> >>>> +inline bool Thread::have_threads_list() { >>>> + return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; >>>> +} >>>> + >>>> inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) { >>>> diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp >>>> --- a/src/hotspot/share/runtime/vmThread.cpp Tue Oct 23 13:27:41 2018 +0200 >>>> +++ b/src/hotspot/share/runtime/vmThread.cpp Wed Oct 24 09:13:17 2018 +0200 >>>> @@ -608,2 +608,3 @@ >>>> if (!t->is_VM_thread()) { >>>> + assert(t->have_threads_list(), "Deadlock if we have exiting threads and if vm thread is running an VM op."); // fatal/guarantee >>>> SkipGCALot sgcalot(t); // avoid re-entrant attempts to gc-a-lot >>>> >>>> >>>> >>>> >>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, skip it - sorry for the noise. >>>>>>>> It is hard to prove anything with current dump. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi David and Robbin, >>>>>>>>> >>>>>>>>> I have an idea that needs to be checked. >>>>>>>>> It can be almost the same deadlock scenario that I've already explained but more sophisticated. >>>>>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag Monitor::_safepoint_check_always does not help much. >>>>>>>>> It can be verified by checking what monitors are used by the blocked threads. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is not a safepoint operation. There's no real way to tell from the stacks what it's stuck on. >>>>>>>>>> >>>>>>>>>> I cannot find a thread that is not considered safepoint safe or is_ext_suspended (thread 146). So the handshake should go through. The handshake will log a warning after a while, is there such warning from the handshake operation? >>>>>>>>>> >>>>>>>>>> There are several threads competing with e.g. Threads_lock, and threads waiting for GC and several other VM ops, could it just be really slow? >>>>>>>>>> >>>>>>>>>> /Robbin >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> You are right, thanks. >>>>>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>> >>>>>>>>>>>>> The JvmtiThreadState_lock is always acquired with safepoint checks enabled, so all JavaThreads blocked trying to acquire it will be _thread_blocked and so safepoint-safe and so won't be holding up the safepoint. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Seems last version also crashes with 2 other different symptoms. >>>>>>>>>>>>>>> http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also it might hangs with stack attached. Seems that test might be blocked because it invoke 2 jvmti methods. Can jvmti agent invoke jvmti methods from different threads? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, in general. >>>>>>>>>>>>>> However, you have to be careful when using debugging features. >>>>>>>>>>>>>> Below, one thread is enabling single stepping while another thread is being suspended. >>>>>>>>>>>>>> Both are blocked at a safepoint which is Okay in general but not Okay if they hold any lock. >>>>>>>>>>>>>> For instance, the thread #152 is holding the monitor JvmtiThreadState. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, I see a couple of more threads that are interesting as well: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>>>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3984c9100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>> #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984c9100) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>> #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984c7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>>> #4 0x00002ae393b512c1 in lock (Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>>> #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>>> #6 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>>> #7 ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b78eb30) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>>>> #8 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method (task=task at entry=0x2ae48800ff40) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>>>> #9 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae3984c7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984c7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984c7800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>>>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3984cbb00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>> #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae3984cbb00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>> #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae3984ca800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>>> #4 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>>> #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>>> #6 0x00002ae39350510c in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>>> #7 ciEnv::cache_jvmti_state (this=this at entry=0x2ae40b88fb30) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>>>> #8 0x00002ae3935d3294 in CompileBroker::invoke_compiler_on_method (task=task at entry=0x2ae49c00a670) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 >>>>>>>>>>>>>> #9 0x00002ae3935d4f48 in CompileBroker::compiler_thread_loop () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 >>>>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae3984ca800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run (this=0x2ae3984ca800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae3984ca800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>>>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae460061c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>> #2 0x00002ae393b50920 in ParkCommon (timo=0, ev=0x2ae460061c00) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>> #3 Monitor::ILock (this=0x2ae398024f10, Self=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 >>>>>>>>>>>>>> #4 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, this=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 >>>>>>>>>>>>>> #5 Monitor::lock (this=this at entry=0x2ae398024f10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 >>>>>>>>>>>>>> #6 0x00002ae393999682 in MutexLocker (mutex=0x2ae398024f10, this=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 >>>>>>>>>>>>>> #7 thread_started (thread=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 >>>>>>>>>>>>>> #8 JvmtiEventController::thread_started (thread=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 >>>>>>>>>>>>>> #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start (thread=thread at entry=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 >>>>>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run (this=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 >>>>>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae4600c2800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> These two thread are blocked on the monitor JvmtiThreadState_lock in the function ciEnv::cache_jvmti_state(). >>>>>>>>>>>>>> Also, there are many threads (like #51) that are executing JvmtiExport::post_thread_start and blocked on the same monitor. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>>>>> What thread is blocking it? Or in reverse, what thread this safepoint is waiting for? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think, this safepoint operation is waiting for all threads that are blocked on the JvmtiThreadState_lock. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Conclusion: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The deadlock is: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thread #152: >>>>>>>>>>>>>> - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>>>>> - blocked in the VM_GetCurrentLocation in the function JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>>>>> >>>>>>>>>>>>>> Many other threads: >>>>>>>>>>>>>> - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>>>> - can not reach the blocked at a safepoint state (all threads have to reach this state for this safepoint to happen) >>>>>>>>>>>>>> >>>>>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> My guess is that this will stop to reproduce after if you turn off the single stepping for thread #152. >>>>>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make sense to integrate jvmti changes but *don't* enabled jvmti module by default. >>>>>>>>>>>>>> >>>>>>>>>>>>>> This one is a deadlock. >>>>>>>>>>>>>> However, the root cause is a race condition that can potentially result in both deadlocks and crashes. >>>>>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>>>>> So anyone could easily run them to reproduce crashes. This test would be out of CI to don't introduce any bugs. Does it make sense? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Consider hang - I think that it might be product bug since I don't see any locking on my monitors. But I am not sure. Is it possible that any my code jvmti agent prevent VM to get into safepoint? >>>>>>>>>>>>>>> Could we discuss it tomorrow or his week when you have a time? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes, of course. >>>>>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>>>>> It is non-trivial in this particular case as there are so many threads executed at the same time. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>>>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae454005800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>>> #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>>> #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>>>> 8 >>>>>>>>>>>>>>> #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>>>> try=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>>>> #5 0x00002ae393de7867 in VMThread::execute (op=op at entry=0x2ae4940ffb10) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>>>> #6 0x00002ae393d6a3bd in JavaThread::java_suspend (this=this at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>>>>>>>>>>>>> #7 0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend (java_thread=java_thread at entry=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ >>>>>>>>>>>>>>> 47 >>>>>>>>>>>>>>> #8 0x00002ae3939887ae in JvmtiEnv::SuspendThread (this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>>>>> #9 0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, thread=0x2ae49929fdf8) at /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ >>>>>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, env=, p=) at /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ >>>>>>>>>>>>>>> hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>>>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper (thread=0x2ae454004800, __the_thread__=) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>>>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner (this=this at entry=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>>>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>>>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry (thread=0x2ae454004800) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>>>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from /lib64/libpthread.so.0 >>>>>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>>>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park (this=this at entry=0x2ae3985e7400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>>>>>>>>>>>>> #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae3985e7400) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>>>>>>>>>>>>> #3 Monitor::IWait (this=this at entry=0x2ae398023c10, Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ >>>>>>>>>>>>>>> 8 >>>>>>>>>>>>>>> #4 0x00002ae393b51f2e in Monitor::wait (this=this at entry=0x2ae398023c10, no_safepoint_check=, timeout=timeout at entry=0, as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>>>> try=false) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>>>>>>>>>>>>> #5 0x00002ae393de7867 in VMThread::execute (op=0x2ae42705f500) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>>>>>>>>>>>>> #6 0x00002ae3939965f3 in JvmtiEnvThreadState::reset_current_location (this=this at entry=0x2ae6bc000d80, event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, enabled=enabled at entry=tr\ >>>>>>>>>>>>>>> ue) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 >>>>>>>>>>>>>>> #7 0x00002ae393997acf in recompute_env_thread_enabled (state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ >>>>>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>>>>> #8 JvmtiEventControllerPrivate::recompute_thread_enabled (state=state at entry=0x2ae6bc000cd0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ >>>>>>>>>>>>>>> :523 >>>>>>>>>>>>>>> #9 0x00002ae393998168 in JvmtiEventControllerPrivate::recompute_enabled () at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 >>>>>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled (enabled=true, event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, env=0x2ae39801b270) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled (env=0x2ae39801b270, thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, enabled=) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>>>>> #12 0x00002ae393987d2d in JvmtiEnv::SetEventNotificationMode (this=this at entry=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at /scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 >>>>>>>>>>>>>>> #13 0x00002ae3939414eb in jvmti_SetEventNotificationMode (env=0x2ae39801b270, mode=mode at entry=JVMTI_ENABLE, event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, event_thread=event_\ >>>>>>>>>>>>>>> thread at entry=0x0) at /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 >>>>>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at /scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 >>>>>>>>>>>>>>> #15 0x00002ae394d98070 in Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration (env=, this=) at /scratch/lmesnik/ws/h\ >>>>>>>>>>>>>>> s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 >>>>>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime Environment: >>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>> # Internal Error (/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), pid=13926, tid=13962 >>>>>>>>>>>>>>>>> # assert(_cur_stack_depth == count_frames()) failed: cur_stack_depth out of sync >>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) (fastdebug build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>>>>> # Core dump will be written. Default location: Core dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I %h" (or dumping to /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) >>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>> # If you would like to submit a bug report, please visit: >>>>>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --------------- S U M M A R Y ------------ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 -XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData -Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags -XX:+DisableExplicitGC -XX:+PrintFlagsFinal -XX:+StartAttachListener -XX:NativeMemoryTracking=detail -XX:+FlightRecorder --add-exports=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED --add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED -Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir -Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home -agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so applications.kitchensink.process.stress.Main /scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Host: scaaa118.us.oracle.com , Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle Linux Server release 7.3 >>>>>>>>>>>>>>>>> Time: Tue Oct 9 16:06:07 2018 PDT elapsed time: 31 seconds (0d 0h 0m 31s) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> --------------- T H R E A D --------------- >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): VMThread "VM Thread" [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] _threads_hazard_ptr=0x00002af4ac090eb0, _nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], sp=0x00002af44f208720, free space=1017k >>>>>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>>>>> V [libjvm.so+0x18c4923] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x2c3 >>>>>>>>>>>>>>>>> V [libjvm.so+0x18c56ef] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x2f >>>>>>>>>>>>>>>>> V [libjvm.so+0xb55aa0] report_vm_error(char const*, int, char const*, char const*, ...)+0x100 >>>>>>>>>>>>>>>>> V [libjvm.so+0x11f2cfe] JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>>>>> V [libjvm.so+0x11f3257] JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>>>>> V [libjvm.so+0x119af99] VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>>>>> V [libjvm.so+0x1908982] VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>>>>> V [libjvm.so+0x19040be] VMThread::evaluate_operation(VM_Operation*) [clone .constprop.51]+0x18e >>>>>>>>>>>>>>>>> V [libjvm.so+0x1904960] VMThread::loop()+0x4c0 >>>>>>>>>>>>>>>>> V [libjvm.so+0x1904f53] VMThread::run()+0xd3 >>>>>>>>>>>>>>>>> V [libjvm.so+0x14e8300] thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): UpdateForPopTopFrame, mode: safepoint, requested by thread 0x00002af4dc008800 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>> From robbin.ehn at oracle.com Thu Oct 25 20:24:24 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 25 Oct 2018 22:24:24 +0200 Subject: For-Test: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: References: <39a1cfd2-ee00-8bcb-430d-4b262cade4ce@oracle.com> <6FF8CDAA-B83B-4BFC-8352-CFDB282BDB0E@oracle.com> <503b1ec9-5506-5834-9555-569bde7b1bad@oracle.com> <29ab0345-d093-f9ae-1504-e7ebbc566abe@oracle.com> <3e4d58b4-1349-bc70-e0dc-3b87be2db55b@oracle.com> <2346d330-32c7-3ed3-eb0d-c8333e0337e5@oracle.com> <89b16600-34f2-2408-ac0d-ef96b3800671@oracle.com> <6bfafaf4-cfe7-bc2e-cc75-0e14adddf792@oracle.com> <3c003089-c29d-e263-01cb-20dc9bb17835@oracle.com> <47199978-0e32-7b7c-6912-c153951421f8@oracle.com> <7015404c-1977-c1f0-6a94-5ed444c93975@oracle.com> <729a8616-6a66-a9d5-3876-7d1366fc5da4@oracle.com> Message-ID: Great, thanks. I did some local stress tests and t1-5. I'll rfr it tomorrow if KS passes. /Robbin Leonid Mesnik skrev: (25 oktober 2018 22:11:07 CEST) >Testing is still in progress, out of 30min tests passed and 8 hours >tasks are still running. >http://java-dev.se.oracle.com:10067/mdash/jobs/lmesnik-ks-short-test-20181025-1842-7762?search=result.status%3APASSED > >I haven't run any other tests. > >Leonid >> On Oct 25, 2018, at 6:15 AM, Robbin Ehn >wrote: >> >> Hi, here is a fix, which allows ThreadsList to be used over a VM >operation. >> >> >http://cr.openjdk.java.net/~rehn/8212933/v1_handshak_vm_cancel/webrev/ >> >> Please test it out. >> >> /Robbin >> >> On 10/24/18 11:16 PM, serguei.spitsyn at oracle.com wrote: >>> Leonid confirmed this deadlock is not reproducible if the >Kitchensink agent_sampler is disabled. >>> Also, applying the patch from Robbin (with agent_sampler enabled) >hit new assert >>> that has caught another case in JvmtiEnv::GetStackTrace with the >same pattern: >>> With proposed patch issue reproduced with hs_err (file in >attachement): >>> # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error >(/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:607), >pid=26188, tid=26325 >>> # assert(!t->have_threads_list()) failed: Deadlock if we have >exiting threads and if vm thread is running an VM op. >>> # >>> # JRE version: Java(TM) SE Runtime Environment (12.0) (slowdebug >build 12-internal+0-2018-10-24-2022348.lmesnik.hs-bigapps) >>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug >12-internal+0-2018-10-24-2022348.lmesnik.hs-bigapps, mixed mode, >sharing, tiered, compressed oops, g1 gc, linux-amd64) >>> # Core dump will be written. Default location: Core dumps may be >processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e %P %I >%h" (or dumping to >/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/core.26188) ># >>> # If you would like to submit a bug report, please visit: >>> # http://bugreport.java.com/bugreport/crash.jsp >>> # >>> --------------- S U M M A R Y ------------ >>> Command Line: -XX:MaxRAMPercentage=2 -XX:MaxRAMPercentage=50 >-XX:+CrashOnOutOfMemoryError -Djava.net.preferIPv6Addresses=false >-XX:-PrintVMOptions -XX:+DisplayVMOutputToStderr -XX:+UsePerfData >-Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >-XX:+DisableExplicitGC -XX:+PrintFlagsFinal -XX:+StartAttachListener >-XX:NativeMemoryTracking=detail -XX:+FlightRecorder >--add-exports=java.base/java.lang=ALL-UNNAMED >--add-opens=java.base/java.lang=ALL-UNNAMED >--add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >--add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >-Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/java.io.tmpdir >-Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/user.home >-agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >applications.kitchensink.process.stress.Main >/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSampler_java/scratch/0/kitchensink.final.properties >Host: Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz, 32 cores, 235G, Oracle >Linux Server release 7.3 >>> Time: Wed Oct 24 13:28:30 2018 PDT elapsed time: 3 seconds (0d 0h 0m >3s) >>> --------------- T H R E A D --------------- >>> Current thread (0x00002b9f68006000): JavaThread "Jvmti-AgentSampler" >daemon [_thread_in_vm, id=26325, >stack(0x00002b9f88808000,0x00002b9f88909000)] >_threads_hazard_ptr=0x00002b9f68008e30, >_nested_threads_hazard_ptr_cnt=0 >>> Stack: [0x00002b9f88808000,0x00002b9f88909000], >sp=0x00002b9f88907440, free space=1021k >>> Native frames: (J=compiled Java code, A=aot compiled Java code, >j=interpreted, Vv=VM code, C=native code) >>> V [libjvm.so+0x12a04bb] VMError::report_and_die(int, char const*, >char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, >char const*, int, unsigned long)+0x6a5 >>> V [libjvm.so+0x129fdb3] VMError::report_and_die(Thread*, void*, char >const*, int, char const*, char const*, __va_list_tag*)+0x57 >>> V [libjvm.so+0x8ca5ab] report_vm_error(char const*, int, char >const*, char const*, ...)+0x152 >>> V [libjvm.so+0x12e485b] VMThread::execute(VM_Operation*)+0x99 >>> V [libjvm.so+0xdbec54] JvmtiEnv::GetStackTrace(JavaThread*, int, >int, _jvmtiFrameInfo*, int*)+0xc0 >>> V [libjvm.so+0xd677cf] jvmti_GetStackTrace+0x2c2 >>> C [libJvmtiStressModule.so+0x302d] trace_stack+0xa9 >>> C [libJvmtiStressModule.so+0x3daf] agent_sampler+0x21f >>> V [libjvm.so+0xddf595] JvmtiAgentThread::call_start_function()+0x67 >>> V [libjvm.so+0xddf52a] >JvmtiAgentThread::start_function_wrapper(JavaThread*, Thread*)+0xf2 >>> V [libjvm.so+0x1218945] JavaThread::thread_main_inner()+0x17f >>> V [libjvm.so+0x12187ad] JavaThread::run()+0x273 >>> V [libjvm.so+0x100e4ee] thread_native_entry(Thread*)+0x192 >>> Leonid attached the full hs_err log to the bug report. >>> Thanks, >>> Serguei >>> On 10/24/18 02:00, serguei.spitsyn at oracle.com wrote: >>>> Hi Robbin and David, >>>> >>>> There is no JvmtiEnv::SuspendThreadList call in the dumped stack >traces. >>>> But there is an instance of the JvmtiEnv::SuspendThread which seems >to be supporting your theory: >>>> >>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 () from >/lib64/libpthread.so.0 >>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park >(this=this at entry=0x2ae454005800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 >>>> #2 0x00002ae393b50cf8 in ParkCommon (timo=0, ev=0x2ae454005800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 >>>> #3 Monitor::IWait (this=this at entry=0x2ae398023c10, >Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:768 >>>> #4 0x00002ae393b51f2e in Monitor::wait >(this=this at entry=0x2ae398023c10, no_safepoint_check=, >timeout=timeout at entry=0, >as_suspend_equivalent=as_suspend_equivalent at entry=false) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 >>>> #5 0x00002ae393de7867 in VMThread::execute >(op=op at entry=0x2ae4940ffb10) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 >>>> #6 0x00002ae393d6a3bd in JavaThread::java_suspend >(this=this at entry=0x2ae3985f2000) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 >>>> #7 0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >(java_thread=java_thread at entry=0x2ae3985f2000) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:847 >>>> #8 0x00002ae3939887ae in JvmtiEnv::SuspendThread >(this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:955 >>>> #9 0x00002ae39393a8c6 in jvmti_SuspendThread (env=0x2ae39801b270, >thread=0x2ae49929fdf8) at >/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:527 > >>>> #10 0x00002ae394d973ee in agent_sampler (jvmti=0x2ae39801b270, >env=, p=) at >/scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:274 > >>>> #11 0x00002ae3939ab24d in call_start_function (this=0x2ae454004800) >at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 >>>> #12 JvmtiAgentThread::start_function_wrapper >(thread=0x2ae454004800, __the_thread__=) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 >>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >(this=this at entry=0x2ae454004800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 >>>> #14 0x00002ae393d736c6 in JavaThread::run (this=0x2ae454004800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 >>>> #15 0x00002ae393ba0070 in thread_native_entry >(thread=0x2ae454004800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 >>>> #16 0x00002ae3927b1e25 in start_thread () from >/lib64/libpthread.so.0 >>>> #17 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>> >>>> >>>> The JavaThread::suspend() call from the stack trace above also >holds a ThreadsListHandle while executing >VMThread::execute(&vm_suspend): >>>> >>>> void JavaThread::java_suspend() { >>>> ThreadsListHandle tlh; >>>> if (!tlh.includes(this) || threadObj() == NULL || is_exiting()) { >>>> return; >>>> } >>>> >>>> { MutexLockerEx ml(SR_lock(), Mutex::_no_safepoint_check_flag); >>>> if (!is_external_suspend()) { >>>> // a racing resume has cancelled us; bail out now >>>> return; >>>> } >>>> >>>> // suspend is done >>>> uint32_t debug_bits = 0; >>>> // Warning: is_ext_suspend_completed() may temporarily drop the >>>> // SR_lock to allow the thread to reach a stable thread state >if >>>> // it is currently in a transient thread state. >>>> if (is_ext_suspend_completed(false /* !called_by_wait */, >>>> SuspendRetryDelay, &debug_bits)) { >>>> return; >>>> } >>>> } >>>> >>>> VM_ThreadSuspend vm_suspend; >>>> VMThread::execute(&vm_suspend); >>>> } >>>> >>>> >>>> I'll check with Leonid tomorrow if we can check if your patch below >can fix this deadlock. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/24/18 00:18, Robbin Ehn wrote: >>>>> Hi, truncate: >>>>> >>>>> On 24/10/2018 02:00, serguei.spitsyn at oracle.com wrote: >>>>>>>> One thing I noticed which Robbin should be able to expand upon >is that Thread 101 is terminating and has called >ThreadsSMRSupport::smr_delete and is blocked here: >>>>>>>> >>>>>>>> // Wait for a release_stable_list() call before we check >again. No >>>>>>>> // safepoint check, no timeout, and not as suspend equivalent >flag >>>>>>>> // because this JavaThread is not on the Threads list. >>>>>>>> >ThreadsSMRSupport::delete_lock()->wait(Mutex::_no_safepoint_check_flag, >>>>>>>> 0, >!Mutex::_as_suspend_equivalent_flag); >>>>>>>> >>>>>>>> As the comment says this thread is no longer on the >Threads_list, but the VM_HandshakeAllThreads is not a safepoint >operation and does not hold the Threads_lock, so is it possible this >thread was captured by the JavaThreadIteratorWithHandle being used by >VM_HandshakeAllThreads, before it got removed? If so we'd be hung >waiting it for it handshake as it's not in a "safepoint-safe" or >suspend-equivalent state. >>>>> >>>>> In short: >>>>> # VM Thread >>>>> VM Thread is in a loop, takes Threads_lock, takes a new snapshot >of the Threads_list, scans the list and process handshakes on behalf of >safe threads. >>>>> Releases snapshot and Threads_lock and checks if all handshakes >are completed >>>>> >>>>> # An exiting thread >>>>> A thread exiting thread removes it self from _THE_ threads list, >but must stick around if it is on any snapshots of alive. When it is no >on any list it will cancel the handshake. >>>>> >>>>> Since VM thread during the handshake takes a new snapshot every >iteration any exiting can proceed since it will not be a the new >snapshot. Thus cancel the handshake and VM thread can exit the loop (if >this was the last handshake). >>>>> >>>>> Constraint: >>>>> If any thread grabs a snapshot of threads list and later tries to >take a lock which is 'used' by VM Thread or inside the handshake we can >deadlock. >>>>> >>>>> Considering that looking at e.g. : JvmtiEnv::SuspendThreadList >>>>> Which calls VMThread::execute(&tsj); with a ThreadsListHandle >alive, this could deadlock AFAICT. Since the thread will rest on >VMOperationRequest_lock with a Threads list snapshot but VM thread >cannot finishes handshake until that snapshot is released. >>>>> >>>>> I suggest first step is to add something like this patch below and >fix the obvious ones first. >>>>> >>>>> Note, I have not verified that is the problem you are seeing, I'm >saying that this seem to be real issue. And considering how the stack >traces looks, it may be this. >>>>> >>>>> You want me going through this, just assign a bug if there is one? >>>>> >>>>> /Robbin >>>>> >>>>> diff -r 622fd3608374 src/hotspot/share/runtime/thread.hpp >>>>> --- a/src/hotspot/share/runtime/thread.hpp Tue Oct 23 13:27:41 >2018 +0200 >>>>> +++ b/src/hotspot/share/runtime/thread.hpp Wed Oct 24 09:13:17 >2018 +0200 >>>>> @@ -167,2 +167,6 @@ >>>>> } >>>>> + public: >>>>> + bool have_threads_list(); >>>>> + private: >>>>> + >>>>> // This field is enabled via -XX:+EnableThreadSMRStatistics: >>>>> diff -r 622fd3608374 src/hotspot/share/runtime/thread.inline.hpp >>>>> --- a/src/hotspot/share/runtime/thread.inline.hpp Tue Oct 23 >13:27:41 2018 +0200 >>>>> +++ b/src/hotspot/share/runtime/thread.inline.hpp Wed Oct 24 >09:13:17 2018 +0200 >>>>> @@ -111,2 +111,6 @@ >>>>> >>>>> +inline bool Thread::have_threads_list() { >>>>> + return OrderAccess::load_acquire(&_threads_hazard_ptr) != NULL; >>>>> +} >>>>> + >>>>> inline void Thread::set_threads_hazard_ptr(ThreadsList* new_list) >{ >>>>> diff -r 622fd3608374 src/hotspot/share/runtime/vmThread.cpp >>>>> --- a/src/hotspot/share/runtime/vmThread.cpp Tue Oct 23 >13:27:41 2018 +0200 >>>>> +++ b/src/hotspot/share/runtime/vmThread.cpp Wed Oct 24 >09:13:17 2018 +0200 >>>>> @@ -608,2 +608,3 @@ >>>>> if (!t->is_VM_thread()) { >>>>> + assert(t->have_threads_list(), "Deadlock if we have exiting >threads and if vm thread is running an VM op."); // fatal/guarantee >>>>> SkipGCALot sgcalot(t); // avoid re-entrant attempts to >gc-a-lot >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> On 24/10/2018 9:18 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, skip it - sorry for the noise. >>>>>>>>> It is hard to prove anything with current dump. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> On 10/23/18 9:09 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi David and Robbin, >>>>>>>>>> >>>>>>>>>> I have an idea that needs to be checked. >>>>>>>>>> It can be almost the same deadlock scenario that I've already >explained but more sophisticated. >>>>>>>>>> I suspect a scenario with JvmtiThreadState_lock that the flag >Monitor::_safepoint_check_always does not help much. >>>>>>>>>> It can be verified by checking what monitors are used by the >blocked threads. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/23/18 07:38, Robbin Ehn wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 10/23/18 10:34 AM, David Holmes wrote: >>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>> >>>>>>>>>>>> The VMThread is executing VM_HandshakeAllThreads which is >not a safepoint operation. There's no real way to tell from the stacks >what it's stuck on. >>>>>>>>>>> >>>>>>>>>>> I cannot find a thread that is not considered safepoint safe >or is_ext_suspended (thread 146). So the handshake should go through. >The handshake will log a warning after a while, is there such warning >from the handshake operation? >>>>>>>>>>> >>>>>>>>>>> There are several threads competing with e.g. Threads_lock, >and threads waiting for GC and several other VM ops, could it just be >really slow? >>>>>>>>>>> >>>>>>>>>>> /Robbin >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 23/10/2018 5:58 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> You are right, thanks. >>>>>>>>>>>>> It means, this deadlock needs more analysis. >>>>>>>>>>>>> For completeness, the stack traces are in attachments. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/23/18 00:43, David Holmes wrote: >>>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The JvmtiThreadState_lock is always acquired with >safepoint checks enabled, so all JavaThreads blocked trying to acquire >it will be _thread_blocked and so safepoint-safe and so won't be >holding up the safepoint. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 23/10/2018 5:21 PM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've added the seviceability-dev mailing list. >>>>>>>>>>>>>>> It can be interesting for the SVC folks. :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 10/22/18 22:14, Leonid Mesnik wrote: >>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Seems last version also crashes with 2 other different >symptoms. >>>>>>>>>>>>>>>> >http://java.se.oracle.com:10065/mdash/jobs/lmesnik-ks8-20181021-0638-7157/results?search=status%3Afailed+AND+-state%3Ainvalid > > >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also it might hangs with stack attached. Seems that >test might be blocked because it invoke 2 jvmti methods. Can jvmti >agent invoke jvmti methods from different threads? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, in general. >>>>>>>>>>>>>>> However, you have to be careful when using debugging >features. >>>>>>>>>>>>>>> Below, one thread is enabling single stepping while >another thread is being suspended. >>>>>>>>>>>>>>> Both are blocked at a safepoint which is Okay in general >but not Okay if they hold any lock. >>>>>>>>>>>>>>> For instance, the thread #152 is holding the monitor >JvmtiThreadState. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Also, I see a couple of more threads that are >interesting as well: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thread 159 (Thread 0x2ae40b78f700 (LWP 27962)): >>>>>>>>>>>>>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 >() from /lib64/libpthread.so.0 >>>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park >(this=this at entry=0x2ae3984c9100) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > >>>>>>>>>>>>>>> #2 0x00002ae393b50920 in ParkCommon (timo=0, >ev=0x2ae3984c9100) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > >>>>>>>>>>>>>>> #3 Monitor::ILock (this=0x2ae398024f10, >Self=0x2ae3984c7800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 > >>>>>>>>>>>>>>> #4 0x00002ae393b512c1 in lock >(Self=0x2ae3984c7is_ext_suspended800, this=0x2ae398024f10) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 > >>>>>>>>>>>>>>> #5 Monitor::lock (this=this at entry=0x2ae398024f10) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 > >>>>>>>>>>>>>>> #6 0x00002ae39350510c in MutexLocker >(mutex=0x2ae398024f10, this=) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 > >>>>>>>>>>>>>>> #7 ciEnv::cache_jvmti_state >(this=this at entry=0x2ae40b78eb30) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>>>>> #8 0x00002ae3935d3294 in >CompileBroker::invoke_compiler_on_method >(task=task at entry=0x2ae48800ff40) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 > >>>>>>>>>>>>>>> #9 0x00002ae3935d4f48 in >CompileBroker::compiler_thread_loop () at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 > >>>>>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >(this=this at entry=0x2ae3984c7800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 > >>>>>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >(this=0x2ae3984c7800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 > >>>>>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >(thread=0x2ae3984c7800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 > >>>>>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >/lib64/libpthread.so.0 >>>>>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thread 158 (Thread 0x2ae40b890700 (LWP 27963)): >>>>>>>>>>>>>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 >() from /lib64/libpthread.so.0 >>>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park >(this=this at entry=0x2ae3984cbb00) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > >>>>>>>>>>>>>>> #2 0x00002ae393b50920 in ParkCommon (timo=0, >ev=0x2ae3984cbb00) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > >>>>>>>>>>>>>>> #3 Monitor::ILock (this=0x2ae398024f10, >Self=0x2ae3984ca800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 > >>>>>>>>>>>>>>> #4 0x00002ae393b512c1 in lock (Self=0x2ae3984ca800, >this=0x2ae398024f10) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 > >>>>>>>>>>>>>>> #5 Monitor::lock (this=this at entry=0x2ae398024f10) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 > >>>>>>>>>>>>>>> #6 0x00002ae39350510c in MutexLocker >(mutex=0x2ae398024f10, this=) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 > >>>>>>>>>>>>>>> #7 ciEnv::cache_jvmti_state >(this=this at entry=0x2ae40b88fb30) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/ci/ciEnv.cpp:229 >>>>>>>>>>>>>>> #8 0x00002ae3935d3294 in >CompileBroker::invoke_compiler_on_method >(task=task at entry=0x2ae49c00a670) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:2084 > >>>>>>>>>>>>>>> #9 0x00002ae3935d4f48 in >CompileBroker::compiler_thread_loop () at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/compiler/compileBroker.cpp:1798 > >>>>>>>>>>>>>>> #10 0x00002ae393d7338a in JavaThread::thread_main_inner >(this=this at entry=0x2ae3984ca800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 > >>>>>>>>>>>>>>> #11 0x00002ae393d736c6 in JavaThread::run >(this=0x2ae3984ca800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 > >>>>>>>>>>>>>>> #12 0x00002ae393ba0070 in thread_native_entry >(thread=0x2ae3984ca800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 > >>>>>>>>>>>>>>> #13 0x00002ae3927b1e25 in start_thread () from >/lib64/libpthread.so.0 >>>>>>>>>>>>>>> #14 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thread 51 (Thread 0x2ae49549b700 (LWP 29678)): >>>>>>>>>>>>>>> #0 0x00002ae3927b5945 in pthread_cond_wait@@GLIBC_2.3.2 >() from /lib64/libpthread.so.0 >>>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park >(this=this at entry=0x2ae460061c00) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > >>>>>>>>>>>>>>> #2 0x00002ae393b50920 in ParkCommon (timo=0, >ev=0x2ae460061c00) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > >>>>>>>>>>>>>>> #3 Monitor::ILock (this=0x2ae398024f10, >Self=0x2ae4600c2800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:461 > >>>>>>>>>>>>>>> #4 0x00002ae393b512c1 in lock (Self=0x2ae4600c2800, >this=0x2ae398024f10) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:910 > >>>>>>>>>>>>>>> #5 Monitor::lock (this=this at entry=0x2ae398024f10) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:919 > >>>>>>>>>>>>>>> #6 0x00002ae393999682 in MutexLocker >(mutex=0x2ae398024f10, this=) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutexLocker.hpp:182 > >>>>>>>>>>>>>>> #7 thread_started (thread=0x2ae4600c2800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:668 > >>>>>>>>>>>>>>> #8 JvmtiEventController::thread_started >(thread=0x2ae4600c2800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:1027 > >>>>>>>>>>>>>>> #9 0x00002ae39399f3a0 in JvmtiExport::post_thread_start >(thread=thread at entry=0x2ae4600c2800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiExport.cpp:1395 > >>>>>>>>>>>>>>> #10 0x00002ae393d737d8 in JavaThread::run >(this=0x2ae4600c2800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1764 > >>>>>>>>>>>>>>> #11 0x00002ae393ba0070 in thread_native_entry >(thread=0x2ae4600c2800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 > >>>>>>>>>>>>>>> #12 0x00002ae3927b1e25 in start_thread () from >/lib64/libpthread.so.0 >>>>>>>>>>>>>>> #13 0x00002ae392cc234d in clone () from /lib64/libc.so.6 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> These two thread are blocked on the monitor >JvmtiThreadState_lock in the function ciEnv::cache_jvmti_state(). >>>>>>>>>>>>>>> Also, there are many threads (like #51) that are >executing JvmtiExport::post_thread_start and blocked on the same >monitor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now, the question is why this safepoint can not start? >>>>>>>>>>>>>>> What thread is blocking it? Or in reverse, what thread >this safepoint is waiting for? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think, this safepoint operation is waiting for all >threads that are blocked on the JvmtiThreadState_lock. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Conclusion: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The deadlock is: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thread #152: >>>>>>>>>>>>>>> - grabbed the monitor JvmtiThreadState_lock >>>>>>>>>>>>>>> - blocked in the VM_GetCurrentLocation in the >function JvmtiEnvThreadState::reset_current_location() >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Many other threads: >>>>>>>>>>>>>>> - blocked on the monitor JvmtiThreadState_lock >>>>>>>>>>>>>>> - can not reach the blocked at a safepoint state (all >threads have to reach this state for this safepoint to happen) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems to me, this is a bug which has to be filed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> My guess is that this will stop to reproduce after if >you turn off the single stepping for thread #152. >>>>>>>>>>>>>>> Please, let me know about the results. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Assuming that crashes look like VM bugs I think it make >sense to integrate jvmti changes but *don't* enabled jvmti module by >default. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This one is a deadlock. >>>>>>>>>>>>>>> However, the root cause is a race condition that can >potentially result in both deadlocks and crashes. >>>>>>>>>>>>>>> So, I'm curious if you observed crashes as well. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And add to more tests with jvmti enabled. >>>>>>>>>>>>>>>> So anyone could easily run them to reproduce crashes. >This test would be out of CI to don't introduce any bugs. Does it make >sense? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Consider hang - I think that it might be product bug >since I don't see any locking on my monitors. But I am not sure. Is it >possible that any my code jvmti agent prevent VM to get into safepoint? >>>>>>>>>>>>>>>> Could we discuss it tomorrow or his week when you have >a time? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, of course. >>>>>>>>>>>>>>> Let's find some time tomorrow. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any suggestion how to diagnose deadlock would be great. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Analysis of stack traces is needed. >>>>>>>>>>>>>>> It is non-trivial in this particular case as there are >so many threads executed at the same time. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Part of stack trace with 2 my threads only: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thread 136 (Thread 0x2ae494100700 (LWP 28023)): >>>>>>>>>>>>>>>> #0 0x00002ae3927b5945 in >pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>>>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park >(this=this at entry=0x2ae454005800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > >>>>>>>>>>>>>>>> #2 0x00002ae393b50cf8 in ParkCommon (timo=0, >ev=0x2ae454005800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > >>>>>>>>>>>>>>>> #3 Monitor::IWait (this=this at entry=0x2ae398023c10, >Self=Self at entry=0x2ae454004800, timo=timo at entry=0) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ > >>>>>>>>>>>>>>>> 8 >>>>>>>>>>>>>>>> #4 0x00002ae393b51f2e in Monitor::wait >(this=this at entry=0x2ae398023c10, no_safepoint_check=, >timeout=timeout at entry=0, >as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>>>>> try=false) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 > >>>>>>>>>>>>>>>> #5 0x00002ae393de7867 in VMThread::execute >(op=op at entry=0x2ae4940ffb10) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 > >>>>>>>>>>>>>>>> #6 0x00002ae393d6a3bd in JavaThread::java_suspend >(this=this at entry=0x2ae3985f2000) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:2321 > >>>>>>>>>>>>>>>> #7 0x00002ae3939ad7e1 in JvmtiSuspendControl::suspend >(java_thread=java_thread at entry=0x2ae3985f2000) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:8\ > >>>>>>>>>>>>>>>> 47 >>>>>>>>>>>>>>>> #8 0x00002ae3939887ae in JvmtiEnv::SuspendThread >(this=this at entry=0x2ae39801b270, java_thread=0x2ae3985f2000) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiE\ >>>>>>>>>>>>>>>> nv.cpp:955 >>>>>>>>>>>>>>>> #9 0x00002ae39393a8c6 in jvmti_SuspendThread >(env=0x2ae39801b270, thread=0x2ae49929fdf8) at >/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles\ > >>>>>>>>>>>>>>>> /jvmtiEnter.cpp:527 >>>>>>>>>>>>>>>> #10 0x00002ae394d973ee in agent_sampler >(jvmti=0x2ae39801b270, env=, p=) at >/scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitc\ > >>>>>>>>>>>>>>>> >hensink/process/stress/modules/libJvmtiStressModule.c:274 >>>>>>>>>>>>>>>> #11 0x00002ae3939ab24d in call_start_function >(this=0x2ae454004800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:85 > >>>>>>>>>>>>>>>> #12 JvmtiAgentThread::start_function_wrapper >(thread=0x2ae454004800, __the_thread__=) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiImpl.cpp:79 > >>>>>>>>>>>>>>>> #13 0x00002ae393d7338a in JavaThread::thread_main_inner >(this=this at entry=0x2ae454004800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1795 > >>>>>>>>>>>>>>>> #14 0x00002ae393d736c6 in JavaThread::run >(this=0x2ae454004800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/thread.cpp:1775 > >>>>>>>>>>>>>>>> #15 0x00002ae393ba0070 in thread_native_entry >(thread=0x2ae454004800) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/linux/os_linux.cpp:698 > >>>>>>>>>>>>>>>> #16 0x00002ae3927b1e25 in start_thread () from >/lib64/libpthread.so.0 >>>>>>>>>>>>>>>> #17 0x00002ae392cc234d in clone () from >/lib64/libc.so.6 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thread 152 (Thread 0x2ae427060700 (LWP 27995)): >>>>>>>>>>>>>>>> #0 0x00002ae3927b5945 in >pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 >>>>>>>>>>>>>>>> #1 0x00002ae393ba8d63 in os::PlatformEvent::park >(this=this at entry=0x2ae3985e7400) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/os/posix/os_posix.cpp:1897 > >>>>>>>>>>>>>>>> #2 0x00002ae393b50cf8 in ParkCommon (timo=0, >ev=0x2ae3985e7400) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:399 > >>>>>>>>>>>>>>>> #3 Monitor::IWait (this=this at entry=0x2ae398023c10, >Self=Self at entry=0x2ae3985e6000, timo=timo at entry=0) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:76\ > >>>>>>>>>>>>>>>> 8 >>>>>>>>>>>>>>>> #4 0x00002ae393b51f2e in Monitor::wait >(this=this at entry=0x2ae398023c10, no_safepoint_check=, >timeout=timeout at entry=0, >as_suspend_equivalent=as_suspend_equivalent at en\ >>>>>>>>>>>>>>>> try=false) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/mutex.cpp:1106 > >>>>>>>>>>>>>>>> #5 0x00002ae393de7867 in VMThread::execute >(op=0x2ae42705f500) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/runtime/vmThread.cpp:657 > >>>>>>>>>>>>>>>> #6 0x00002ae3939965f3 in >JvmtiEnvThreadState::reset_current_location >(this=this at entry=0x2ae6bc000d80, >event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >enabled=enabled at entry=tr\ >>>>>>>>>>>>>>>> ue) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnvThreadState.cpp:312 > >>>>>>>>>>>>>>>> #7 0x00002ae393997acf in recompute_env_thread_enabled >(state=0x2ae6bc000cd0, ets=0x2ae6bc000d80) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventControlle\ > >>>>>>>>>>>>>>>> r.cpp:490 >>>>>>>>>>>>>>>> #8 >JvmtiEventControllerPrivate::recompute_thread_enabled >(state=state at entry=0x2ae6bc000cd0) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp\ > >>>>>>>>>>>>>>>> :523 >>>>>>>>>>>>>>>> #9 0x00002ae393998168 in >JvmtiEventControllerPrivate::recompute_enabled () at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEventController.cpp:598 > >>>>>>>>>>>>>>>> #10 0x00002ae39399a244 in set_user_enabled >(enabled=true, event_type=JVMTI_EVENT_SINGLE_STEP, thread=0x0, >env=0x2ae39801b270) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/sha\ >>>>>>>>>>>>>>>> re/prims/jvmtiEventController.cpp:818 >>>>>>>>>>>>>>>> #11 JvmtiEventController::set_user_enabled >(env=0x2ae39801b270, thread=0x0, event_type=JVMTI_EVENT_SINGLE_STEP, >enabled=) at /scratch/lmesnik/ws/hs-bigapps/open/src/\ >>>>>>>>>>>>>>>> hotspot/share/prims/jvmtiEventController.cpp:963 >>>>>>>>>>>>>>>> #12 0x00002ae393987d2d in >JvmtiEnv::SetEventNotificationMode (this=this at entry=0x2ae39801b270, >mode=mode at entry=JVMTI_ENABLE, >event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, eve\ >>>>>>>>>>>>>>>> nt_thread=event_thread at entry=0x0) at >/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiEnv.cpp:543 > >>>>>>>>>>>>>>>> #13 0x00002ae3939414eb in >jvmti_SetEventNotificationMode (env=0x2ae39801b270, >mode=mode at entry=JVMTI_ENABLE, >event_type=event_type at entry=JVMTI_EVENT_SINGLE_STEP, >event_thread=event_\ >>>>>>>>>>>>>>>> thread at entry=0x0) at >/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp:5389 > >>>>>>>>>>>>>>>> #14 0x00002ae394d97989 in enable_events () at >/scratch/lmesnik/ws/hs-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:519 > >>>>>>>>>>>>>>>> #15 0x00002ae394d98070 in >Java_applications_kitchensink_process_stress_modules_JvmtiStressModule_startIteration >(env=, this=) at /scratch/lmesnik/ws/h\ >>>>>>>>>>>>>>>> >s-bigapps/closed/test/hotspot/jtreg/applications/kitchensink/process/stress/modules/libJvmtiStressModule.c:697 > >>>>>>>>>>>>>>>> #16 0x00002ae3a43ef257 in ?? () >>>>>>>>>>>>>>>> #17 0x00002ae3a43eede1 in ?? () >>>>>>>>>>>>>>>> #18 0x00002ae42705f878 in ?? () >>>>>>>>>>>>>>>> #19 0x00002ae40ad334e0 in ?? () >>>>>>>>>>>>>>>> #20 0x00002ae42705f8e0 in ?? () >>>>>>>>>>>>>>>> #21 0x00002ae40ad33c68 in ?? () >>>>>>>>>>>>>>>> #22 0x0000000000000000 in ?? () >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Oct 9, 2018, at 4:52 PM, serguei.spitsyn at oracle.com > wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Leonid, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is an existing bug: >>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8043571 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Serguei >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 10/9/18 16:11, Leonid Mesnik wrote: >>>>>>>>>>>>>>>>>> Hi >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> During fixing kitchensink I get >>>>>>>>>>>>>>>>>> assert(_cur_stack_depth == count_frames()) failed: >cur_stack_depth out of sync >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Do you know if i might be bug in my jvmti agent? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Leonid >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>>> # A fatal error has been detected by the Java Runtime >Environment: >>>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>>> # Internal Error >(/scratch/lmesnik/ws/hs-bigapps/open/src/hotspot/share/prims/jvmtiThreadState.cpp:277), >pid=13926, tid=13962 >>>>>>>>>>>>>>>>>> # assert(_cur_stack_depth == count_frames()) failed: >cur_stack_depth out of sync >>>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>>> # JRE version: Java(TM) SE Runtime Environment (12.0) >(fastdebug build 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps) >>>>>>>>>>>>>>>>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM >(fastdebug 12-internal+0-2018-10-08-2342517.lmesnik.hs-bigapps, mixed >mode, tiered, compressed oops, g1 gc, linux-amd64) >>>>>>>>>>>>>>>>>> # Core dump will be written. Default location: Core >dumps may be processed with "/usr/libexec/abrt-hook-ccpp %s %c %p %u %g >%t e %P %I %h" (or dumping to >/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/core.13926) > >>>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>>> # If you would like to submit a bug report, please >visit: >>>>>>>>>>>>>>>>>> # http://bugreport.java.com/bugreport/crash.jsp >>>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> --------------- S U M M A R Y ------------ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Command Line: -XX:MaxRAMPercentage=2 >-XX:MaxRAMPercentage=50 -XX:+CrashOnOutOfMemoryError >-Djava.net.preferIPv6Addresses=false -XX:-PrintVMOptions >-XX:+DisplayVMOutputToStderr -XX:+UsePerfData >-Xlog:gc*,gc+heap=debug:gc.log:uptime,timemillis,level,tags >-XX:+DisableExplicitGC -XX:+PrintFlagsFinal -XX:+StartAttachListener >-XX:NativeMemoryTracking=detail -XX:+FlightRecorder >--add-exports=java.base/java.lang=ALL-UNNAMED >--add-opens=java.base/java.lang=ALL-UNNAMED >--add-exports=java.xml/com.sun.org.apache.xerces.internal.parsers=ALL-UNNAMED >--add-exports=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED >-Djava.io.tmpdir=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/java.io.tmpdir >-Duser.home=/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/user.home >-agentpath:/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/images/test/hotspot/jtreg/native/libJvmtiStressModule.so >applications.kitchensink.process.stress.Main >/scratch/lmesnik/ws/hs-bigapps/build/linux-x64/test-support/jtreg_closed_test_hotspot_jtreg_applications_kitchensink_KitchensinkSanity_java/scratch/0/kitchensink.final.properties > >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Host: scaaa118.us.oracle.com >, Intel(R) Xeon(R) CPU E5-2690 0 @ >2.90GHz, 32 cores, 235G, Oracle Linux Server release 7.3 >>>>>>>>>>>>>>>>>> Time: Tue Oct 9 16:06:07 2018 PDT elapsed time: 31 >seconds (0d 0h 0m 31s) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> --------------- T H R E A D --------------- >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Current thread (0x00002af3dc6ac800): VMThread "VM >Thread" [stack: 0x00002af44f10a000,0x00002af44f20a000] [id=13962] >_threads_hazard_ptr=0x00002af4ac090eb0, >_nested_threads_hazard_ptr_cnt=0 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Stack: [0x00002af44f10a000,0x00002af44f20a000], >sp=0x00002af44f208720, free space=1017k >>>>>>>>>>>>>>>>>> Native frames: (J=compiled Java code, A=aot compiled >Java code, j=interpreted, Vv=VM code, C=native code) >>>>>>>>>>>>>>>>>> V [libjvm.so+0x18c4923] >VMError::report_and_die(int, char const*, char const*, __va_list_tag*, >Thread*, unsigned char*, void*, void*, char const*, int, unsigned >long)+0x2c3 >>>>>>>>>>>>>>>>>> V [libjvm.so+0x18c56ef] >VMError::report_and_die(Thread*, void*, char const*, int, char const*, >char const*, __va_list_tag*)+0x2f >>>>>>>>>>>>>>>>>> V [libjvm.so+0xb55aa0] report_vm_error(char const*, >int, char const*, char const*, ...)+0x100 >>>>>>>>>>>>>>>>>> V [libjvm.so+0x11f2cfe] >JvmtiThreadState::cur_stack_depth()+0x14e >>>>>>>>>>>>>>>>>> V [libjvm.so+0x11f3257] >JvmtiThreadState::update_for_pop_top_frame()+0x27 >>>>>>>>>>>>>>>>>> V [libjvm.so+0x119af99] >VM_UpdateForPopTopFrame::doit()+0xb9 >>>>>>>>>>>>>>>>>> V [libjvm.so+0x1908982] >VM_Operation::evaluate()+0x132 >>>>>>>>>>>>>>>>>> V [libjvm.so+0x19040be] >VMThread::evaluate_operation(VM_Operation*) [clone .constprop.51]+0x18e >>>>>>>>>>>>>>>>>> V [libjvm.so+0x1904960] VMThread::loop()+0x4c0 >>>>>>>>>>>>>>>>>> V [libjvm.so+0x1904f53] VMThread::run()+0xd3 >>>>>>>>>>>>>>>>>> V [libjvm.so+0x14e8300] >thread_native_entry(Thread*)+0x100 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> VM_Operation (0x00002af4d8502910): >UpdateForPopTopFrame, mode: safepoint, requested by thread >0x00002af4dc008800 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>> >>>> From robbin.ehn at oracle.com Fri Oct 26 14:33:18 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 26 Oct 2018 16:33:18 +0200 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks Message-ID: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> Hi, please review. When the VM thread executes a handshake it uses different ThreadsLists during the execution. A JavaThread that is armed for the handshake when it is already in the exit path in VM will cancel the handshake. Even if the VM thread cannot see this thread after the initial ThreadsList which where used for arming, the handshake can progress when the exiting thread cancels the handshake. But if a third thread takes a ThreadsList where the exiting JavaThread is present and tries to execute a VM operation, hence waiting on VM thread to finish the handshake, the JavaThread in the exit path can never reach the handshake cancellation point. VM thread cannot finishes the handshake and the third thread is stuck waiting on the VM thread. To allow holding a ThreadsList when executing a VM operation we instead let the VM thread use the same ThreadsList over the entire handshake making all armed threads visible to the VM thread at all time. And if VM thread spots a terminated thread it will count that thread is already done by only clearing it's operation. Passes local stress testing, t1-5 and the deadlock is no longer reproduce-able. Added a jtreg handshake + thread suspend test as a reproducer. Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ Thanks, Robbin From erik.osterlund at oracle.com Fri Oct 26 14:37:34 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 26 Oct 2018 16:37:34 +0200 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> Message-ID: <5BD326AE.5@oracle.com> Hi Robbin, Looks good. Thanks, /Erik On 2018-10-26 16:33, Robbin Ehn wrote: > Hi, please review. > > When the VM thread executes a handshake it uses different ThreadsLists > during > the execution. A JavaThread that is armed for the handshake when it is > already > in the exit path in VM will cancel the handshake. Even if the VM > thread cannot > see this thread after the initial ThreadsList which where used for > arming, the > handshake can progress when the exiting thread cancels the handshake. > > But if a third thread takes a ThreadsList where the exiting JavaThread > is present and tries to execute a VM operation, hence waiting on VM > thread to finish the handshake, the JavaThread in the exit path can > never reach the handshake cancellation point. VM thread cannot > finishes the handshake and the third thread is stuck waiting on the VM > thread. > > To allow holding a ThreadsList when executing a VM operation we > instead let the > VM thread use the same ThreadsList over the entire handshake making > all armed > threads visible to the VM thread at all time. And if VM thread spots a > terminated thread it will count that thread is already done by only > clearing > it's operation. > > Passes local stress testing, t1-5 and the deadlock is no longer > reproduce-able. > Added a jtreg handshake + thread suspend test as a reproducer. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 > Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ > > Thanks, Robbin From daniel.daugherty at oracle.com Fri Oct 26 15:38:51 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 26 Oct 2018 11:38:51 -0400 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> Message-ID: On 10/26/18 10:33 AM, Robbin Ehn wrote: > Hi, please review. > > When the VM thread executes a handshake it uses different ThreadsLists > during > the execution. A JavaThread that is armed for the handshake when it is > already > in the exit path in VM will cancel the handshake. Even if the VM > thread cannot > see this thread after the initial ThreadsList which where used for > arming, the > handshake can progress when the exiting thread cancels the handshake. > > But if a third thread takes a ThreadsList where the exiting JavaThread > is present and tries to execute a VM operation, hence waiting on VM > thread to finish the handshake, the JavaThread in the exit path can > never reach the handshake cancellation point. VM thread cannot > finishes the handshake and the third thread is stuck waiting on the VM > thread. > > To allow holding a ThreadsList when executing a VM operation we > instead let the > VM thread use the same ThreadsList over the entire handshake making > all armed > threads visible to the VM thread at all time. And if VM thread spots a > terminated thread it will count that thread is already done by only > clearing > it's operation. > > Passes local stress testing, t1-5 and the deadlock is no longer > reproduce-able. > Added a jtreg handshake + thread suspend test as a reproducer. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 > Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ src/hotspot/share/runtime/handshake.hpp ??? No comments. src/hotspot/share/runtime/handshake.cpp ??? L358: void HandshakeState::process_by_vmthread(JavaThread* target) { ??? L359: ? assert(Thread::current()->is_VM_thread(), "should call from vm thread"); ??????? Both calls to handshake_process_by_vmthread() which calls this ??????? function are made with the Threads_lock held: ??????? MutexLockerEx ml(Threads_lock, Mutex::_no_safepoint_check_flag); ??????? Looks like the lock is grabbed because of ??????? possibly_vmthread_can_process_handshake() which asserts: ??????? L351: ? // An externally suspended thread cannot be resumed while the ??????? L352: ? // Threads_lock is held so it is safe. ??????? L353: ? // Note that this method is allowed to produce false positives. ??????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding Threads_lock."); ??????? L355: ? if (target->is_ext_suspended()) { ??????? L356: ??? return true; ??????? L357: ? } ??????? Also looks like vmthread_can_process_handshake() needs the ??????? Threads_lock for the same externally suspended thread check. ??????? So I was going to ask that you add: ??????? assert(Threads_lock->owned_by_self(), "Not holding Threads_lock."); ??????? after L359, but how about a comment instead: ??????? // Threads_lock must be held here, but that is assert()ed in ??????? // possibly_vmthread_can_process_handshake(). src/hotspot/share/runtime/thread.hpp ??? No comments. src/hotspot/share/runtime/thread.cpp ??? No comments. src/hotspot/share/runtime/threadSMR.cpp ??? No comments. test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java ??? Very nice test! It specifically exercises ThreadLocalHandshakes ??? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java ??? only ran into this bug by accident (JDK-8212152) so I like the ??? targeted test. ??? L49: ??????? while(!exit_now) { ??????? nit - please add a space before '(' ??? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { ??? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { ??????? nit - please added spaces around '+=' ??????? So why every other thread? A comment would be good... ??? L52: ??????????????? wb.handshakeWalkStack(null, true); ??????? I'm guessing the 'null' parameter means current thread, but ??????? that's a guess on my part. A comment would be good. ??? L82: ??????? for (int i = 0; i < _threads.length; i++) { ??? L83: ??????????? _threads[i].join(); ??? L84: ??????? } ??????? Thanks for cleaning up the test_threads. That will make ??????? the JTREG thread sweeper happy. However, you don't save ??????? the test_exit_thread references and you don't clean those ??????? up either. Yes, I realize that they are supposed to exit, ??????? but if something hangs up on exit, I'd rather have a join() ??????? hang failure in this test's code than have the JTREG thread ??????? sweeper catch it. Dan > > Thanks, Robbin From serguei.spitsyn at oracle.com Fri Oct 26 17:23:10 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 26 Oct 2018 10:23:10 -0700 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> Message-ID: <2c2cde0c-2606-c4c2-7b64-ac51200077ef@oracle.com> Hi Robbin, The fix looks good to me. Thank you a lot for identifying and fixing this issue! Really nice, new jtreg handshake + thread suspend test reproduced this deadlock. Thanks, Serguei On 10/26/18 07:33, Robbin Ehn wrote: > Hi, please review. > > When the VM thread executes a handshake it uses different ThreadsLists > during > the execution. A JavaThread that is armed for the handshake when it is > already > in the exit path in VM will cancel the handshake. Even if the VM > thread cannot > see this thread after the initial ThreadsList which where used for > arming, the > handshake can progress when the exiting thread cancels the handshake. > > But if a third thread takes a ThreadsList where the exiting JavaThread > is present and tries to execute a VM operation, hence waiting on VM > thread to finish the handshake, the JavaThread in the exit path can > never reach the handshake cancellation point. VM thread cannot > finishes the handshake and the third thread is stuck waiting on the VM > thread. > > To allow holding a ThreadsList when executing a VM operation we > instead let the > VM thread use the same ThreadsList over the entire handshake making > all armed > threads visible to the VM thread at all time. And if VM thread spots a > terminated thread it will count that thread is already done by only > clearing > it's operation. > > Passes local stress testing, t1-5 and the deadlock is no longer > reproduce-able. > Added a jtreg handshake + thread suspend test as a reproducer. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 > Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ > > Thanks, Robbin From jcbeyler at google.com Fri Oct 26 17:48:14 2018 From: jcbeyler at google.com (JC Beyler) Date: Fri, 26 Oct 2018 10:48:14 -0700 Subject: RFR (M) 8201655: Add thread-enabled support for the Heap Sampling Message-ID: Hi all, When working on the heap sampling, I had promised to do the per thread event so here it is! Could I get a review for this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8201655/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8201655 I was thinking of adding GC-dev for the memAllocator change once I get favorable reviews for the rest of the change. I've done a bit of performance testing and on the Dacapo benchmark I see no change in performance when turned off (logical, any code change is behind a flag check already in place) and when turned on it is comparable to the current performance. (More information is: I see a very slight degradation if we are doing 512k sampling but no degradation at 2MB). Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Sun Oct 28 19:58:19 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Sun, 28 Oct 2018 20:58:19 +0100 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <5BD326AE.5@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <5BD326AE.5@oracle.com> Message-ID: <56141c9a-dbcf-b528-07b5-116ef9cbe6e6@oracle.com> Thanks Erik! /Robbin On 26/10/2018 16:37, Erik ?sterlund wrote: > Hi Robbin, > > Looks good. > > Thanks, > /Erik > > On 2018-10-26 16:33, Robbin Ehn wrote: >> Hi, please review. >> >> When the VM thread executes a handshake it uses different ThreadsLists during >> the execution. A JavaThread that is armed for the handshake when it is already >> in the exit path in VM will cancel the handshake. Even if the VM thread cannot >> see this thread after the initial ThreadsList which where used for arming, the >> handshake can progress when the exiting thread cancels the handshake. >> >> But if a third thread takes a ThreadsList where the exiting JavaThread is >> present and tries to execute a VM operation, hence waiting on VM thread to >> finish the handshake, the JavaThread in the exit path can never reach the >> handshake cancellation point. VM thread cannot finishes the handshake and the >> third thread is stuck waiting on the VM thread. >> >> To allow holding a ThreadsList when executing a VM operation we instead let the >> VM thread use the same ThreadsList over the entire handshake making all armed >> threads visible to the VM thread at all time. And if VM thread spots a >> terminated thread it will count that thread is already done by only clearing >> it's operation. >> >> Passes local stress testing, t1-5 and the deadlock is no longer reproduce-able. >> Added a jtreg handshake + thread suspend test as a reproducer. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >> >> Thanks, Robbin > From robbin.ehn at oracle.com Sun Oct 28 20:02:49 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Sun, 28 Oct 2018 21:02:49 +0100 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <2c2cde0c-2606-c4c2-7b64-ac51200077ef@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <2c2cde0c-2606-c4c2-7b64-ac51200077ef@oracle.com> Message-ID: On 26/10/2018 19:23, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > The fix looks good to me. > Thank you a lot for identifying and fixing this issue! > Really nice, new jtreg handshake + thread suspend test reproduced this deadlock. Thanks Serguei! /Robbin > > Thanks, > Serguei > > > On 10/26/18 07:33, Robbin Ehn wrote: >> Hi, please review. >> >> When the VM thread executes a handshake it uses different ThreadsLists during >> the execution. A JavaThread that is armed for the handshake when it is already >> in the exit path in VM will cancel the handshake. Even if the VM thread cannot >> see this thread after the initial ThreadsList which where used for arming, the >> handshake can progress when the exiting thread cancels the handshake. >> >> But if a third thread takes a ThreadsList where the exiting JavaThread is >> present and tries to execute a VM operation, hence waiting on VM thread to >> finish the handshake, the JavaThread in the exit path can never reach the >> handshake cancellation point. VM thread cannot finishes the handshake and the >> third thread is stuck waiting on the VM thread. >> >> To allow holding a ThreadsList when executing a VM operation we instead let the >> VM thread use the same ThreadsList over the entire handshake making all armed >> threads visible to the VM thread at all time. And if VM thread spots a >> terminated thread it will count that thread is already done by only clearing >> it's operation. >> >> Passes local stress testing, t1-5 and the deadlock is no longer reproduce-able. >> Added a jtreg handshake + thread suspend test as a reproducer. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >> >> Thanks, Robbin > From robbin.ehn at oracle.com Sun Oct 28 20:08:36 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Sun, 28 Oct 2018 21:08:36 +0100 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> Message-ID: Hi Dan, Thanks for looking at this, here is the update: Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ /Robbin On 26/10/2018 17:38, Daniel D. Daugherty wrote: > On 10/26/18 10:33 AM, Robbin Ehn wrote: >> Hi, please review. >> >> When the VM thread executes a handshake it uses different ThreadsLists during >> the execution. A JavaThread that is armed for the handshake when it is already >> in the exit path in VM will cancel the handshake. Even if the VM thread cannot >> see this thread after the initial ThreadsList which where used for arming, the >> handshake can progress when the exiting thread cancels the handshake. >> >> But if a third thread takes a ThreadsList where the exiting JavaThread is >> present and tries to execute a VM operation, hence waiting on VM thread to >> finish the handshake, the JavaThread in the exit path can never reach the >> handshake cancellation point. VM thread cannot finishes the handshake and the >> third thread is stuck waiting on the VM thread. >> >> To allow holding a ThreadsList when executing a VM operation we instead let the >> VM thread use the same ThreadsList over the entire handshake making all armed >> threads visible to the VM thread at all time. And if VM thread spots a >> terminated thread it will count that thread is already done by only clearing >> it's operation. >> >> Passes local stress testing, t1-5 and the deadlock is no longer reproduce-able. >> Added a jtreg handshake + thread suspend test as a reproducer. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ > > src/hotspot/share/runtime/handshake.hpp > ??? No comments. > > src/hotspot/share/runtime/handshake.cpp > ??? L358: void HandshakeState::process_by_vmthread(JavaThread* target) { > ??? L359: ? assert(Thread::current()->is_VM_thread(), "should call from vm > thread"); > ??????? Both calls to handshake_process_by_vmthread() which calls this > ??????? function are made with the Threads_lock held: > > ??????? MutexLockerEx ml(Threads_lock, Mutex::_no_safepoint_check_flag); > > ??????? Looks like the lock is grabbed because of > ??????? possibly_vmthread_can_process_handshake() which asserts: > > ??????? L351: ? // An externally suspended thread cannot be resumed while the > ??????? L352: ? // Threads_lock is held so it is safe. > ??????? L353: ? // Note that this method is allowed to produce false positives. > ??????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding > Threads_lock."); > ??????? L355: ? if (target->is_ext_suspended()) { > ??????? L356: ??? return true; > ??????? L357: ? } > > ??????? Also looks like vmthread_can_process_handshake() needs the > ??????? Threads_lock for the same externally suspended thread check. > > ??????? So I was going to ask that you add: > > ??????? assert(Threads_lock->owned_by_self(), "Not holding Threads_lock."); > > ??????? after L359, but how about a comment instead: > > ??????? // Threads_lock must be held here, but that is assert()ed in > ??????? // possibly_vmthread_can_process_handshake(). > > > src/hotspot/share/runtime/thread.hpp > ??? No comments. > > src/hotspot/share/runtime/thread.cpp > ??? No comments. > > src/hotspot/share/runtime/threadSMR.cpp > ??? No comments. > > test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java > ??? Very nice test! It specifically exercises ThreadLocalHandshakes > ??? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java > ??? only ran into this bug by accident (JDK-8212152) so I like the > ??? targeted test. > > ??? L49: ??????? while(!exit_now) { > ??????? nit - please add a space before '(' > > ??? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { > ??? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { > ??????? nit - please added spaces around '+=' > > ??????? So why every other thread? A comment would be good... > > ??? L52: ??????????????? wb.handshakeWalkStack(null, true); > ??????? I'm guessing the 'null' parameter means current thread, but > ??????? that's a guess on my part. A comment would be good. > > ??? L82: ??????? for (int i = 0; i < _threads.length; i++) { > ??? L83: ??????????? _threads[i].join(); > ??? L84: ??????? } > ??????? Thanks for cleaning up the test_threads. That will make > ??????? the JTREG thread sweeper happy. However, you don't save > ??????? the test_exit_thread references and you don't clean those > ??????? up either. Yes, I realize that they are supposed to exit, > ??????? but if something hangs up on exit, I'd rather have a join() > ??????? hang failure in this test's code than have the JTREG thread > ??????? sweeper catch it. > > Dan > >> >> Thanks, Robbin > From jini.george at oracle.com Mon Oct 29 06:02:15 2018 From: jini.george at oracle.com (Jini George) Date: Mon, 29 Oct 2018 11:32:15 +0530 Subject: RFR: (S): JDK-8200613: SA: jstack throws UnmappedAddressException with a CDS core file In-Reply-To: References: <864997e5-2581-7ac9-44f7-76cc31c9ad93@oracle.com> <60d2e6db-c87b-9658-57cb-b03ca881a624@oracle.com> Message-ID: <9eb9041d-f984-0df4-a21e-4645966a62b8@oracle.com> Thank you very much, Ioi, for looking into this, and the clarification offline. My bad, I had missed the earlier mail from you. :-( My responses below. Yes, I had tested this on MacOS. The issue does not exist on MacOS since the file backed private mmap()-ed regions get dumped into the MacOS corefiles by default. The corefile sizes on Linux do increase due to this change. And the increase would also include any file mapped using NIO with MapMode.PRIVATE. The typical corefile size increase with this change would include the following components at a high level: * Any NIO file mapping with MapMode.PRIVATE. * Any file mmap()-ed by any native library with MAP_PRIVATE. * The read only CDS regions (ro and od): Of the order of a few MB. * The shared strings CDS region. (typically less than 1 MB). * 2 MB per native shared library (regions with ---p permissions mapped by the dynamic linker for better alignment and for keeping libraries efficiently shareable). * The JDK 'modules' file. (About 140 MB). So, without including any NIO mapping, I typically see around 250-300 MB increase in the corefile sizes. I agree that the size increase could be a cause for concern, but for FWIW, these privately mapped files get dumped into the corefile for MacOS too. And the corefile sizes for the same program on MacOS are way larger (of the order of a few GB as against about 300 MB on Linux (without the change)). The advantage of fixing this by modifying the coredump_filter v/s doing it in SA (by reading in more sections of the shared archive file) is that this would benefit other debuggers like gdb also. (And reduces the dependence on having the shared archive file being available at the time of debugging). If folks still think this is a cause for concern, I could make modifications to fix this by reading in the regions from the shared archive file in the SA code. I also wonder if it is worth taking a relook at the mapping types of the various CDS regions also. Thank you, Jini. On 10/22/2018 10:27 AM, Ioi Lam wrote: > Hi Jini, > > Did you see my earlier reply? I might have sent it out during the mail > server outage days :-( > > http://openjdk.5641.n7.nabble.com/RFR-S-JDK-8200613-SA-jstack-throws-UnmappedAddressException-with-a-CDS-core-file-td352681.html#a353026 > > > Here was my reply again: > >> Hi Jini, >> >> The changes looks good to me. >> >> Have you tested this on MacOS? CDS heap support is also enabled on >> MacOS. See macros.hpp: >> >> ???? #if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64) && >> !defined(_WINDOWS) >> ???? #define INCLUDE_CDS_JAVA_HEAP 1 >> >> Also, besides CDS, do we know how often other files will be mmaped with >> MAP_PRIVATE? Will users get huge core files because CDS is enabled? In >> JDK 12, CDS will be enabled by default (see JDK-8202951), so all users >> will be affected by the following line: >> >> ?? if (UseSharedSpaces) { >> ???? set_coredump_filter(FILE_BACKED_PVT_BIT); >> ?? } >> >> Maybe you can run an big app such as Eclipse, trigger a core dump, and >> compare the size of the core file before/after this change? >> >> Thanks >> >> - Ioi > > > > > > > Thanks > > - Ioi > > > On 10/21/18 8:58 PM, Jini George wrote: >> Gentle reminder! >> >> Thanks, >> - Jini >> >> On 10/9/2018 11:31 AM, Jini George wrote: >>> 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 amit.sapre at oracle.com Mon Oct 29 06:08:14 2018 From: amit.sapre at oracle.com (Amit Sapre) Date: Sun, 28 Oct 2018 23:08:14 -0700 (PDT) Subject: RFR : JDK-8211951 - Broken links in java.management files Message-ID: <3bd93906-a004-4d2c-b6d5-d002cd4702ea@default> Hello, Please review the docs fixes for broken links. Bug ID : https://bugs.openjdk.java.net/browse/JDK-8211951 Webrev : http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8211951/00/webrev/ Thanks, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Oct 29 06:20:32 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Oct 2018 16:20:32 +1000 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> Message-ID: <667fe3d7-efe8-1f8a-0e83-a028c18e9cae@oracle.com> Hi Robbin, On 29/10/2018 6:08 AM, Robbin Ehn wrote: > Hi Dan, > > Thanks for looking at this, here is the update: > Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ > Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ I can't say I really understand the change in protocol here and why all the cancel operations are no longer needed. I see the handshake VM operations reusing the initial "threads list" but I'm unclear how they might be affected if additional threads are added to the system before the Threads_lock is acquired? A couple of specific comments: src/hotspot/share/runtime/handshake.hpp cancel_inner() is dead now. --- src/hotspot/share/runtime/handshake.cpp This was an odd looking for loop before your change and now looks even more strange: for ( ; JavaThread *thr = jtiwh.next(); ) { can it not simply be a more normal looking: for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = jtiwh.next()) { ? --- Thanks, David > /Robbin > > On 26/10/2018 17:38, Daniel D. Daugherty wrote: >> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>> Hi, please review. >>> >>> When the VM thread executes a handshake it uses different >>> ThreadsLists during >>> the execution. A JavaThread that is armed for the handshake when it >>> is already >>> in the exit path in VM will cancel the handshake. Even if the VM >>> thread cannot >>> see this thread after the initial ThreadsList which where used for >>> arming, the >>> handshake can progress when the exiting thread cancels the handshake. >>> >>> But if a third thread takes a ThreadsList where the exiting >>> JavaThread is present and tries to execute a VM operation, hence >>> waiting on VM thread to finish the handshake, the JavaThread in the >>> exit path can never reach the handshake cancellation point. VM thread >>> cannot finishes the handshake and the third thread is stuck waiting >>> on the VM thread. >>> >>> To allow holding a ThreadsList when executing a VM operation we >>> instead let the >>> VM thread use the same ThreadsList over the entire handshake making >>> all armed >>> threads visible to the VM thread at all time. And if VM thread spots >>> a terminated thread it will count that thread is already done by only >>> clearing >>> it's operation. >>> >>> Passes local stress testing, t1-5 and the deadlock is no longer >>> reproduce-able. >>> Added a jtreg handshake + thread suspend test as a reproducer. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >> >> src/hotspot/share/runtime/handshake.hpp >> ???? No comments. >> >> src/hotspot/share/runtime/handshake.cpp >> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* target) { >> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should call >> from vm thread"); >> ???????? Both calls to handshake_process_by_vmthread() which calls this >> ???????? function are made with the Threads_lock held: >> >> ???????? MutexLockerEx ml(Threads_lock, Mutex::_no_safepoint_check_flag); >> >> ???????? Looks like the lock is grabbed because of >> ???????? possibly_vmthread_can_process_handshake() which asserts: >> >> ???????? L351: ? // An externally suspended thread cannot be resumed >> while the >> ???????? L352: ? // Threads_lock is held so it is safe. >> ???????? L353: ? // Note that this method is allowed to produce false >> positives. >> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding >> Threads_lock."); >> ???????? L355: ? if (target->is_ext_suspended()) { >> ???????? L356: ??? return true; >> ???????? L357: ? } >> >> ???????? Also looks like vmthread_can_process_handshake() needs the >> ???????? Threads_lock for the same externally suspended thread check. >> >> ???????? So I was going to ask that you add: >> >> ???????? assert(Threads_lock->owned_by_self(), "Not holding >> Threads_lock."); >> >> ???????? after L359, but how about a comment instead: >> >> ???????? // Threads_lock must be held here, but that is assert()ed in >> ???????? // possibly_vmthread_can_process_handshake(). >> >> >> src/hotspot/share/runtime/thread.hpp >> ???? No comments. >> >> src/hotspot/share/runtime/thread.cpp >> ???? No comments. >> >> src/hotspot/share/runtime/threadSMR.cpp >> ???? No comments. >> >> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >> ???? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java >> ???? only ran into this bug by accident (JDK-8212152) so I like the >> ???? targeted test. >> >> ???? L49: ??????? while(!exit_now) { >> ???????? nit - please add a space before '(' >> >> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >> ???????? nit - please added spaces around '+=' >> >> ???????? So why every other thread? A comment would be good... >> >> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >> ???????? I'm guessing the 'null' parameter means current thread, but >> ???????? that's a guess on my part. A comment would be good. >> >> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >> ???? L83: ??????????? _threads[i].join(); >> ???? L84: ??????? } >> ???????? Thanks for cleaning up the test_threads. That will make >> ???????? the JTREG thread sweeper happy. However, you don't save >> ???????? the test_exit_thread references and you don't clean those >> ???????? up either. Yes, I realize that they are supposed to exit, >> ???????? but if something hangs up on exit, I'd rather have a join() >> ???????? hang failure in this test's code than have the JTREG thread >> ???????? sweeper catch it. >> >> Dan >> >>> >>> Thanks, Robbin >> From Alan.Bateman at oracle.com Mon Oct 29 06:43:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Oct 2018 06:43:17 +0000 Subject: RFR : JDK-8211951 - Broken links in java.management files In-Reply-To: <3bd93906-a004-4d2c-b6d5-d002cd4702ea@default> References: <3bd93906-a004-4d2c-b6d5-d002cd4702ea@default> Message-ID: On 29/10/2018 06:08, Amit Sapre wrote: > > Hello, > > Please review the docs fixes for broken links. > > Bug ID : https://bugs.openjdk.java.net/browse/JDK-8211951 > > Webrev : > http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8211951/00/webrev/ > > > Looks okay. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Mon Oct 29 09:05:07 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 29 Oct 2018 10:05:07 +0100 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <667fe3d7-efe8-1f8a-0e83-a028c18e9cae@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <667fe3d7-efe8-1f8a-0e83-a028c18e9cae@oracle.com> Message-ID: <743d68d6-5317-df15-ed9c-743e11e5579b@oracle.com> Hi David, On 29/10/2018 07:20, David Holmes wrote: > Hi Robbin, > > On 29/10/2018 6:08 AM, Robbin Ehn wrote: >> Hi Dan, >> >> Thanks for looking at this, here is the update: >> Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ >> Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ > > I can't say I really understand the change in protocol here and why all the > cancel operations are no longer needed. I see the handshake VM operations > reusing the initial "threads list" but I'm unclear how they might be affected if > additional threads are added to the system before the Threads_lock is acquired? The ThreadsList is a snapshot of all the JavaThreads at that time in the VM. Handshake all threads only handshake those JavaThreads. We do not care about new threads. The typical generic use-case is the similar to RCU. You first update a global state and emit the handshake when the handshake return no thread can see the old state. GlobalFuncPtr = some_new_func; HandshakeAllThreads; ------------------------------ No thread can be executing the old func. If the JavaThreads have a local copy of GlobalFuncPtr the handshake operation would be to update the local copy to some_new_func. It works for both Java and for VM resources that respect safepoints. For a pure VM resource it's much cheaper to use the GlobalCounter. The Threads_lock must only be held for S/R protocol. With changes to the S/R protocol, such as using handshake instead, we can remove Threads_lock for handshakes completely. (with a other small fixes) The cancel is no longer needed since the terminated threads are visible to the VM thread when we keep the arming threadslist. We add terminated threads as safe for handshake. But if we handshake a terminated thread we do not execute the handshake operation, instead just clear the operation and increment the completed counter. (the VM thread cancels the operation) I hope that helped? > > A couple of specific comments: > > src/hotspot/share/runtime/handshake.hpp > > cancel_inner() is dead now. > > --- > > src/hotspot/share/runtime/handshake.cpp > > This was an odd looking for loop before your change and now looks even more > strange: > > ?for ( ; JavaThread *thr = jtiwh.next(); ) { > > can it not simply be a more normal looking: > > ?for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = jtiwh.next()) { > > ? Thanks, fixed with below patch. /Robbin diff -r 5f8b292c473f src/hotspot/share/runtime/handshake.cpp --- a/src/hotspot/share/runtime/handshake.cpp Sun Oct 28 20:57:24 2018 +0100 +++ b/src/hotspot/share/runtime/handshake.cpp Mon Oct 29 09:32:26 2018 +0100 @@ -166,1 +166,1 @@ - for ( ; JavaThread *thr = jtiwh.next(); ) { + for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = jtiwh.next()) { @@ -198,1 +198,1 @@ - for ( ; JavaThread *thr = jtiwh.next(); ) { + for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = jtiwh.next()) { diff -r 5f8b292c473f src/hotspot/share/runtime/handshake.hpp --- a/src/hotspot/share/runtime/handshake.hpp Sun Oct 28 20:57:24 2018 +0100 +++ b/src/hotspot/share/runtime/handshake.hpp Mon Oct 29 09:32:26 2018 +0100 @@ -63,1 +62,0 @@ - void cancel_inner(JavaThread* thread); > > --- > > Thanks, > David > >> /Robbin >> >> On 26/10/2018 17:38, Daniel D. Daugherty wrote: >>> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>>> Hi, please review. >>>> >>>> When the VM thread executes a handshake it uses different ThreadsLists during >>>> the execution. A JavaThread that is armed for the handshake when it is already >>>> in the exit path in VM will cancel the handshake. Even if the VM thread cannot >>>> see this thread after the initial ThreadsList which where used for arming, the >>>> handshake can progress when the exiting thread cancels the handshake. >>>> >>>> But if a third thread takes a ThreadsList where the exiting JavaThread is >>>> present and tries to execute a VM operation, hence waiting on VM thread to >>>> finish the handshake, the JavaThread in the exit path can never reach the >>>> handshake cancellation point. VM thread cannot finishes the handshake and >>>> the third thread is stuck waiting on the VM thread. >>>> >>>> To allow holding a ThreadsList when executing a VM operation we instead let the >>>> VM thread use the same ThreadsList over the entire handshake making all armed >>>> threads visible to the VM thread at all time. And if VM thread spots a >>>> terminated thread it will count that thread is already done by only clearing >>>> it's operation. >>>> >>>> Passes local stress testing, t1-5 and the deadlock is no longer reproduce-able. >>>> Added a jtreg handshake + thread suspend test as a reproducer. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >>> >>> src/hotspot/share/runtime/handshake.hpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/handshake.cpp >>> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* target) { >>> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should call from vm >>> thread"); >>> ???????? Both calls to handshake_process_by_vmthread() which calls this >>> ???????? function are made with the Threads_lock held: >>> >>> ???????? MutexLockerEx ml(Threads_lock, Mutex::_no_safepoint_check_flag); >>> >>> ???????? Looks like the lock is grabbed because of >>> ???????? possibly_vmthread_can_process_handshake() which asserts: >>> >>> ???????? L351: ? // An externally suspended thread cannot be resumed while the >>> ???????? L352: ? // Threads_lock is held so it is safe. >>> ???????? L353: ? // Note that this method is allowed to produce false positives. >>> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding >>> Threads_lock."); >>> ???????? L355: ? if (target->is_ext_suspended()) { >>> ???????? L356: ??? return true; >>> ???????? L357: ? } >>> >>> ???????? Also looks like vmthread_can_process_handshake() needs the >>> ???????? Threads_lock for the same externally suspended thread check. >>> >>> ???????? So I was going to ask that you add: >>> >>> ???????? assert(Threads_lock->owned_by_self(), "Not holding Threads_lock."); >>> >>> ???????? after L359, but how about a comment instead: >>> >>> ???????? // Threads_lock must be held here, but that is assert()ed in >>> ???????? // possibly_vmthread_can_process_handshake(). >>> >>> >>> src/hotspot/share/runtime/thread.hpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/thread.cpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/threadSMR.cpp >>> ???? No comments. >>> >>> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >>> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >>> ???? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java >>> ???? only ran into this bug by accident (JDK-8212152) so I like the >>> ???? targeted test. >>> >>> ???? L49: ??????? while(!exit_now) { >>> ???????? nit - please add a space before '(' >>> >>> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>> ???????? nit - please added spaces around '+=' >>> >>> ???????? So why every other thread? A comment would be good... >>> >>> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >>> ???????? I'm guessing the 'null' parameter means current thread, but >>> ???????? that's a guess on my part. A comment would be good. >>> >>> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >>> ???? L83: ??????????? _threads[i].join(); >>> ???? L84: ??????? } >>> ???????? Thanks for cleaning up the test_threads. That will make >>> ???????? the JTREG thread sweeper happy. However, you don't save >>> ???????? the test_exit_thread references and you don't clean those >>> ???????? up either. Yes, I realize that they are supposed to exit, >>> ???????? but if something hangs up on exit, I'd rather have a join() >>> ???????? hang failure in this test's code than have the JTREG thread >>> ???????? sweeper catch it. >>> >>> Dan >>> >>>> >>>> Thanks, Robbin >>> From daniel.daugherty at oracle.com Mon Oct 29 13:52:32 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 29 Oct 2018 09:52:32 -0400 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> Message-ID: <88bc0b9f-a7a0-4144-da57-fcde608cc0b4@oracle.com> On 10/28/18 4:08 PM, Robbin Ehn wrote: > Hi Dan, > > Thanks for looking at this, here is the update: > Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ src/hotspot/share/runtime/handshake.cpp ??? No comments. test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java ??? No comments. Thumbs up! Thanks for making the updates. Dan > Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ > > /Robbin > > On 26/10/2018 17:38, Daniel D. Daugherty wrote: >> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>> Hi, please review. >>> >>> When the VM thread executes a handshake it uses different >>> ThreadsLists during >>> the execution. A JavaThread that is armed for the handshake when it >>> is already >>> in the exit path in VM will cancel the handshake. Even if the VM >>> thread cannot >>> see this thread after the initial ThreadsList which where used for >>> arming, the >>> handshake can progress when the exiting thread cancels the handshake. >>> >>> But if a third thread takes a ThreadsList where the exiting >>> JavaThread is present and tries to execute a VM operation, hence >>> waiting on VM thread to finish the handshake, the JavaThread in the >>> exit path can never reach the handshake cancellation point. VM >>> thread cannot finishes the handshake and the third thread is stuck >>> waiting on the VM thread. >>> >>> To allow holding a ThreadsList when executing a VM operation we >>> instead let the >>> VM thread use the same ThreadsList over the entire handshake making >>> all armed >>> threads visible to the VM thread at all time. And if VM thread spots >>> a terminated thread it will count that thread is already done by >>> only clearing >>> it's operation. >>> >>> Passes local stress testing, t1-5 and the deadlock is no longer >>> reproduce-able. >>> Added a jtreg handshake + thread suspend test as a reproducer. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >> >> src/hotspot/share/runtime/handshake.hpp >> ???? No comments. >> >> src/hotspot/share/runtime/handshake.cpp >> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* >> target) { >> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should call >> from vm thread"); >> ???????? Both calls to handshake_process_by_vmthread() which calls this >> ???????? function are made with the Threads_lock held: >> >> ???????? MutexLockerEx ml(Threads_lock, >> Mutex::_no_safepoint_check_flag); >> >> ???????? Looks like the lock is grabbed because of >> ???????? possibly_vmthread_can_process_handshake() which asserts: >> >> ???????? L351: ? // An externally suspended thread cannot be resumed >> while the >> ???????? L352: ? // Threads_lock is held so it is safe. >> ???????? L353: ? // Note that this method is allowed to produce false >> positives. >> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding >> Threads_lock."); >> ???????? L355: ? if (target->is_ext_suspended()) { >> ???????? L356: ??? return true; >> ???????? L357: ? } >> >> ???????? Also looks like vmthread_can_process_handshake() needs the >> ???????? Threads_lock for the same externally suspended thread check. >> >> ???????? So I was going to ask that you add: >> >> ???????? assert(Threads_lock->owned_by_self(), "Not holding >> Threads_lock."); >> >> ???????? after L359, but how about a comment instead: >> >> ???????? // Threads_lock must be held here, but that is assert()ed in >> ???????? // possibly_vmthread_can_process_handshake(). >> >> >> src/hotspot/share/runtime/thread.hpp >> ???? No comments. >> >> src/hotspot/share/runtime/thread.cpp >> ???? No comments. >> >> src/hotspot/share/runtime/threadSMR.cpp >> ???? No comments. >> >> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >> ???? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java >> ???? only ran into this bug by accident (JDK-8212152) so I like the >> ???? targeted test. >> >> ???? L49: ??????? while(!exit_now) { >> ???????? nit - please add a space before '(' >> >> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >> ???????? nit - please added spaces around '+=' >> >> ???????? So why every other thread? A comment would be good... >> >> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >> ???????? I'm guessing the 'null' parameter means current thread, but >> ???????? that's a guess on my part. A comment would be good. >> >> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >> ???? L83: ??????????? _threads[i].join(); >> ???? L84: ??????? } >> ???????? Thanks for cleaning up the test_threads. That will make >> ???????? the JTREG thread sweeper happy. However, you don't save >> ???????? the test_exit_thread references and you don't clean those >> ???????? up either. Yes, I realize that they are supposed to exit, >> ???????? but if something hangs up on exit, I'd rather have a join() >> ???????? hang failure in this test's code than have the JTREG thread >> ???????? sweeper catch it. >> >> Dan >> >>> >>> Thanks, Robbin >> From robbin.ehn at oracle.com Mon Oct 29 14:21:09 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 29 Oct 2018 15:21:09 +0100 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <88bc0b9f-a7a0-4144-da57-fcde608cc0b4@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <88bc0b9f-a7a0-4144-da57-fcde608cc0b4@oracle.com> Message-ID: Thanks Dan! /Robbin On 29/10/2018 14:52, Daniel D. Daugherty wrote: > On 10/28/18 4:08 PM, Robbin Ehn wrote: >> Hi Dan, >> >> Thanks for looking at this, here is the update: >> Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ > > src/hotspot/share/runtime/handshake.cpp > ??? No comments. > > test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java > ??? No comments. > > Thumbs up! > > Thanks for making the updates. > > Dan > > > >> Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ >> >> /Robbin >> >> On 26/10/2018 17:38, Daniel D. Daugherty wrote: >>> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>>> Hi, please review. >>>> >>>> When the VM thread executes a handshake it uses different ThreadsLists during >>>> the execution. A JavaThread that is armed for the handshake when it is already >>>> in the exit path in VM will cancel the handshake. Even if the VM thread cannot >>>> see this thread after the initial ThreadsList which where used for arming, the >>>> handshake can progress when the exiting thread cancels the handshake. >>>> >>>> But if a third thread takes a ThreadsList where the exiting JavaThread is >>>> present and tries to execute a VM operation, hence waiting on VM thread to >>>> finish the handshake, the JavaThread in the exit path can never reach the >>>> handshake cancellation point. VM thread cannot finishes the handshake and >>>> the third thread is stuck waiting on the VM thread. >>>> >>>> To allow holding a ThreadsList when executing a VM operation we instead let the >>>> VM thread use the same ThreadsList over the entire handshake making all armed >>>> threads visible to the VM thread at all time. And if VM thread spots a >>>> terminated thread it will count that thread is already done by only clearing >>>> it's operation. >>>> >>>> Passes local stress testing, t1-5 and the deadlock is no longer reproduce-able. >>>> Added a jtreg handshake + thread suspend test as a reproducer. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >>> >>> src/hotspot/share/runtime/handshake.hpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/handshake.cpp >>> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* target) { >>> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should call from vm >>> thread"); >>> ???????? Both calls to handshake_process_by_vmthread() which calls this >>> ???????? function are made with the Threads_lock held: >>> >>> ???????? MutexLockerEx ml(Threads_lock, Mutex::_no_safepoint_check_flag); >>> >>> ???????? Looks like the lock is grabbed because of >>> ???????? possibly_vmthread_can_process_handshake() which asserts: >>> >>> ???????? L351: ? // An externally suspended thread cannot be resumed while the >>> ???????? L352: ? // Threads_lock is held so it is safe. >>> ???????? L353: ? // Note that this method is allowed to produce false positives. >>> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding >>> Threads_lock."); >>> ???????? L355: ? if (target->is_ext_suspended()) { >>> ???????? L356: ??? return true; >>> ???????? L357: ? } >>> >>> ???????? Also looks like vmthread_can_process_handshake() needs the >>> ???????? Threads_lock for the same externally suspended thread check. >>> >>> ???????? So I was going to ask that you add: >>> >>> ???????? assert(Threads_lock->owned_by_self(), "Not holding Threads_lock."); >>> >>> ???????? after L359, but how about a comment instead: >>> >>> ???????? // Threads_lock must be held here, but that is assert()ed in >>> ???????? // possibly_vmthread_can_process_handshake(). >>> >>> >>> src/hotspot/share/runtime/thread.hpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/thread.cpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/threadSMR.cpp >>> ???? No comments. >>> >>> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >>> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >>> ???? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java >>> ???? only ran into this bug by accident (JDK-8212152) so I like the >>> ???? targeted test. >>> >>> ???? L49: ??????? while(!exit_now) { >>> ???????? nit - please add a space before '(' >>> >>> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>> ???????? nit - please added spaces around '+=' >>> >>> ???????? So why every other thread? A comment would be good... >>> >>> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >>> ???????? I'm guessing the 'null' parameter means current thread, but >>> ???????? that's a guess on my part. A comment would be good. >>> >>> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >>> ???? L83: ??????????? _threads[i].join(); >>> ???? L84: ??????? } >>> ???????? Thanks for cleaning up the test_threads. That will make >>> ???????? the JTREG thread sweeper happy. However, you don't save >>> ???????? the test_exit_thread references and you don't clean those >>> ???????? up either. Yes, I realize that they are supposed to exit, >>> ???????? but if something hangs up on exit, I'd rather have a join() >>> ???????? hang failure in this test's code than have the JTREG thread >>> ???????? sweeper catch it. >>> >>> Dan >>> >>>> >>>> Thanks, Robbin >>> > From serguei.spitsyn at oracle.com Mon Oct 29 17:35:04 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Oct 2018 10:35:04 -0700 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <88bc0b9f-a7a0-4144-da57-fcde608cc0b4@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <88bc0b9f-a7a0-4144-da57-fcde608cc0b4@oracle.com> Message-ID: <0278da83-ec4c-273a-e2ac-d7fd2dad7bf8@oracle.com> Hi Robbin, +1 Thanks, Serguei On 10/29/18 06:52, Daniel D. Daugherty wrote: > On 10/28/18 4:08 PM, Robbin Ehn wrote: >> Hi Dan, >> >> Thanks for looking at this, here is the update: >> Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ > > src/hotspot/share/runtime/handshake.cpp > ??? No comments. > > test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java > ??? No comments. > > Thumbs up! > > Thanks for making the updates. > > Dan > > > >> Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ >> >> /Robbin >> >> On 26/10/2018 17:38, Daniel D. Daugherty wrote: >>> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>>> Hi, please review. >>>> >>>> When the VM thread executes a handshake it uses different >>>> ThreadsLists during >>>> the execution. A JavaThread that is armed for the handshake when it >>>> is already >>>> in the exit path in VM will cancel the handshake. Even if the VM >>>> thread cannot >>>> see this thread after the initial ThreadsList which where used for >>>> arming, the >>>> handshake can progress when the exiting thread cancels the handshake. >>>> >>>> But if a third thread takes a ThreadsList where the exiting >>>> JavaThread is present and tries to execute a VM operation, hence >>>> waiting on VM thread to finish the handshake, the JavaThread in the >>>> exit path can never reach the handshake cancellation point. VM >>>> thread cannot finishes the handshake and the third thread is stuck >>>> waiting on the VM thread. >>>> >>>> To allow holding a ThreadsList when executing a VM operation we >>>> instead let the >>>> VM thread use the same ThreadsList over the entire handshake making >>>> all armed >>>> threads visible to the VM thread at all time. And if VM thread >>>> spots a terminated thread it will count that thread is already done >>>> by only clearing >>>> it's operation. >>>> >>>> Passes local stress testing, t1-5 and the deadlock is no longer >>>> reproduce-able. >>>> Added a jtreg handshake + thread suspend test as a reproducer. >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >>> >>> src/hotspot/share/runtime/handshake.hpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/handshake.cpp >>> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* >>> target) { >>> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should call >>> from vm thread"); >>> ???????? Both calls to handshake_process_by_vmthread() which calls this >>> ???????? function are made with the Threads_lock held: >>> >>> ???????? MutexLockerEx ml(Threads_lock, >>> Mutex::_no_safepoint_check_flag); >>> >>> ???????? Looks like the lock is grabbed because of >>> ???????? possibly_vmthread_can_process_handshake() which asserts: >>> >>> ???????? L351: ? // An externally suspended thread cannot be resumed >>> while the >>> ???????? L352: ? // Threads_lock is held so it is safe. >>> ???????? L353: ? // Note that this method is allowed to produce >>> false positives. >>> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding >>> Threads_lock."); >>> ???????? L355: ? if (target->is_ext_suspended()) { >>> ???????? L356: ??? return true; >>> ???????? L357: ? } >>> >>> ???????? Also looks like vmthread_can_process_handshake() needs the >>> ???????? Threads_lock for the same externally suspended thread check. >>> >>> ???????? So I was going to ask that you add: >>> >>> ???????? assert(Threads_lock->owned_by_self(), "Not holding >>> Threads_lock."); >>> >>> ???????? after L359, but how about a comment instead: >>> >>> ???????? // Threads_lock must be held here, but that is assert()ed in >>> ???????? // possibly_vmthread_can_process_handshake(). >>> >>> >>> src/hotspot/share/runtime/thread.hpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/thread.cpp >>> ???? No comments. >>> >>> src/hotspot/share/runtime/threadSMR.cpp >>> ???? No comments. >>> >>> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >>> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >>> ???? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java >>> ???? only ran into this bug by accident (JDK-8212152) so I like the >>> ???? targeted test. >>> >>> ???? L49: ??????? while(!exit_now) { >>> ???????? nit - please add a space before '(' >>> >>> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>> ???????? nit - please added spaces around '+=' >>> >>> ???????? So why every other thread? A comment would be good... >>> >>> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >>> ???????? I'm guessing the 'null' parameter means current thread, but >>> ???????? that's a guess on my part. A comment would be good. >>> >>> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >>> ???? L83: ??????????? _threads[i].join(); >>> ???? L84: ??????? } >>> ???????? Thanks for cleaning up the test_threads. That will make >>> ???????? the JTREG thread sweeper happy. However, you don't save >>> ???????? the test_exit_thread references and you don't clean those >>> ???????? up either. Yes, I realize that they are supposed to exit, >>> ???????? but if something hangs up on exit, I'd rather have a join() >>> ???????? hang failure in this test's code than have the JTREG thread >>> ???????? sweeper catch it. >>> >>> Dan >>> >>>> >>>> Thanks, Robbin >>> > From daniil.x.titov at oracle.com Mon Oct 29 18:13:07 2018 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 29 Oct 2018 11:13:07 -0700 Subject: RFR 8195627: [Graal] nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026 hangs with Graal in Xcomp mode Message-ID: Please review the change that fixes the issue when the test hangs with Graal and XComp mode on. One of the test cases the test runs is to call com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is suspended. The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses() don't correspond to the reference type (the names do not match) and the test expects NoClassDefFoundError to be thrown. The problem here is that the compiler thread is suspended while "JDWP Transport Listener" thread enters CompileBroker::wait_for_jvmci_completion() method and the code inside CompileBroker::wait_for_jvmci_completion() method falsely assumes that some progress by the compiler thread was made. As a result, it resets the progress wait attempt counter and goes into an endless loop waiting for JVMCI to complete the compilation. Webrev: http://cr.openjdk.java.net/~dtitov/8195627/webrev.01/ Issue: https://bugs.openjdk.java.net/browse/JDK-8195627 Thanks! --Daniil From serguei.spitsyn at oracle.com Mon Oct 29 19:22:48 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 29 Oct 2018 12:22:48 -0700 Subject: RFR : JDK-8211951 - Broken links in java.management files In-Reply-To: References: <3bd93906-a004-4d2c-b6d5-d002cd4702ea@default> Message-ID: <6ed06834-a771-5a04-d629-335c3b0a651b@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Oct 30 01:31:51 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Oct 2018 11:31:51 +1000 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <743d68d6-5317-df15-ed9c-743e11e5579b@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <667fe3d7-efe8-1f8a-0e83-a028c18e9cae@oracle.com> <743d68d6-5317-df15-ed9c-743e11e5579b@oracle.com> Message-ID: <221a4229-a742-2323-61c0-a6f6b10f5b11@oracle.com> Thanks for the explanation Robbin. The inline patch also seems fine. I hope the other reviewers noticed it. David On 29/10/2018 7:05 PM, Robbin Ehn wrote: > Hi David, > > On 29/10/2018 07:20, David Holmes wrote: >> Hi Robbin, >> >> On 29/10/2018 6:08 AM, Robbin Ehn wrote: >>> Hi Dan, >>> >>> Thanks for looking at this, here is the update: >>> Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ >>> Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ >> >> I can't say I really understand the change in protocol here and why >> all the cancel operations are no longer needed. I see the handshake VM >> operations reusing the initial "threads list" but I'm unclear how they >> might be affected if additional threads are added to the system before >> the Threads_lock is acquired? > > The ThreadsList is a snapshot of all the JavaThreads at that time in the > VM. > Handshake all threads only handshake those JavaThreads. We do not care > about new > threads. > > The typical generic use-case is the similar to RCU. You first update a > global > state and emit the handshake when the handshake return no thread can see > the old > state. > > GlobalFuncPtr = some_new_func; > HandshakeAllThreads; > ------------------------------ > No thread can be executing the old func. > > If the JavaThreads have a local copy of GlobalFuncPtr the handshake > operation would be to update the local copy to some_new_func. > > It works for both Java and for VM resources that respect safepoints. > For a pure VM resource it's much cheaper to use the GlobalCounter. > > The Threads_lock must only be held for S/R protocol. > With changes to the S/R protocol, such as using handshake instead, we > can remove > Threads_lock for handshakes completely. (with a other small fixes) > > The cancel is no longer needed since the terminated threads are visible > to the > VM thread when we keep the arming threadslist. We add terminated threads > as safe > for handshake. But if we handshake a terminated thread we do not execute > the > handshake operation, instead just clear the operation and increment the > completed counter. (the VM thread cancels the operation) > > I hope that helped? > >> >> A couple of specific comments: >> >> src/hotspot/share/runtime/handshake.hpp >> >> cancel_inner() is dead now. >> >> --- >> >> src/hotspot/share/runtime/handshake.cpp >> >> This was an odd looking for loop before your change and now looks even >> more strange: >> >> ??for ( ; JavaThread *thr = jtiwh.next(); ) { >> >> can it not simply be a more normal looking: >> >> ??for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = jtiwh.next()) { >> >> ? > > Thanks, fixed with below patch. > > /Robbin > > diff -r 5f8b292c473f src/hotspot/share/runtime/handshake.cpp > --- a/src/hotspot/share/runtime/handshake.cpp??? Sun Oct 28 20:57:24 > 2018 +0100 > +++ b/src/hotspot/share/runtime/handshake.cpp??? Mon Oct 29 09:32:26 > 2018 +0100 > @@ -166,1 +166,1 @@ > -??? for ( ; JavaThread *thr = jtiwh.next(); ) { > +??? for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = > jtiwh.next()) { > @@ -198,1 +198,1 @@ > -????????? for ( ; JavaThread *thr = jtiwh.next(); ) { > +????????? for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = > jtiwh.next()) { > diff -r 5f8b292c473f src/hotspot/share/runtime/handshake.hpp > --- a/src/hotspot/share/runtime/handshake.hpp??? Sun Oct 28 20:57:24 > 2018 +0100 > +++ b/src/hotspot/share/runtime/handshake.hpp??? Mon Oct 29 09:32:26 > 2018 +0100 > @@ -63,1 +62,0 @@ > -? void cancel_inner(JavaThread* thread); > > >> >> --- >> >> Thanks, >> David >> >>> /Robbin >>> >>> On 26/10/2018 17:38, Daniel D. Daugherty wrote: >>>> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>>>> Hi, please review. >>>>> >>>>> When the VM thread executes a handshake it uses different >>>>> ThreadsLists during >>>>> the execution. A JavaThread that is armed for the handshake when it >>>>> is already >>>>> in the exit path in VM will cancel the handshake. Even if the VM >>>>> thread cannot >>>>> see this thread after the initial ThreadsList which where used for >>>>> arming, the >>>>> handshake can progress when the exiting thread cancels the handshake. >>>>> >>>>> But if a third thread takes a ThreadsList where the exiting >>>>> JavaThread is present and tries to execute a VM operation, hence >>>>> waiting on VM thread to finish the handshake, the JavaThread in the >>>>> exit path can never reach the handshake cancellation point. VM >>>>> thread cannot finishes the handshake and the third thread is stuck >>>>> waiting on the VM thread. >>>>> >>>>> To allow holding a ThreadsList when executing a VM operation we >>>>> instead let the >>>>> VM thread use the same ThreadsList over the entire handshake making >>>>> all armed >>>>> threads visible to the VM thread at all time. And if VM thread >>>>> spots a terminated thread it will count that thread is already done >>>>> by only clearing >>>>> it's operation. >>>>> >>>>> Passes local stress testing, t1-5 and the deadlock is no longer >>>>> reproduce-able. >>>>> Added a jtreg handshake + thread suspend test as a reproducer. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>>>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >>>> >>>> src/hotspot/share/runtime/handshake.hpp >>>> ???? No comments. >>>> >>>> src/hotspot/share/runtime/handshake.cpp >>>> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* >>>> target) { >>>> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should call >>>> from vm thread"); >>>> ???????? Both calls to handshake_process_by_vmthread() which calls this >>>> ???????? function are made with the Threads_lock held: >>>> >>>> ???????? MutexLockerEx ml(Threads_lock, >>>> Mutex::_no_safepoint_check_flag); >>>> >>>> ???????? Looks like the lock is grabbed because of >>>> ???????? possibly_vmthread_can_process_handshake() which asserts: >>>> >>>> ???????? L351: ? // An externally suspended thread cannot be resumed >>>> while the >>>> ???????? L352: ? // Threads_lock is held so it is safe. >>>> ???????? L353: ? // Note that this method is allowed to produce >>>> false positives. >>>> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding >>>> Threads_lock."); >>>> ???????? L355: ? if (target->is_ext_suspended()) { >>>> ???????? L356: ??? return true; >>>> ???????? L357: ? } >>>> >>>> ???????? Also looks like vmthread_can_process_handshake() needs the >>>> ???????? Threads_lock for the same externally suspended thread check. >>>> >>>> ???????? So I was going to ask that you add: >>>> >>>> ???????? assert(Threads_lock->owned_by_self(), "Not holding >>>> Threads_lock."); >>>> >>>> ???????? after L359, but how about a comment instead: >>>> >>>> ???????? // Threads_lock must be held here, but that is assert()ed in >>>> ???????? // possibly_vmthread_can_process_handshake(). >>>> >>>> >>>> src/hotspot/share/runtime/thread.hpp >>>> ???? No comments. >>>> >>>> src/hotspot/share/runtime/thread.cpp >>>> ???? No comments. >>>> >>>> src/hotspot/share/runtime/threadSMR.cpp >>>> ???? No comments. >>>> >>>> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >>>> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >>>> ???? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java >>>> ???? only ran into this bug by accident (JDK-8212152) so I like the >>>> ???? targeted test. >>>> >>>> ???? L49: ??????? while(!exit_now) { >>>> ???????? nit - please add a space before '(' >>>> >>>> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>>> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>>> ???????? nit - please added spaces around '+=' >>>> >>>> ???????? So why every other thread? A comment would be good... >>>> >>>> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >>>> ???????? I'm guessing the 'null' parameter means current thread, but >>>> ???????? that's a guess on my part. A comment would be good. >>>> >>>> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >>>> ???? L83: ??????????? _threads[i].join(); >>>> ???? L84: ??????? } >>>> ???????? Thanks for cleaning up the test_threads. That will make >>>> ???????? the JTREG thread sweeper happy. However, you don't save >>>> ???????? the test_exit_thread references and you don't clean those >>>> ???????? up either. Yes, I realize that they are supposed to exit, >>>> ???????? but if something hangs up on exit, I'd rather have a join() >>>> ???????? hang failure in this test's code than have the JTREG thread >>>> ???????? sweeper catch it. >>>> >>>> Dan >>>> >>>>> >>>>> Thanks, Robbin >>>> From amit.sapre at oracle.com Tue Oct 30 08:10:31 2018 From: amit.sapre at oracle.com (Amit Sapre) Date: Tue, 30 Oct 2018 01:10:31 -0700 (PDT) Subject: RFR : JDK-8211951 - Broken links in java.management files In-Reply-To: <6ed06834-a771-5a04-d629-335c3b0a651b@oracle.com> References: <3bd93906-a004-4d2c-b6d5-d002cd4702ea@default> <6ed06834-a771-5a04-d629-335c3b0a651b@oracle.com> Message-ID: Thanks Serguei & Alan for the reviews. Amit ? From: Serguei Spitsyn Sent: Tuesday, October 30, 2018 12:53 AM To: Alan Bateman; Amit Sapre; serviceability-dev at openjdk.java.net Subject: Re: RFR : JDK-8211951 - Broken links in java.management files ? Hi Amit, +1 Thanks, Serguei On 10/28/18 23:43, Alan Bateman wrote: ? On 29/10/2018 06:08, Amit Sapre wrote: Hello, ? Please review the docs fixes for broken links. ? Bug ID : https://bugs.openjdk.java.net/browse/JDK-8211951 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Easapre/webrev/2018/JDK-8211951/00/webrev/"http://cr.openjdk.java.net/~asapre/webrev/2018/JDK-8211951/00/webrev/ ? Looks okay. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Oct 30 09:04:25 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Oct 2018 02:04:25 -0700 Subject: RFR 8195627: [Graal] nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026 hangs with Graal in Xcomp mode In-Reply-To: References: Message-ID: <0fa53478-a0cc-5031-21bd-1790ebd49c45@oracle.com> The Compiler team needs to review this as well, so added hotspot-compiler-dev mailing list. Thanks, Serguei On 10/29/18 11:13, Daniil Titov wrote: > Please review the change that fixes the issue when the test hangs with Graal and XComp mode on. > > One of the test cases the test runs is to call com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is suspended. The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses() don't correspond to the reference type (the names do not match) and the test expects NoClassDefFoundError to be thrown. > > The problem here is that the compiler thread is suspended while "JDWP Transport Listener" thread enters CompileBroker::wait_for_jvmci_completion() method and the code inside CompileBroker::wait_for_jvmci_completion() method falsely assumes that some progress by the compiler thread was made. As a result, it resets the progress wait attempt counter and goes into an endless loop waiting for JVMCI to complete the compilation. > > > Webrev: http://cr.openjdk.java.net/~dtitov/8195627/webrev.01/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8195627 > > Thanks! > --Daniil > > From daniel.daugherty at oracle.com Tue Oct 30 13:18:25 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 30 Oct 2018 09:18:25 -0400 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <221a4229-a742-2323-61c0-a6f6b10f5b11@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <667fe3d7-efe8-1f8a-0e83-a028c18e9cae@oracle.com> <743d68d6-5317-df15-ed9c-743e11e5579b@oracle.com> <221a4229-a742-2323-61c0-a6f6b10f5b11@oracle.com> Message-ID: <9376d6c8-6134-8893-b092-d06b0b23f229@oracle.com> On 10/29/18 9:31 PM, David Holmes wrote: > Thanks for the explanation Robbin. > > The inline patch also seems fine. I hope the other reviewers noticed it. Yes, but I forgot to reply to it. Thumbs up. Dan > > David > > On 29/10/2018 7:05 PM, Robbin Ehn wrote: >> Hi David, >> >> On 29/10/2018 07:20, David Holmes wrote: >>> Hi Robbin, >>> >>> On 29/10/2018 6:08 AM, Robbin Ehn wrote: >>>> Hi Dan, >>>> >>>> Thanks for looking at this, here is the update: >>>> Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ >>>> Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ >>> >>> I can't say I really understand the change in protocol here and why >>> all the cancel operations are no longer needed. I see the handshake >>> VM operations reusing the initial "threads list" but I'm unclear how >>> they might be affected if additional threads are added to the system >>> before the Threads_lock is acquired? >> >> The ThreadsList is a snapshot of all the JavaThreads at that time in >> the VM. >> Handshake all threads only handshake those JavaThreads. We do not >> care about new >> threads. >> >> The typical generic use-case is the similar to RCU. You first update >> a global >> state and emit the handshake when the handshake return no thread can >> see the old >> state. >> >> GlobalFuncPtr = some_new_func; >> HandshakeAllThreads; >> ------------------------------ >> No thread can be executing the old func. >> >> If the JavaThreads have a local copy of GlobalFuncPtr the handshake >> operation would be to update the local copy to some_new_func. >> >> It works for both Java and for VM resources that respect safepoints. >> For a pure VM resource it's much cheaper to use the GlobalCounter. >> >> The Threads_lock must only be held for S/R protocol. >> With changes to the S/R protocol, such as using handshake instead, we >> can remove >> Threads_lock for handshakes completely. (with a other small fixes) >> >> The cancel is no longer needed since the terminated threads are >> visible to the >> VM thread when we keep the arming threadslist. We add terminated >> threads as safe >> for handshake. But if we handshake a terminated thread we do not >> execute the >> handshake operation, instead just clear the operation and increment the >> completed counter. (the VM thread cancels the operation) >> >> I hope that helped? >> >>> >>> A couple of specific comments: >>> >>> src/hotspot/share/runtime/handshake.hpp >>> >>> cancel_inner() is dead now. >>> >>> --- >>> >>> src/hotspot/share/runtime/handshake.cpp >>> >>> This was an odd looking for loop before your change and now looks >>> even more strange: >>> >>> ??for ( ; JavaThread *thr = jtiwh.next(); ) { >>> >>> can it not simply be a more normal looking: >>> >>> ??for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = >>> jtiwh.next()) { >>> >>> ? >> >> Thanks, fixed with below patch. >> >> /Robbin >> >> diff -r 5f8b292c473f src/hotspot/share/runtime/handshake.cpp >> --- a/src/hotspot/share/runtime/handshake.cpp??? Sun Oct 28 20:57:24 >> 2018 +0100 >> +++ b/src/hotspot/share/runtime/handshake.cpp??? Mon Oct 29 09:32:26 >> 2018 +0100 >> @@ -166,1 +166,1 @@ >> -??? for ( ; JavaThread *thr = jtiwh.next(); ) { >> +??? for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = >> jtiwh.next()) { >> @@ -198,1 +198,1 @@ >> -????????? for ( ; JavaThread *thr = jtiwh.next(); ) { >> +????????? for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = >> jtiwh.next()) { >> diff -r 5f8b292c473f src/hotspot/share/runtime/handshake.hpp >> --- a/src/hotspot/share/runtime/handshake.hpp??? Sun Oct 28 20:57:24 >> 2018 +0100 >> +++ b/src/hotspot/share/runtime/handshake.hpp??? Mon Oct 29 09:32:26 >> 2018 +0100 >> @@ -63,1 +62,0 @@ >> -? void cancel_inner(JavaThread* thread); >> >> >>> >>> --- >>> >>> Thanks, >>> David >>> >>>> /Robbin >>>> >>>> On 26/10/2018 17:38, Daniel D. Daugherty wrote: >>>>> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>>>>> Hi, please review. >>>>>> >>>>>> When the VM thread executes a handshake it uses different >>>>>> ThreadsLists during >>>>>> the execution. A JavaThread that is armed for the handshake when >>>>>> it is already >>>>>> in the exit path in VM will cancel the handshake. Even if the VM >>>>>> thread cannot >>>>>> see this thread after the initial ThreadsList which where used >>>>>> for arming, the >>>>>> handshake can progress when the exiting thread cancels the >>>>>> handshake. >>>>>> >>>>>> But if a third thread takes a ThreadsList where the exiting >>>>>> JavaThread is present and tries to execute a VM operation, hence >>>>>> waiting on VM thread to finish the handshake, the JavaThread in >>>>>> the exit path can never reach the handshake cancellation point. >>>>>> VM thread cannot finishes the handshake and the third thread is >>>>>> stuck waiting on the VM thread. >>>>>> >>>>>> To allow holding a ThreadsList when executing a VM operation we >>>>>> instead let the >>>>>> VM thread use the same ThreadsList over the entire handshake >>>>>> making all armed >>>>>> threads visible to the VM thread at all time. And if VM thread >>>>>> spots a terminated thread it will count that thread is already >>>>>> done by only clearing >>>>>> it's operation. >>>>>> >>>>>> Passes local stress testing, t1-5 and the deadlock is no longer >>>>>> reproduce-able. >>>>>> Added a jtreg handshake + thread suspend test as a reproducer. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>>>>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >>>>> >>>>> src/hotspot/share/runtime/handshake.hpp >>>>> ???? No comments. >>>>> >>>>> src/hotspot/share/runtime/handshake.cpp >>>>> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* >>>>> target) { >>>>> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should >>>>> call from vm thread"); >>>>> ???????? Both calls to handshake_process_by_vmthread() which calls >>>>> this >>>>> ???????? function are made with the Threads_lock held: >>>>> >>>>> ???????? MutexLockerEx ml(Threads_lock, >>>>> Mutex::_no_safepoint_check_flag); >>>>> >>>>> ???????? Looks like the lock is grabbed because of >>>>> ???????? possibly_vmthread_can_process_handshake() which asserts: >>>>> >>>>> ???????? L351: ? // An externally suspended thread cannot be >>>>> resumed while the >>>>> ???????? L352: ? // Threads_lock is held so it is safe. >>>>> ???????? L353: ? // Note that this method is allowed to produce >>>>> false positives. >>>>> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not >>>>> holding Threads_lock."); >>>>> ???????? L355: ? if (target->is_ext_suspended()) { >>>>> ???????? L356: ??? return true; >>>>> ???????? L357: ? } >>>>> >>>>> ???????? Also looks like vmthread_can_process_handshake() needs the >>>>> ???????? Threads_lock for the same externally suspended thread check. >>>>> >>>>> ???????? So I was going to ask that you add: >>>>> >>>>> ???????? assert(Threads_lock->owned_by_self(), "Not holding >>>>> Threads_lock."); >>>>> >>>>> ???????? after L359, but how about a comment instead: >>>>> >>>>> ???????? // Threads_lock must be held here, but that is assert()ed in >>>>> ???????? // possibly_vmthread_can_process_handshake(). >>>>> >>>>> >>>>> src/hotspot/share/runtime/thread.hpp >>>>> ???? No comments. >>>>> >>>>> src/hotspot/share/runtime/thread.cpp >>>>> ???? No comments. >>>>> >>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>> ???? No comments. >>>>> >>>>> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >>>>> >>>>> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >>>>> ???? with JavaThread suspend/resume. >>>>> runtime/Thread/SuspendAtExit.java >>>>> ???? only ran into this bug by accident (JDK-8212152) so I like the >>>>> ???? targeted test. >>>>> >>>>> ???? L49: ??????? while(!exit_now) { >>>>> ???????? nit - please add a space before '(' >>>>> >>>>> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>>>> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>>>> ???????? nit - please added spaces around '+=' >>>>> >>>>> ???????? So why every other thread? A comment would be good... >>>>> >>>>> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >>>>> ???????? I'm guessing the 'null' parameter means current thread, but >>>>> ???????? that's a guess on my part. A comment would be good. >>>>> >>>>> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >>>>> ???? L83: ??????????? _threads[i].join(); >>>>> ???? L84: ??????? } >>>>> ???????? Thanks for cleaning up the test_threads. That will make >>>>> ???????? the JTREG thread sweeper happy. However, you don't save >>>>> ???????? the test_exit_thread references and you don't clean those >>>>> ???????? up either. Yes, I realize that they are supposed to exit, >>>>> ???????? but if something hangs up on exit, I'd rather have a join() >>>>> ???????? hang failure in this test's code than have the JTREG thread >>>>> ???????? sweeper catch it. >>>>> >>>>> Dan >>>>> >>>>>> >>>>>> Thanks, Robbin >>>>> From vladimir.kozlov at oracle.com Tue Oct 30 15:51:26 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 30 Oct 2018 08:51:26 -0700 Subject: RFR 8195627: [Graal] nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026 hangs with Graal in Xcomp mode In-Reply-To: <0fa53478-a0cc-5031-21bd-1790ebd49c45@oracle.com> References: <0fa53478-a0cc-5031-21bd-1790ebd49c45@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 10/30/18 2:04 AM, serguei.spitsyn at oracle.com wrote: > The Compiler team needs to review this as well, so added hotspot-compiler-dev mailing list. > > Thanks, > Serguei > > > On 10/29/18 11:13, Daniil Titov wrote: >> Please review the change that fixes the issue when the test hangs with Graal and XComp mode on. >> >> One of the test cases the test runs is to call com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is >> suspended.? The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses()? don't correspond to the reference type >> (the names do not match) and the test expects NoClassDefFoundError to be thrown. >> >> The problem here is that the compiler thread is suspended while "JDWP Transport Listener" thread enters >> CompileBroker::wait_for_jvmci_completion() method and the code inside CompileBroker::wait_for_jvmci_completion() >> method falsely assumes that some progress by the compiler thread was made.? As a result, it resets the progress wait >> attempt counter and goes into an endless loop waiting for JVMCI to complete the compilation. >> >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8195627/webrev.01/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8195627 >> >> Thanks! >> --Daniil >> >> > From serguei.spitsyn at oracle.com Tue Oct 30 21:24:09 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Oct 2018 14:24:09 -0700 Subject: RFR 8195627: [Graal] nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026 hangs with Graal in Xcomp mode In-Reply-To: References: Message-ID: <6c64896e-b691-63b3-5a97-ceecf1046ef7@oracle.com> Hi Daniil, It looks good. Thanks! Serguei On 10/29/18 11:13 AM, Daniil Titov wrote: > Please review the change that fixes the issue when the test hangs with Graal and XComp mode on. > > One of the test cases the test runs is to call com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is suspended. The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses() don't correspond to the reference type (the names do not match) and the test expects NoClassDefFoundError to be thrown. > > The problem here is that the compiler thread is suspended while "JDWP Transport Listener" thread enters CompileBroker::wait_for_jvmci_completion() method and the code inside CompileBroker::wait_for_jvmci_completion() method falsely assumes that some progress by the compiler thread was made. As a result, it resets the progress wait attempt counter and goes into an endless loop waiting for JVMCI to complete the compilation. > > > Webrev: http://cr.openjdk.java.net/~dtitov/8195627/webrev.01/ > Issue: https://bugs.openjdk.java.net/browse/JDK-8195627 > > Thanks! > --Daniil > > From jcbeyler at google.com Wed Oct 31 04:42:57 2018 From: jcbeyler at google.com (JC Beyler) Date: Tue, 30 Oct 2018 21:42:57 -0700 Subject: RFR (M) 8213003: Remove more assignments in ifs for vmTestbase/[a-s] Message-ID: Hi all, I worked on updating my script and handling more assignments so I redid a second pass on the same files to get all the cases. Now, on those files the regex "if.* = " no longer shows any cases we would want to fix. Could I get a review for this webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8213003/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8213003 I tested this on my dev machine by passing all the tests that were modified. Thanks! Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Wed Oct 31 07:03:30 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 31 Oct 2018 08:03:30 +0100 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <9376d6c8-6134-8893-b092-d06b0b23f229@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <667fe3d7-efe8-1f8a-0e83-a028c18e9cae@oracle.com> <743d68d6-5317-df15-ed9c-743e11e5579b@oracle.com> <221a4229-a742-2323-61c0-a6f6b10f5b11@oracle.com> <9376d6c8-6134-8893-b092-d06b0b23f229@oracle.com> Message-ID: Thanks Dan, Robbin On 10/30/18 2:18 PM, Daniel D. Daugherty wrote: > On 10/29/18 9:31 PM, David Holmes wrote: >> Thanks for the explanation Robbin. >> >> The inline patch also seems fine. I hope the other reviewers noticed it. > > Yes, but I forgot to reply to it. > > Thumbs up. > > Dan > > >> >> David >> >> On 29/10/2018 7:05 PM, Robbin Ehn wrote: >>> Hi David, >>> >>> On 29/10/2018 07:20, David Holmes wrote: >>>> Hi Robbin, >>>> >>>> On 29/10/2018 6:08 AM, Robbin Ehn wrote: >>>>> Hi Dan, >>>>> >>>>> Thanks for looking at this, here is the update: >>>>> Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ >>>>> Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ >>>> >>>> I can't say I really understand the change in protocol here and why all the >>>> cancel operations are no longer needed. I see the handshake VM operations >>>> reusing the initial "threads list" but I'm unclear how they might be >>>> affected if additional threads are added to the system before the >>>> Threads_lock is acquired? >>> >>> The ThreadsList is a snapshot of all the JavaThreads at that time in the VM. >>> Handshake all threads only handshake those JavaThreads. We do not care about new >>> threads. >>> >>> The typical generic use-case is the similar to RCU. You first update a global >>> state and emit the handshake when the handshake return no thread can see the old >>> state. >>> >>> GlobalFuncPtr = some_new_func; >>> HandshakeAllThreads; >>> ------------------------------ >>> No thread can be executing the old func. >>> >>> If the JavaThreads have a local copy of GlobalFuncPtr the handshake operation >>> would be to update the local copy to some_new_func. >>> >>> It works for both Java and for VM resources that respect safepoints. >>> For a pure VM resource it's much cheaper to use the GlobalCounter. >>> >>> The Threads_lock must only be held for S/R protocol. >>> With changes to the S/R protocol, such as using handshake instead, we can remove >>> Threads_lock for handshakes completely. (with a other small fixes) >>> >>> The cancel is no longer needed since the terminated threads are visible to the >>> VM thread when we keep the arming threadslist. We add terminated threads as safe >>> for handshake. But if we handshake a terminated thread we do not execute the >>> handshake operation, instead just clear the operation and increment the >>> completed counter. (the VM thread cancels the operation) >>> >>> I hope that helped? >>> >>>> >>>> A couple of specific comments: >>>> >>>> src/hotspot/share/runtime/handshake.hpp >>>> >>>> cancel_inner() is dead now. >>>> >>>> --- >>>> >>>> src/hotspot/share/runtime/handshake.cpp >>>> >>>> This was an odd looking for loop before your change and now looks even more >>>> strange: >>>> >>>> ??for ( ; JavaThread *thr = jtiwh.next(); ) { >>>> >>>> can it not simply be a more normal looking: >>>> >>>> ??for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = jtiwh.next()) { >>>> >>>> ? >>> >>> Thanks, fixed with below patch. >>> >>> /Robbin >>> >>> diff -r 5f8b292c473f src/hotspot/share/runtime/handshake.cpp >>> --- a/src/hotspot/share/runtime/handshake.cpp??? Sun Oct 28 20:57:24 2018 +0100 >>> +++ b/src/hotspot/share/runtime/handshake.cpp??? Mon Oct 29 09:32:26 2018 +0100 >>> @@ -166,1 +166,1 @@ >>> -??? for ( ; JavaThread *thr = jtiwh.next(); ) { >>> +??? for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = jtiwh.next()) { >>> @@ -198,1 +198,1 @@ >>> -????????? for ( ; JavaThread *thr = jtiwh.next(); ) { >>> +????????? for (JavaThread *thr = jtiwh.next(); thr != NULL; thr = >>> jtiwh.next()) { >>> diff -r 5f8b292c473f src/hotspot/share/runtime/handshake.hpp >>> --- a/src/hotspot/share/runtime/handshake.hpp??? Sun Oct 28 20:57:24 2018 +0100 >>> +++ b/src/hotspot/share/runtime/handshake.hpp??? Mon Oct 29 09:32:26 2018 +0100 >>> @@ -63,1 +62,0 @@ >>> -? void cancel_inner(JavaThread* thread); >>> >>> >>>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> >>>>> /Robbin >>>>> >>>>> On 26/10/2018 17:38, Daniel D. Daugherty wrote: >>>>>> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>>>>>> Hi, please review. >>>>>>> >>>>>>> When the VM thread executes a handshake it uses different ThreadsLists >>>>>>> during >>>>>>> the execution. A JavaThread that is armed for the handshake when it is >>>>>>> already >>>>>>> in the exit path in VM will cancel the handshake. Even if the VM thread >>>>>>> cannot >>>>>>> see this thread after the initial ThreadsList which where used for >>>>>>> arming, the >>>>>>> handshake can progress when the exiting thread cancels the handshake. >>>>>>> >>>>>>> But if a third thread takes a ThreadsList where the exiting JavaThread is >>>>>>> present and tries to execute a VM operation, hence waiting on VM thread >>>>>>> to finish the handshake, the JavaThread in the exit path can never reach >>>>>>> the handshake cancellation point. VM thread cannot finishes the handshake >>>>>>> and the third thread is stuck waiting on the VM thread. >>>>>>> >>>>>>> To allow holding a ThreadsList when executing a VM operation we instead >>>>>>> let the >>>>>>> VM thread use the same ThreadsList over the entire handshake making all >>>>>>> armed >>>>>>> threads visible to the VM thread at all time. And if VM thread spots a >>>>>>> terminated thread it will count that thread is already done by only clearing >>>>>>> it's operation. >>>>>>> >>>>>>> Passes local stress testing, t1-5 and the deadlock is no longer >>>>>>> reproduce-able. >>>>>>> Added a jtreg handshake + thread suspend test as a reproducer. >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>>>>>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >>>>>> >>>>>> src/hotspot/share/runtime/handshake.hpp >>>>>> ???? No comments. >>>>>> >>>>>> src/hotspot/share/runtime/handshake.cpp >>>>>> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* target) { >>>>>> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should call from >>>>>> vm thread"); >>>>>> ???????? Both calls to handshake_process_by_vmthread() which calls this >>>>>> ???????? function are made with the Threads_lock held: >>>>>> >>>>>> ???????? MutexLockerEx ml(Threads_lock, Mutex::_no_safepoint_check_flag); >>>>>> >>>>>> ???????? Looks like the lock is grabbed because of >>>>>> ???????? possibly_vmthread_can_process_handshake() which asserts: >>>>>> >>>>>> ???????? L351: ? // An externally suspended thread cannot be resumed while >>>>>> the >>>>>> ???????? L352: ? // Threads_lock is held so it is safe. >>>>>> ???????? L353: ? // Note that this method is allowed to produce false >>>>>> positives. >>>>>> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding >>>>>> Threads_lock."); >>>>>> ???????? L355: ? if (target->is_ext_suspended()) { >>>>>> ???????? L356: ??? return true; >>>>>> ???????? L357: ? } >>>>>> >>>>>> ???????? Also looks like vmthread_can_process_handshake() needs the >>>>>> ???????? Threads_lock for the same externally suspended thread check. >>>>>> >>>>>> ???????? So I was going to ask that you add: >>>>>> >>>>>> ???????? assert(Threads_lock->owned_by_self(), "Not holding Threads_lock."); >>>>>> >>>>>> ???????? after L359, but how about a comment instead: >>>>>> >>>>>> ???????? // Threads_lock must be held here, but that is assert()ed in >>>>>> ???????? // possibly_vmthread_can_process_handshake(). >>>>>> >>>>>> >>>>>> src/hotspot/share/runtime/thread.hpp >>>>>> ???? No comments. >>>>>> >>>>>> src/hotspot/share/runtime/thread.cpp >>>>>> ???? No comments. >>>>>> >>>>>> src/hotspot/share/runtime/threadSMR.cpp >>>>>> ???? No comments. >>>>>> >>>>>> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >>>>>> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >>>>>> ???? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java >>>>>> ???? only ran into this bug by accident (JDK-8212152) so I like the >>>>>> ???? targeted test. >>>>>> >>>>>> ???? L49: ??????? while(!exit_now) { >>>>>> ???????? nit - please add a space before '(' >>>>>> >>>>>> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>>>>> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>>>>> ???????? nit - please added spaces around '+=' >>>>>> >>>>>> ???????? So why every other thread? A comment would be good... >>>>>> >>>>>> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >>>>>> ???????? I'm guessing the 'null' parameter means current thread, but >>>>>> ???????? that's a guess on my part. A comment would be good. >>>>>> >>>>>> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >>>>>> ???? L83: ??????????? _threads[i].join(); >>>>>> ???? L84: ??????? } >>>>>> ???????? Thanks for cleaning up the test_threads. That will make >>>>>> ???????? the JTREG thread sweeper happy. However, you don't save >>>>>> ???????? the test_exit_thread references and you don't clean those >>>>>> ???????? up either. Yes, I realize that they are supposed to exit, >>>>>> ???????? but if something hangs up on exit, I'd rather have a join() >>>>>> ???????? hang failure in this test's code than have the JTREG thread >>>>>> ???????? sweeper catch it. >>>>>> >>>>>> Dan >>>>>> >>>>>>> >>>>>>> Thanks, Robbin >>>>>> > From robbin.ehn at oracle.com Wed Oct 31 07:04:18 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 31 Oct 2018 08:04:18 +0100 Subject: RFR: 8212933: Thread-SMR: requesting a VM operation whilst holding a ThreadsListHandle can cause deadlocks In-Reply-To: <0278da83-ec4c-273a-e2ac-d7fd2dad7bf8@oracle.com> References: <503aa2cc-9f34-3f78-fc65-1e163d42453a@oracle.com> <88bc0b9f-a7a0-4144-da57-fcde608cc0b4@oracle.com> <0278da83-ec4c-273a-e2ac-d7fd2dad7bf8@oracle.com> Message-ID: <963b1b1f-d502-8732-1cb8-8d86328f407e@oracle.com> Thanks Serguei, Robbin On 10/29/18 6:35 PM, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > +1 > > Thanks, > Serguei > > On 10/29/18 06:52, Daniel D. Daugherty wrote: >> On 10/28/18 4:08 PM, Robbin Ehn wrote: >>> Hi Dan, >>> >>> Thanks for looking at this, here is the update: >>> Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/ >> >> src/hotspot/share/runtime/handshake.cpp >> ??? No comments. >> >> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >> ??? No comments. >> >> Thumbs up! >> >> Thanks for making the updates. >> >> Dan >> >> >> >>> Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/ >>> >>> /Robbin >>> >>> On 26/10/2018 17:38, Daniel D. Daugherty wrote: >>>> On 10/26/18 10:33 AM, Robbin Ehn wrote: >>>>> Hi, please review. >>>>> >>>>> When the VM thread executes a handshake it uses different ThreadsLists during >>>>> the execution. A JavaThread that is armed for the handshake when it is already >>>>> in the exit path in VM will cancel the handshake. Even if the VM thread cannot >>>>> see this thread after the initial ThreadsList which where used for arming, the >>>>> handshake can progress when the exiting thread cancels the handshake. >>>>> >>>>> But if a third thread takes a ThreadsList where the exiting JavaThread is >>>>> present and tries to execute a VM operation, hence waiting on VM thread to >>>>> finish the handshake, the JavaThread in the exit path can never reach the >>>>> handshake cancellation point. VM thread cannot finishes the handshake and >>>>> the third thread is stuck waiting on the VM thread. >>>>> >>>>> To allow holding a ThreadsList when executing a VM operation we instead let >>>>> the >>>>> VM thread use the same ThreadsList over the entire handshake making all armed >>>>> threads visible to the VM thread at all time. And if VM thread spots a >>>>> terminated thread it will count that thread is already done by only clearing >>>>> it's operation. >>>>> >>>>> Passes local stress testing, t1-5 and the deadlock is no longer >>>>> reproduce-able. >>>>> Added a jtreg handshake + thread suspend test as a reproducer. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8212933 >>>>> Code: http://cr.openjdk.java.net/~rehn/8212933/v1/webrev/ >>>> >>>> src/hotspot/share/runtime/handshake.hpp >>>> ???? No comments. >>>> >>>> src/hotspot/share/runtime/handshake.cpp >>>> ???? L358: void HandshakeState::process_by_vmthread(JavaThread* target) { >>>> ???? L359: ? assert(Thread::current()->is_VM_thread(), "should call from vm >>>> thread"); >>>> ???????? Both calls to handshake_process_by_vmthread() which calls this >>>> ???????? function are made with the Threads_lock held: >>>> >>>> ???????? MutexLockerEx ml(Threads_lock, Mutex::_no_safepoint_check_flag); >>>> >>>> ???????? Looks like the lock is grabbed because of >>>> ???????? possibly_vmthread_can_process_handshake() which asserts: >>>> >>>> ???????? L351: ? // An externally suspended thread cannot be resumed while the >>>> ???????? L352: ? // Threads_lock is held so it is safe. >>>> ???????? L353: ? // Note that this method is allowed to produce false >>>> positives. >>>> ???????? L354: ? assert(Threads_lock->owned_by_self(), "Not holding >>>> Threads_lock."); >>>> ???????? L355: ? if (target->is_ext_suspended()) { >>>> ???????? L356: ??? return true; >>>> ???????? L357: ? } >>>> >>>> ???????? Also looks like vmthread_can_process_handshake() needs the >>>> ???????? Threads_lock for the same externally suspended thread check. >>>> >>>> ???????? So I was going to ask that you add: >>>> >>>> ???????? assert(Threads_lock->owned_by_self(), "Not holding Threads_lock."); >>>> >>>> ???????? after L359, but how about a comment instead: >>>> >>>> ???????? // Threads_lock must be held here, but that is assert()ed in >>>> ???????? // possibly_vmthread_can_process_handshake(). >>>> >>>> >>>> src/hotspot/share/runtime/thread.hpp >>>> ???? No comments. >>>> >>>> src/hotspot/share/runtime/thread.cpp >>>> ???? No comments. >>>> >>>> src/hotspot/share/runtime/threadSMR.cpp >>>> ???? No comments. >>>> >>>> test/hotspot/jtreg/runtime/handshake/HandshakeWalkSuspendExitTest.java >>>> ???? Very nice test! It specifically exercises ThreadLocalHandshakes >>>> ???? with JavaThread suspend/resume. runtime/Thread/SuspendAtExit.java >>>> ???? only ran into this bug by accident (JDK-8212152) so I like the >>>> ???? targeted test. >>>> >>>> ???? L49: ??????? while(!exit_now) { >>>> ???????? nit - please add a space before '(' >>>> >>>> ???? L51: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>>> ???? L58: ??????????? for (int i = 0; i < _threads.length; i+=2) { >>>> ???????? nit - please added spaces around '+=' >>>> >>>> ???????? So why every other thread? A comment would be good... >>>> >>>> ???? L52: ??????????????? wb.handshakeWalkStack(null, true); >>>> ???????? I'm guessing the 'null' parameter means current thread, but >>>> ???????? that's a guess on my part. A comment would be good. >>>> >>>> ???? L82: ??????? for (int i = 0; i < _threads.length; i++) { >>>> ???? L83: ??????????? _threads[i].join(); >>>> ???? L84: ??????? } >>>> ???????? Thanks for cleaning up the test_threads. That will make >>>> ???????? the JTREG thread sweeper happy. However, you don't save >>>> ???????? the test_exit_thread references and you don't clean those >>>> ???????? up either. Yes, I realize that they are supposed to exit, >>>> ???????? but if something hangs up on exit, I'd rather have a join() >>>> ???????? hang failure in this test's code than have the JTREG thread >>>> ???????? sweeper catch it. >>>> >>>> Dan >>>> >>>>> >>>>> Thanks, Robbin >>>> >> > From serguei.spitsyn at oracle.com Wed Oct 31 07:11:18 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 31 Oct 2018 00:11:18 -0700 Subject: RFR (M) 8213003: Remove more assignments in ifs for vmTestbase/[a-s] In-Reply-To: References: Message-ID: <8d045fd5-3a88-c1f8-2f22-987621eccaa1@oracle.com> An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Wed Oct 31 10:16:06 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 31 Oct 2018 11:16:06 +0100 Subject: RFR (M) 8213003: Remove more assignments in ifs for vmTestbase/[a-s] In-Reply-To: References: Message-ID: Hi, here's a case that your script seems to miss: http://cr.openjdk.java.net/%7Ejcbeyler/8213003/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp.udiff.html if (!NSK_JNI_VERIFY(jni, (testedFieldID = jni->GetStaticFieldID(testedClass, FIELD_NAME, FIELD_SIGNATURE)) != NULL)) I'd note that with some of your changes here you're unconditionally executing logic outside of NSK_JNI_VERIFY macros. Does care need be taken to wrap the code blocks in equivalent macros/ifdefs? Or are the NSK_JNI_VERIFY macros always-on in these tests (and essentially pointless)? /Claes On 2018-10-31 05:42, JC Beyler wrote: > Hi all, > > I worked on updating my script and handling more assignments so I > redid a second pass on the same files to get all the cases. Now, on > those files the regex "if.* = " no longer shows any cases we would > want to fix. > > Could I get a review for this webrev: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8213003/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8213003 > > I tested this on my dev machine by passing all the tests that were > modified. > > Thanks! > Jc From simon at dancingcloudservices.com Wed Oct 31 11:07:31 2018 From: simon at dancingcloudservices.com (Simon Roberts) Date: Wed, 31 Oct 2018 13:07:31 +0200 Subject: Fwd: hprof format question In-Reply-To: References: Message-ID: Hi all, I'm hoping this is the correct list for a question on the hprof file format (1.0.2)? I found this information: http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/tip/src/share/demo/jvmti/hprof/manual.html and have been working on a small project to read these files. (Yes, I know that NetBeans/VisualVM and Eclipse both have such libraries, and a number of other tools have been derived from those, but so far as I can tell, they all are fundamentally built on the notion of fully decoding everything, and creating memory representations of the entire heap. I want to pull out only certain pieces of information--specifically object counts by class--from a large, ~20Gb, dump file, and those tools just give up the ghost on my systems.) Anyway, my code reads the file pretty well so far, except that the file I want to analyze seems to contradict the specifications of the document mentioned above. Specifically, after processing about five HEAP_DUMP_SEGMENTS with around 1.5 million sub-records in each, I come across some ROOT_JNI_LOCAL records. The first 15 follow the format specified in the above document (one 8 byte "ID" and two four byte values.) But the 16th omits the two four byte records (well, it might simply have more, but visual analysis shows that after the 8 byte ID, I have a new block tag, and a believable structure. I've actually noticed that several of the record types defined in this "group" seem to diverge from the paper I mentioned. My solution is that if my parser trips, it abandons that HEAP_DUMP_SEGMENT from that point forward. It doesn't seem to matter much, since I was looking for object data, and it appears that all of that has already been handled. However, clearly this is not ideal! Is there any more detailed, newer, better, information? Or anything else I should know to pursue this tool (or indeed a simple object frequency by classname result) from an hprof 1.0.2 format file? (And yes, I'm pursuing a putative memory leak :) Thanks for any input (including "dude, this is the wrong list!") Cheers, Simon -- Simon Roberts (303) 249 3613 -- Simon Roberts (303) 249 3613 -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Oct 31 18:21:41 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 31 Oct 2018 11:21:41 -0700 Subject: RFR (M) 8213003: Remove more assignments in ifs for vmTestbase/[a-s] In-Reply-To: References: Message-ID: Hi Claes, It's good that you brought this up. NSK_JNI_VERIFY is always "on", but moving the assignment outside of it does slightly change the behavior of the macro (although the code still executes "correctly"): /** ?* Execute action with JNI call, check result for true and ?* pending exception and complain error if required. ?* Also trace action execution if tracing mode enabled. ?*/ #define NSK_JNI_VERIFY(jni, action)? \ (nsk_ltrace(NSK_TRACE_BEFORE,__FILE__,__LINE__,"%s\n",#action), \ nsk_jni_lverify(NSK_TRUE,jni,action,__FILE__,__LINE__,"%s\n",#action)) So you will no longer see the JNI call in the trace or error output. You will just see the comparison to the JNI result, which gives no context as to the source of the result. So I'm now starting to think that doing the assignments within the NSK_JNI_VERIFY was intentional so we would see the JNI call in the trace output. Chris On 10/31/18 3:16 AM, Claes Redestad wrote: > Hi, > > here's a case that your script seems to miss: > > http://cr.openjdk.java.net/%7Ejcbeyler/8213003/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp.udiff.html > > > ???? if (!NSK_JNI_VERIFY(jni, (testedFieldID = > ???????????? jni->GetStaticFieldID(testedClass, FIELD_NAME, > FIELD_SIGNATURE)) != NULL)) > > I'd note that with some of your changes here you're unconditionally > executing logic outside of NSK_JNI_VERIFY macros. Does care need be > taken to wrap the code blocks in equivalent macros/ifdefs? Or are the > NSK_JNI_VERIFY macros always-on in these tests (and essentially > pointless)? > > /Claes > > On 2018-10-31 05:42, JC Beyler wrote: >> Hi all, >> >> I worked on updating my script and handling more assignments so I >> redid a second pass on the same files to get all the cases. Now, on >> those files the regex "if.* = " no longer shows any cases we would >> want to fix. >> >> Could I get a review for this webrev: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8213003/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213003 >> >> I tested this on my dev machine by passing all the tests that were >> modified. >> >> Thanks! >> Jc > From serguei.spitsyn at oracle.com Wed Oct 31 18:30:18 2018 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 31 Oct 2018 11:30:18 -0700 Subject: RFR (M) 8213003: Remove more assignments in ifs for vmTestbase/[a-s] In-Reply-To: References: Message-ID: <201b203e-2ba3-6849-79ca-0b6dba1c12e4@oracle.com> It prints the FILE/LINE which is enough to identify the error point. But I agree that doing the assignments within the NSK_JNI_VERIFY was intentional as it gives more context. From the other hand it make the code ugly and less readable. Not sure, what direction is better to go. Thanks, Serguei On 10/31/18 11:21, Chris Plummer wrote: > Hi Claes, > > It's good that you brought this up. NSK_JNI_VERIFY is always "on", but > moving the assignment outside of it does slightly change the behavior > of the macro (although the code still executes "correctly"): > > /** > ?* Execute action with JNI call, check result for true and > ?* pending exception and complain error if required. > ?* Also trace action execution if tracing mode enabled. > ?*/ > #define NSK_JNI_VERIFY(jni, action)? \ > (nsk_ltrace(NSK_TRACE_BEFORE,__FILE__,__LINE__,"%s\n",#action), \ > nsk_jni_lverify(NSK_TRUE,jni,action,__FILE__,__LINE__,"%s\n",#action)) > > So you will no longer see the JNI call in the trace or error output. > You will just see the comparison to the JNI result, which gives no > context as to the source of the result. So I'm now starting to think > that doing the assignments within the NSK_JNI_VERIFY was intentional > so we would see the JNI call in the trace output. > > Chris > > On 10/31/18 3:16 AM, Claes Redestad wrote: >> Hi, >> >> here's a case that your script seems to miss: >> >> http://cr.openjdk.java.net/%7Ejcbeyler/8213003/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp.udiff.html >> >> >> ???? if (!NSK_JNI_VERIFY(jni, (testedFieldID = >> ???????????? jni->GetStaticFieldID(testedClass, FIELD_NAME, >> FIELD_SIGNATURE)) != NULL)) >> >> I'd note that with some of your changes here you're unconditionally >> executing logic outside of NSK_JNI_VERIFY macros. Does care need be >> taken to wrap the code blocks in equivalent macros/ifdefs? Or are the >> NSK_JNI_VERIFY macros always-on in these tests (and essentially >> pointless)? >> >> /Claes >> >> On 2018-10-31 05:42, JC Beyler wrote: >>> Hi all, >>> >>> I worked on updating my script and handling more assignments so I >>> redid a second pass on the same files to get all the cases. Now, on >>> those files the regex "if.* = " no longer shows any cases we would >>> want to fix. >>> >>> Could I get a review for this webrev: >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8213003/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213003 >>> >>> I tested this on my dev machine by passing all the tests that were >>> modified. >>> >>> Thanks! >>> Jc >> > > From kirk.pepperdine at gmail.com Wed Oct 31 18:33:37 2018 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Wed, 31 Oct 2018 11:33:37 -0700 Subject: hprof format question In-Reply-To: References: Message-ID: <405F2C86-3494-494D-91EA-B96579557732@gmail.com> Hi Simon, I?ve also started a small project to try and solve the we need to look at very large heap problem. My solution is to load the data into Neo4J. You can find the project on my GitHub account. So, I believe I?ve taken the same tactic in just abandoning the segment for the moment. It would be useful to sort that out but I listed it as a future? Kind regards, Kirk L > On Oct 31, 2018, at 4:07 AM, Simon Roberts wrote: > > Hi all, I'm hoping this is the correct list for a question on the hprof file format (1.0.2)? > > I found this information: http://hg.openjdk.java.net/jdk6/jdk6/jdk/raw-file/tip/src/share/demo/jvmti/hprof/manual.html > > and have been working on a small project to read these files. (Yes, I know that NetBeans/VisualVM and Eclipse both have such libraries, and a number of other tools have been derived from those, but so far as I can tell, they all are fundamentally built on the notion of fully decoding everything, and creating memory representations of the entire heap. I want to pull out only certain pieces of information--specifically object counts by class--from a large, ~20Gb, dump file, and those tools just give up the ghost on my systems.) > > Anyway, my code reads the file pretty well so far, except that the file I want to analyze seems to contradict the specifications of the document mentioned above. Specifically, after processing about five HEAP_DUMP_SEGMENTS with around 1.5 million sub-records in each, I come across some ROOT_JNI_LOCAL records. The first 15 follow the format specified in the above document (one 8 byte "ID" and two four byte values.) But the 16th omits the two four byte records (well, it might simply have more, but visual analysis shows that after the 8 byte ID, I have a new block tag, and a believable structure. I've actually noticed that several of the record types defined in this "group" seem to diverge from the paper I mentioned. > > My solution is that if my parser trips, it abandons that HEAP_DUMP_SEGMENT from that point forward. It doesn't seem to matter much, since I was looking for object data, and it appears that all of that has already been handled. However, clearly this is not ideal! > > Is there any more detailed, newer, better, information? Or anything else I should know to pursue this tool (or indeed a simple object frequency by classname result) from an hprof 1.0.2 format file? > > (And yes, I'm pursuing a putative memory leak :) > > Thanks for any input (including "dude, this is the wrong list!") > Cheers, > Simon > > > > -- > Simon Roberts > (303) 249 3613 > > > > -- > Simon Roberts > (303) 249 3613 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Oct 31 18:52:38 2018 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 31 Oct 2018 11:52:38 -0700 Subject: RFR (M) 8213003: Remove more assignments in ifs for vmTestbase/[a-s] In-Reply-To: <201b203e-2ba3-6849-79ca-0b6dba1c12e4@oracle.com> References: <201b203e-2ba3-6849-79ca-0b6dba1c12e4@oracle.com> Message-ID: <131c6c78-575d-695a-a2ac-a05adefff3e0@oracle.com> On 10/31/18 11:30 AM, serguei.spitsyn at oracle.com wrote: > It prints the FILE/LINE which is enough to identify the error point. Yes, but it also prints the JNI calls. > But I agree that doing the assignments within the NSK_JNI_VERIFY was > intentional as it gives more context. > From the other hand it make the code ugly and less readable. > Not sure, what direction is better to go. Agreed. Somewhat of a tossup now as to whether or not this change should be done. I'm fine either way. Chris > > Thanks, > Serguei > > > On 10/31/18 11:21, Chris Plummer wrote: >> Hi Claes, >> >> It's good that you brought this up. NSK_JNI_VERIFY is always "on", >> but moving the assignment outside of it does slightly change the >> behavior of the macro (although the code still executes "correctly"): >> >> /** >> ?* Execute action with JNI call, check result for true and >> ?* pending exception and complain error if required. >> ?* Also trace action execution if tracing mode enabled. >> ?*/ >> #define NSK_JNI_VERIFY(jni, action)? \ >> (nsk_ltrace(NSK_TRACE_BEFORE,__FILE__,__LINE__,"%s\n",#action), \ >> nsk_jni_lverify(NSK_TRUE,jni,action,__FILE__,__LINE__,"%s\n",#action)) >> >> So you will no longer see the JNI call in the trace or error output. >> You will just see the comparison to the JNI result, which gives no >> context as to the source of the result. So I'm now starting to think >> that doing the assignments within the NSK_JNI_VERIFY was intentional >> so we would see the JNI call in the trace output. >> >> Chris >> >> On 10/31/18 3:16 AM, Claes Redestad wrote: >>> Hi, >>> >>> here's a case that your script seems to miss: >>> >>> http://cr.openjdk.java.net/%7Ejcbeyler/8213003/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp.udiff.html >>> >>> >>> ???? if (!NSK_JNI_VERIFY(jni, (testedFieldID = >>> ???????????? jni->GetStaticFieldID(testedClass, FIELD_NAME, >>> FIELD_SIGNATURE)) != NULL)) >>> >>> I'd note that with some of your changes here you're unconditionally >>> executing logic outside of NSK_JNI_VERIFY macros. Does care need be >>> taken to wrap the code blocks in equivalent macros/ifdefs? Or are >>> the NSK_JNI_VERIFY macros always-on in these tests (and essentially >>> pointless)? >>> >>> /Claes >>> >>> On 2018-10-31 05:42, JC Beyler wrote: >>>> Hi all, >>>> >>>> I worked on updating my script and handling more assignments so I >>>> redid a second pass on the same files to get all the cases. Now, on >>>> those files the regex "if.* = " no longer shows any cases we would >>>> want to fix. >>>> >>>> Could I get a review for this webrev: >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8213003/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213003 >>>> >>>> I tested this on my dev machine by passing all the tests that were >>>> modified. >>>> >>>> Thanks! >>>> Jc >>> >> >> > From jcbeyler at google.com Wed Oct 31 20:54:55 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 31 Oct 2018 13:54:55 -0700 Subject: RFR (M) 8213003: Remove more assignments in ifs for vmTestbase/[a-s] In-Reply-To: <131c6c78-575d-695a-a2ac-a05adefff3e0@oracle.com> References: <201b203e-2ba3-6849-79ca-0b6dba1c12e4@oracle.com> <131c6c78-575d-695a-a2ac-a05adefff3e0@oracle.com> Message-ID: @Claes: you are right, I did not do a grep such as "if.* =$"; by adding the space instead of the $, I missed a few :) I've been meaning to ask if we could deprecate these anyway. Are these really being used? And if so, are we saying everything here is useful: - Line/File + JNI call? I ask because I'd like to deprecate the NSK_VERIFY macros but the LINE/FILE is a bit annoying to deprecate. I'd rather be able to remove them entirely but we could do an alternative and migrate the NSK_VERIFY to: testedFieldID = jni->GetStaticFieldID(testedClass, FIELD_NAME, FIELD_SIGNATURE); if (!testedFieldID) { where the print out of the jni method and argument values can still be done in the JNI wrapper I added (ExceptionCheckingJniEnv.cpp) so we'd have the printout of the calls but not the line and filename from where the call was done. If lines and filenames are really important, then we could do something like: testedFieldID = NSK_TRACE(jni->GetStaticFieldID(testedClass, FIELD_NAME, FIELD_SIGNATURE)); if (!testedFieldID) { Which would add a line for which line/file is doing the JNI call. The verify part can go into the wrapper I was talking about (ExceptionCheckingJniEnv.cpp). Thanks, Jc On Wed, Oct 31, 2018 at 11:52 AM Chris Plummer wrote: > On 10/31/18 11:30 AM, serguei.spitsyn at oracle.com wrote: > > It prints the FILE/LINE which is enough to identify the error point. > Yes, but it also prints the JNI calls. > > But I agree that doing the assignments within the NSK_JNI_VERIFY was > > intentional as it gives more context. > > From the other hand it make the code ugly and less readable. > > Not sure, what direction is better to go. > Agreed. Somewhat of a tossup now as to whether or not this change should > be done. I'm fine either way. > > Chris > > > > Thanks, > > Serguei > > > > > > On 10/31/18 11:21, Chris Plummer wrote: > >> Hi Claes, > >> > >> It's good that you brought this up. NSK_JNI_VERIFY is always "on", > >> but moving the assignment outside of it does slightly change the > >> behavior of the macro (although the code still executes "correctly"): > >> > >> /** > >> * Execute action with JNI call, check result for true and > >> * pending exception and complain error if required. > >> * Also trace action execution if tracing mode enabled. > >> */ > >> #define NSK_JNI_VERIFY(jni, action) \ > >> (nsk_ltrace(NSK_TRACE_BEFORE,__FILE__,__LINE__,"%s\n",#action), \ > >> nsk_jni_lverify(NSK_TRUE,jni,action,__FILE__,__LINE__,"%s\n",#action)) > >> > >> So you will no longer see the JNI call in the trace or error output. > >> You will just see the comparison to the JNI result, which gives no > >> context as to the source of the result. So I'm now starting to think > >> that doing the assignments within the NSK_JNI_VERIFY was intentional > >> so we would see the JNI call in the trace output. > >> > >> Chris > >> > >> On 10/31/18 3:16 AM, Claes Redestad wrote: > >>> Hi, > >>> > >>> here's a case that your script seems to miss: > >>> > >>> > http://cr.openjdk.java.net/%7Ejcbeyler/8213003/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp.udiff.html > >>> > >>> > >>> if (!NSK_JNI_VERIFY(jni, (testedFieldID = > >>> jni->GetStaticFieldID(testedClass, FIELD_NAME, > >>> FIELD_SIGNATURE)) != NULL)) > >>> > >>> I'd note that with some of your changes here you're unconditionally > >>> executing logic outside of NSK_JNI_VERIFY macros. Does care need be > >>> taken to wrap the code blocks in equivalent macros/ifdefs? Or are > >>> the NSK_JNI_VERIFY macros always-on in these tests (and essentially > >>> pointless)? > >>> > >>> /Claes > >>> > >>> On 2018-10-31 05:42, JC Beyler wrote: > >>>> Hi all, > >>>> > >>>> I worked on updating my script and handling more assignments so I > >>>> redid a second pass on the same files to get all the cases. Now, on > >>>> those files the regex "if.* = " no longer shows any cases we would > >>>> want to fix. > >>>> > >>>> Could I get a review for this webrev: > >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8213003/webrev.00/ > >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213003 > >>>> > >>>> I tested this on my dev machine by passing all the tests that were > >>>> modified. > >>>> > >>>> Thanks! > >>>> Jc > >>> > >> > >> > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: