From david.holmes at oracle.com Fri Feb 1 04:10:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 14:10:05 +1000 Subject: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: References: <023938dc65604c7494719a7f3dc90810@sap.com> Message-ID: <33a270a0-e0c0-6753-e9a0-20d94404df72@oracle.com> On 1/02/2019 1:11 am, Lindenmaier, Goetz wrote: > ... and the tests passed. > https://ci.sapmachine.io/job/branch-build-linux_x86_64/12/JT_20Report_20hotspot/ > > Unfortunately one can not see the jtr file to verify the right exception was > thrown. But they passed, so it's good. > > Why do you remove some checks for test failures from some tests? > Like > serviceability/sa/ClhsdbInspect.java > Why won't jstackOutput be null any more after your change? I don't think it can actually be null before the change: ClhsdbLauncher.run calls ClhsdbLauncher.runCmd which will either throw, or return a non-null (put possibly empty) String. So that seems like a simple cleanup to me. Cheers, David > Others are: > serviceability/sa/ClhsdbJdis.java > serviceability/sa/ClhsdbLongConstant.java > serviceability/sa/ClhsdbPrintAs.java > serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java > serviceability/sa/ClhsdbScanOops.java > serviceability/sa/ClhsdbThread.java > > Are these all failures that go back to the attach issue? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Donnerstag, 31. Januar 2019 12:54 >> To: 'Jini George' ; serviceability- >> dev at openjdk.java.net >> Subject: RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker >> containers >> >> Hi Jini, >> >> I pushed it into our testing: >> https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build- >> service/43/ >> >> the build is running ... >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: serviceability-dev On >>> Behalf Of Jini George >>> Sent: Mittwoch, 30. Januar 2019 12:59 >>> To: serviceability-dev at openjdk.java.net >>> Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP >> docker >>> containers >>> >>> Requesting reviews for: >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 >>> Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html >>> >>> The patch includes changes to use SkippedException to skip the tests >>> when canPtraceAttachLinux() in Platform.java returns false. >>> >>> Thanks, >>> Jini. > From jini.george at oracle.com Fri Feb 1 04:16:04 2019 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Feb 2019 09:46:04 +0530 Subject: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: References: <023938dc65604c7494719a7f3dc90810@sap.com> Message-ID: <2a5a25c4-e29b-c965-0f06-4fb08bc152df@oracle.com> Thank you very much, Goetz, for running the tests and for taking a look at the changes. The only reason jstackOutput used to be null was due to the attach permission issues -- but now with the current change, test.run would throw the SkippedException for such cases, and would not reach the code parsing the jstackOutput. And in case jstackOutput is null without an exception from test.run, then that means the test has to fail. This applies to all the tests you have pointed out. Thank you, Jini. On 1/31/2019 8:41 PM, Lindenmaier, Goetz wrote: > ... and the tests passed. > https://ci.sapmachine.io/job/branch-build-linux_x86_64/12/JT_20Report_20hotspot/ > > Unfortunately one can not see the jtr file to verify the right exception was > thrown. But they passed, so it's good. > > Why do you remove some checks for test failures from some tests? > Like > serviceability/sa/ClhsdbInspect.java > Why won't jstackOutput be null any more after your change? > > Others are: > serviceability/sa/ClhsdbJdis.java > serviceability/sa/ClhsdbLongConstant.java > serviceability/sa/ClhsdbPrintAs.java > serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java > serviceability/sa/ClhsdbScanOops.java > serviceability/sa/ClhsdbThread.java > > Are these all failures that go back to the attach issue? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Donnerstag, 31. Januar 2019 12:54 >> To: 'Jini George' ; serviceability- >> dev at openjdk.java.net >> Subject: RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker >> containers >> >> Hi Jini, >> >> I pushed it into our testing: >> https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build- >> service/43/ >> >> the build is running ... >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: serviceability-dev On >>> Behalf Of Jini George >>> Sent: Mittwoch, 30. Januar 2019 12:59 >>> To: serviceability-dev at openjdk.java.net >>> Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP >> docker >>> containers >>> >>> Requesting reviews for: >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 >>> Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html >>> >>> The patch includes changes to use SkippedException to skip the tests >>> when canPtraceAttachLinux() in Platform.java returns false. >>> >>> Thanks, >>> Jini. > From david.holmes at oracle.com Fri Feb 1 04:57:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 14:57:06 +1000 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <79d984ba-f3bd-b329-4d5f-4ba2083e9628@oracle.com> References: <6daa70b3-d10c-afea-b775-12e52d7e2d58@oracle.com> <919AB047-1F67-45BB-80DD-205672FFE49F@oracle.com> <9069d34b-ad8e-17ce-c5f4-8765730d6497@oracle.com> <7afec9a8-602c-9d5b-f899-b806595ad859@oracle.com> <6e609bd6-ef09-3323-9225-255a0e750aa3@oracle.com> <95ed0aa0-7d8c-b448-fd0d-c25b930cafcb@oracle.com> <148c8531-6f2b-142d-cae0-a4d5bc2de970@oracle.com> <79d984ba-f3bd-b329-4d5f-4ba2083e9628@oracle.com> Message-ID: <157a5277-c73e-aa7a-2332-30471bd70d5e@oracle.com> +1 David On 1/02/2019 5:39 am, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > Looks fine to me. > > Thanks, > Serguei > > > On 1/31/19 10:38, Alex Menkov wrote: >> Hi guys, >> >> thank you for the feedback. >> >> updated webrev (used the way suggested by David & Igor): >> http://cr.openjdk.java.net/~amenkov/tck_red_disable_caps/webrev.02/ >> >> --alex >> >> On 01/30/2019 21:31, serguei.spitsyn at oracle.com wrote: >>> On 1/30/19 21:24, David Holmes wrote: >>>> On 31/01/2019 3:18 pm, dean.long at oracle.com wrote: >>>>> On 1/30/19 8:59 PM, serguei.spitsyn at oracle.com wrote: >>>>>> So, the fix needs to be more like this: >>>>>> + // Workaround for 8195635: >>>>>> + // disable pop_frame and force_early_return capabilities with Graal >>>>>> + #if INCLUDE_JVMCI >>>>>> + if (!(EnableJVMCI && UseJVMCICompiler)) { >>>>>> ??? jc.can_pop_frame = 1; >>>>>> ??? jc.can_force_early_return = 1; >>>>>> + } + #endif Not sure, if the check for EnableJVMCI can be removed >>>>>> above. >>>>> >>>>> We still need it to work when INCLUDE_JVMCI is not defined. >>>>> How about >>>>> >>>>> JVMCI_ONLY(if (UseJVMCICompiler)) { >>>>> ... >>>>> } >>>>> >>>>> or >>>>> >>>>> if (JVMCI_ONLY(UseJVMCICompiler) NOT_JVMCI(true)) { >>>>> ... >>>>> } >>>> >>>> Or just turn them on unconditionally first and turn off explicitly >>>> for JVMCI: >>>> >>>> ?jc.can_pop_frame = 1; >>>> ?jc.can_force_early_return = 1; >>>> + #if INCLUDE_JVMCI >>>> +? // Workaround for 8195635: >>>> +? // disable pop_frame and force_early_return capabilities with Graal >>>> + if (EnableJVMCI && UseJVMCICompiler) { >>>> +???? jc.can_pop_frame = 0; >>>> +???? jc.can_force_early_return = 0; >>>> + } >>>> + #endif >>>> >>> Oh, Dean is right. >>> We need these caps initialized even if the macro INCLUDE_JVMCI is >>> undefined. >>> Then I like variant from David above. >>> >>> Thanks, >>> Serguei >>> >>> >>>> David >>>> >>>>> dl >>>>> >>> > From sharath.ballal at oracle.com Fri Feb 1 06:00:44 2019 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 31 Jan 2019 22:00:44 -0800 (PST) Subject: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: <2a5a25c4-e29b-c965-0f06-4fb08bc152df@oracle.com> References: <023938dc65604c7494719a7f3dc90810@sap.com> <2a5a25c4-e29b-c965-0f06-4fb08bc152df@oracle.com> Message-ID: <1e106163-f128-417c-9569-41ac97c38912@default> +1 Thanks, Sharath -----Original Message----- From: Jini George Sent: Friday, February 01, 2019 9:46 AM To: Lindenmaier, Goetz; serviceability-dev at openjdk.java.net Subject: Re: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers Thank you very much, Goetz, for running the tests and for taking a look at the changes. The only reason jstackOutput used to be null was due to the attach permission issues -- but now with the current change, test.run would throw the SkippedException for such cases, and would not reach the code parsing the jstackOutput. And in case jstackOutput is null without an exception from test.run, then that means the test has to fail. This applies to all the tests you have pointed out. Thank you, Jini. On 1/31/2019 8:41 PM, Lindenmaier, Goetz wrote: > ... and the tests passed. > https://ci.sapmachine.io/job/branch-build-linux_x86_64/12/JT_20Report_ > 20hotspot/ > > Unfortunately one can not see the jtr file to verify the right > exception was thrown. But they passed, so it's good. > > Why do you remove some checks for test failures from some tests? > Like > serviceability/sa/ClhsdbInspect.java > Why won't jstackOutput be null any more after your change? > > Others are: > serviceability/sa/ClhsdbJdis.java > serviceability/sa/ClhsdbLongConstant.java > serviceability/sa/ClhsdbPrintAs.java > serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java > serviceability/sa/ClhsdbScanOops.java > serviceability/sa/ClhsdbThread.java > > Are these all failures that go back to the attach issue? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Donnerstag, 31. Januar 2019 12:54 >> To: 'Jini George' ; serviceability- >> dev at openjdk.java.net >> Subject: RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP >> docker containers >> >> Hi Jini, >> >> I pushed it into our testing: >> https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build- >> service/43/ >> >> the build is running ... >> >> Best regards, >> Goetz. >> >>> -----Original Message----- >>> From: serviceability-dev >>> On Behalf Of Jini >>> George >>> Sent: Mittwoch, 30. Januar 2019 12:59 >>> To: serviceability-dev at openjdk.java.net >>> Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on >>> SAP >> docker >>> containers >>> >>> Requesting reviews for: >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 >>> Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.h >>> tml >>> >>> The patch includes changes to use SkippedException to skip the tests >>> when canPtraceAttachLinux() in Platform.java returns false. >>> >>> Thanks, >>> Jini. > From jini.george at oracle.com Fri Feb 1 06:04:15 2019 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Feb 2019 11:34:15 +0530 Subject: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: <1e106163-f128-417c-9569-41ac97c38912@default> References: <023938dc65604c7494719a7f3dc90810@sap.com> <2a5a25c4-e29b-c965-0f06-4fb08bc152df@oracle.com> <1e106163-f128-417c-9569-41ac97c38912@default> Message-ID: Thanks, Sharath. -jini. On 2/1/2019 11:30 AM, Sharath Ballal wrote: > +1 > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Friday, February 01, 2019 9:46 AM > To: Lindenmaier, Goetz; serviceability-dev at openjdk.java.net > Subject: Re: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers > > Thank you very much, Goetz, for running the tests and for taking a look at the changes. The only reason jstackOutput used to be null was due to the attach permission issues -- but now with the current change, test.run would throw the SkippedException for such cases, and would not reach the code parsing the jstackOutput. And in case jstackOutput is null without an exception from test.run, then that means the test has to fail. This applies to all the tests you have pointed out. > > Thank you, > Jini. > > On 1/31/2019 8:41 PM, Lindenmaier, Goetz wrote: >> ... and the tests passed. >> https://ci.sapmachine.io/job/branch-build-linux_x86_64/12/JT_20Report_ >> 20hotspot/ >> >> Unfortunately one can not see the jtr file to verify the right >> exception was thrown. But they passed, so it's good. >> >> Why do you remove some checks for test failures from some tests? >> Like >> serviceability/sa/ClhsdbInspect.java >> Why won't jstackOutput be null any more after your change? >> >> Others are: >> serviceability/sa/ClhsdbJdis.java >> serviceability/sa/ClhsdbLongConstant.java >> serviceability/sa/ClhsdbPrintAs.java >> serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java >> serviceability/sa/ClhsdbScanOops.java >> serviceability/sa/ClhsdbThread.java >> >> Are these all failures that go back to the attach issue? >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: Lindenmaier, Goetz >>> Sent: Donnerstag, 31. Januar 2019 12:54 >>> To: 'Jini George' ; serviceability- >>> dev at openjdk.java.net >>> Subject: RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP >>> docker containers >>> >>> Hi Jini, >>> >>> I pushed it into our testing: >>> https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build- >>> service/43/ >>> >>> the build is running ... >>> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: serviceability-dev >>>> On Behalf Of Jini >>>> George >>>> Sent: Mittwoch, 30. Januar 2019 12:59 >>>> To: serviceability-dev at openjdk.java.net >>>> Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on >>>> SAP >>> docker >>>> containers >>>> >>>> Requesting reviews for: >>>> >>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 >>>> Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.h >>>> tml >>>> >>>> The patch includes changes to use SkippedException to skip the tests >>>> when canPtraceAttachLinux() in Platform.java returns false. >>>> >>>> Thanks, >>>> Jini. >> From Nick.Gasson at arm.com Fri Feb 1 09:22:39 2019 From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China)) Date: Fri, 1 Feb 2019 09:22:39 +0000 Subject: RFR: 8209413: AArch64: NPE in clhsdb jstack command Message-ID: Hi all, Please review this patch to fix a crash in the clhsdb "jstack -v" command on AArch64: Bug: https://bugs.openjdk.java.net/browse/JDK-8209413 Webrev: http://cr.openjdk.java.net/~ngasson/8209413/webrev.01/ On AArch64, if you use "jhsdb clhsdb --pid=..." to attach a debugger to a Java process, and then run "jstack -v" while any thread is executing a native method, you will get a NullPointerException like this: java.lang.NullPointerException at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:83) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$24.doit(CommandProcessor.java:1066) The problem is this constructor of AARCH64Frame, which is called by when trying to construct the frame for the native method (wrapper): AARCH64Frame(Address raw_sp, Address raw_fp) It takes the last-known Java SP and FP, and tries to find the PC following the BL instruction that jumped to the native code. At the moment it assumes this is at SP[-1]: this.pc = raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()); I think this comes from x86 where the CALL instruction will push it there. The fix in this patch is to scan the stack of the native (C++) function looking for a pointer back to the frame of the native wrapper. If we find this then the LR on entry should be saved in the stack slot above. This fails if the native function stack frame is too big, or it's a leaf function that didn't push FP/LR. But in this case setting this.pc to null makes the frame object look invalid and so won't be printed, instead of crashing. Sample output from the ClhsdbJstack.java jtreg test which passes now with this patch: - java.lang.Thread.sleep(long) @bci=0, pc=0x0000ffffa05bb68c, Method*=0x0000000800143410 (Compiled frame; information may be imprecise) - jdk.test.lib.apps.LingeredApp.main(java.lang.String[]) @bci=53, line=502, pc=0x0000ffff9892572c, Method*=0x0000ffff2e870d48 (Interpreted frame) An alternative to scanning the native functions's stack might be to use the last-known Java PC saved by set_last_Java_frame, this is off by a few instructions but I don't think that matters. But this constructor potentially has other users so we'd have to fix it anyway. Thanks, Nick From goetz.lindenmaier at sap.com Fri Feb 1 11:35:01 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Feb 2019 11:35:01 +0000 Subject: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: <33a270a0-e0c0-6753-e9a0-20d94404df72@oracle.com> References: <023938dc65604c7494719a7f3dc90810@sap.com> <33a270a0-e0c0-6753-e9a0-20d94404df72@oracle.com> Message-ID: <18aa9e772e68457684135a37f7fe11eb@sap.com> > > Why do you remove some checks for test failures from some tests? > > Like > > serviceability/sa/ClhsdbInspect.java > > Why won't jstackOutput be null any more after your change? > > I don't think it can actually be null before the change: > ClhsdbLauncher.run calls ClhsdbLauncher.runCmd which will either throw, > or return a non-null (put possibly empty) String. > > So that seems like a simple cleanup to me. If this holds for the other files with similar edits I listed below, too, consider this Reviewed by me as well. Best regards, Goetz. > > Others are: > > serviceability/sa/ClhsdbJdis.java > > serviceability/sa/ClhsdbLongConstant.java > > serviceability/sa/ClhsdbPrintAs.java > > serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java > > serviceability/sa/ClhsdbScanOops.java > > serviceability/sa/ClhsdbThread.java > > > > Are these all failures that go back to the attach issue? > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: Lindenmaier, Goetz > >> Sent: Donnerstag, 31. Januar 2019 12:54 > >> To: 'Jini George' ; serviceability- > >> dev at openjdk.java.net > >> Subject: RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP > docker > >> containers > >> > >> Hi Jini, > >> > >> I pushed it into our testing: > >> https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build- > >> service/43/ > >> > >> the build is running ... > >> > >> Best regards, > >> Goetz. > >> > >>> -----Original Message----- > >>> From: serviceability-dev > On > >>> Behalf Of Jini George > >>> Sent: Mittwoch, 30. Januar 2019 12:59 > >>> To: serviceability-dev at openjdk.java.net > >>> Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP > >> docker > >>> containers > >>> > >>> Requesting reviews for: > >>> > >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 > >>> > Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html > >>> > >>> The patch includes changes to use SkippedException to skip the tests > >>> when canPtraceAttachLinux() in Platform.java returns false. > >>> > >>> Thanks, > >>> Jini. > > From david.holmes at oracle.com Fri Feb 1 12:43:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Feb 2019 22:43:37 +1000 Subject: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: <18aa9e772e68457684135a37f7fe11eb@sap.com> References: <023938dc65604c7494719a7f3dc90810@sap.com> <33a270a0-e0c0-6753-e9a0-20d94404df72@oracle.com> <18aa9e772e68457684135a37f7fe11eb@sap.com> Message-ID: <3e442686-2740-c84a-4c28-67a7ef5ae2bf@oracle.com> On 1/02/2019 9:35 pm, Lindenmaier, Goetz wrote: >>> Why do you remove some checks for test failures from some tests? >>> Like >>> serviceability/sa/ClhsdbInspect.java >>> Why won't jstackOutput be null any more after your change? >> >> I don't think it can actually be null before the change: >> ClhsdbLauncher.run calls ClhsdbLauncher.runCmd which will either throw, >> or return a non-null (put possibly empty) String. >> >> So that seems like a simple cleanup to me. > If this holds for the other files with similar edits I listed below, too, > consider this Reviewed by me as well. It does - in all cases the variable ias assigned the result of ClhsdbLauncher.run. Cheers, David > Best regards, > Goetz. > >>> Others are: >>> serviceability/sa/ClhsdbJdis.java >>> serviceability/sa/ClhsdbLongConstant.java >>> serviceability/sa/ClhsdbPrintAs.java >>> serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java >>> serviceability/sa/ClhsdbScanOops.java >>> serviceability/sa/ClhsdbThread.java >>> >>> Are these all failures that go back to the attach issue? >>> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: Lindenmaier, Goetz >>>> Sent: Donnerstag, 31. Januar 2019 12:54 >>>> To: 'Jini George' ; serviceability- >>>> dev at openjdk.java.net >>>> Subject: RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP >> docker >>>> containers >>>> >>>> Hi Jini, >>>> >>>> I pushed it into our testing: >>>> https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build- >>>> service/43/ >>>> >>>> the build is running ... >>>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: serviceability-dev >> On >>>>> Behalf Of Jini George >>>>> Sent: Mittwoch, 30. Januar 2019 12:59 >>>>> To: serviceability-dev at openjdk.java.net >>>>> Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP >>>> docker >>>>> containers >>>>> >>>>> Requesting reviews for: >>>>> >>>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 >>>>> >> Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html >>>>> >>>>> The patch includes changes to use SkippedException to skip the tests >>>>> when canPtraceAttachLinux() in Platform.java returns false. >>>>> >>>>> Thanks, >>>>> Jini. >>> From david.griffiths at gmail.com Fri Feb 1 16:26:32 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Fri, 1 Feb 2019 16:26:32 +0000 Subject: Is RegisterMap updated? In-Reply-To: <21e8d6ff-41fa-10d6-813b-4d079196d34b@redhat.com> References: <21e8d6ff-41fa-10d6-813b-4d079196d34b@redhat.com> Message-ID: Had a nice simple little reproduction test, went to try it on Java 9 and... oh no, sun.jvm.hotspot.jdi.SACoreAttachingConnector has disappeared! Has it gone for good? Cheers, David On Wed, 30 Jan 2019 at 10:38, Andrew Haley wrote: > > On 1/30/19 10:00 AM, David Griffiths wrote: > > I'm not sure this works though for the frame at the top of the stack. > > The pushing of the registers that you mention appears to take place in > > the updateRegisterMap method which is called when getting the sender. > > At the top of the stack the register will be live and not saved > > anywhere? > > No the pushing of the register happens in generated code. > > > Whatever, I'm seeing a NPE caused by a location that has > > WHERE_IN_REGISTER and a register number of 16 that doesn't have > > locationValid set in the map. If I modify createStackValue to check > > valueAddr being null then it avoids the NPE and getLocals then returns > > all the locals except for the one held in a register (the other ones > > are on the stack). Not sure what a register number of 16 equates to on > > x86, is that supposed to correspond to "not set" or something? > > You're not helping. Are you sure you've got an up-to-date HotSpot > checkout? You're not falling over bug 8217407? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gary.adams at oracle.com Fri Feb 1 18:00:08 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 01 Feb 2019 13:00:08 -0500 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out Message-ID: <5C548928.5010304@oracle.com> When the remove_l005 runs to completion, it never signals the debuggee that all iterations have completed. Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 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 @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java 8068225 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -134,6 +134,7 @@ } display(""); } + debugee.sendSignal(SGNL_QUIT); display(""); display("============="); From jini.george at oracle.com Fri Feb 1 18:16:00 2019 From: jini.george at oracle.com (Jini George) Date: Fri, 1 Feb 2019 23:46:00 +0530 Subject: RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: Message-ID: <4de13272-0f19-7897-3f4d-f4b5b56ca73f@oracle.com> Hi Nick, Do we reach here after AARCH64CurrentFrameGuess.run() fails to get the PC ? If so, was wondering if it would make more sense to scan from the top of stack sp obtained from context.getRegisterAsAddress(AARCH64ThreadContext.SP) to the sp of the last known java frame with thread.getLastJavaSP() in AARCH64CurrentFrameGuess.run() -- otherwise was wondering if we are risking an exception by running off the top of the stack while scanning in the upward direction (towards lower addresses) for CALLEE_FRAME_SEARCH_LIMIT * addressSize from the previous Java SP (though the scan range is small). Thanks, Jini. P.S.:- BTW, I was referring to this to understand your change: (from page 15 of http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf) Conforming code shall construct a linked list of stack-frames. Each frame shall link to the frame of its caller by means of a frame record of two 64-bit values on the stack. The frame record for the innermost frame (belonging to the most recent routine invocation) shall be pointed to by the Frame Pointer register (FP). The lowest addressed double-word shall point to the previous frame record and the highest addressed double-word shall contain the value passed in LR on entry to the current function. The end of the frame record chain is indicated by the address zero in the address for the previous frame. The location of the frame record within a stack frame is not specified. Note: There will always be a short period during construction or destruction of each frame record during which the frame pointer will point to the caller?s record. On 2/1/2019 2:52 PM, Nick Gasson (Arm Technology China) wrote: > Hi all, > > Please review this patch to fix a crash in the clhsdb "jstack -v" > command on AArch64: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209413 > Webrev: http://cr.openjdk.java.net/~ngasson/8209413/webrev.01/ > > On AArch64, if you use "jhsdb clhsdb --pid=..." to attach a debugger to > a Java process, and then run "jstack -v" while any thread is executing a > native method, you will get a NullPointerException like this: > > java.lang.NullPointerException > at > jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:83) > at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$24.doit(CommandProcessor.java:1066) > > The problem is this constructor of AARCH64Frame, which is called by when > trying to construct the frame for the native method (wrapper): > > AARCH64Frame(Address raw_sp, Address raw_fp) > > It takes the last-known Java SP and FP, and tries to find the PC > following the BL instruction that jumped to the native code. At the > moment it assumes this is at SP[-1]: > > this.pc = raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()); > > I think this comes from x86 where the CALL instruction will push it > there. The fix in this patch is to scan the stack of the native (C++) > function looking for a pointer back to the frame of the native wrapper. > If we find this then the LR on entry should be saved in the stack slot > above. This fails if the native function stack frame is too big, or it's > a leaf function that didn't push FP/LR. But in this case setting this.pc > to null makes the frame object look invalid and so won't be printed, > instead of crashing. > > Sample output from the ClhsdbJstack.java jtreg test which passes now > with this patch: > > - java.lang.Thread.sleep(long) @bci=0, pc=0x0000ffffa05bb68c, > Method*=0x0000000800143410 (Compiled frame; information may be imprecise) > - jdk.test.lib.apps.LingeredApp.main(java.lang.String[]) @bci=53, > line=502, pc=0x0000ffff9892572c, Method*=0x0000ffff2e870d48 (Interpreted > frame) > > An alternative to scanning the native functions's stack might be to use > the last-known Java PC saved by set_last_Java_frame, this is off by a > few instructions but I don't think that matters. But this constructor > potentially has other users so we'd have to fix it anyway. > > Thanks, > Nick > From zgu at redhat.com Fri Feb 1 18:27:25 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 01 Feb 2019 13:27:25 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. Message-ID: <1549045645.31327.150.camel@redhat.com> After FastTLABRefill was removed, let's cleanup related perf counters. I removed perf counters for fast refill, and renamed perf counters for slow refill. I am not all clear what implication of renaming/removing exported symbols, and have no idea what aliasmap is for. So I ran all tests I think could be affected, showed no problem. Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ Test: hotspot_runtime, hotspot_serviceability, vmTestbase_nsk_monitoring, vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, vmTestbase_vm_jdwp on Linux x64 Eyeball output of jsnap Thanks, -Zhengyu From serguei.spitsyn at oracle.com Fri Feb 1 19:15:57 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 1 Feb 2019 11:15:57 -0800 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: <5C548928.5010304@oracle.com> References: <5C548928.5010304@oracle.com> Message-ID: <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: ??????????? display(""); ??????? } ??????? display(""); ??????? display("============="); ??????? display("TEST FINISHES\n"); ??????? brkpReq.disable(); ??????? debugee.resume(); ??????? debugee.quit(); ??? } Thanks, Serguei On 2/1/19 10:00, Gary Adams wrote: > When the remove_l005 runs to completion, it never signals the debuggee > that all iterations have completed. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 > > 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 > @@ -163,7 +163,6 @@ > ?vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java > 8066993 generic-all > ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java > 8065773 generic-all > ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all > -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java > 8068225 generic-all > > ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 > generic-all > ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 > generic-all > > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java > b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java > > --- > a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java > +++ > b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -134,6 +134,7 @@ > ???????????? } > ???????????? display(""); > ???????? } > +??????? debugee.sendSignal(SGNL_QUIT); > > ???????? display(""); > ???????? display("============="); From serguei.spitsyn at oracle.com Fri Feb 1 20:11:02 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 1 Feb 2019 12:11:02 -0800 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549045645.31327.150.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> Message-ID: An HTML attachment was scrubbed... URL: From zgu at redhat.com Fri Feb 1 20:25:58 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Fri, 01 Feb 2019 15:25:58 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: References: <1549045645.31327.150.camel@redhat.com> Message-ID: <1549052758.31327.152.camel@redhat.com> Hi Serguei, Thanks for reviewing. > On Fri, 2019-02-01 at 12:11 -0800, serguei.spitsyn at oracle.com wrote: > > Hi Zhengyu, > > > > > > > > I do not have enough expertise in this area but it looks good > > to > > me. > > > > > > > > > > > > http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/src/hotspot/s > > hare/gc/shared/threadLocalAllocBuffer.hpp.udiff.html > > > > > > > > Minor comment: > > > > void update_fast_allocations(unsigned int refills, > > size_t allocations, > > size_t gc_waste, > > - size_t fast_refill_waste, > > size_t slow_refill_waste); > > The slow_refill_waste > > needs to be renamed to refill_waste. Fixed in place. -Zhengyu > > > > > > > > > > Thanks, > > > > Serguei > > > > > > > > > > > > On 2/1/19 10:27, > > zgu at redhat.com wrote: > > > > > > After FastTLABRefill was removed, let's cleanup related perf > > counters. > > I removed perf counters for fast refill, and renamed perf counters > > for > > slow refill. > > > > I am not all clear what implication of renaming/removing exported > > symbols, and have no idea what aliasmap is for. So I ran all tests > > I > > think could be affected, showed no problem. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ > > > > Test: > > hotspot_runtime, hotspot_serviceability, > > vmTestbase_nsk_monitoring, > > vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, vmTestbase_vm_jdwp > > on Linux x64 > > > > Eyeball output of jsnap > > > > Thanks, > > > > -Zhengyu > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Feb 2 01:01:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 2 Feb 2019 11:01:53 +1000 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549045645.31327.150.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> Message-ID: <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> On 2/02/2019 4:27 am, zgu at redhat.com wrote: > After FastTLABRefill was removed, let's cleanup related perf counters. > I removed perf counters for fast refill, and renamed perf counters for > slow refill. > > I am not all clear what implication of renaming/removing exported > symbols, and have no idea what aliasmap is for. So I ran all tests I > think could be affected, showed no problem. Will need to check how perfcounters may be accessed before removing them. I don't know if external tools may access them as jvmstat does. David ----- > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ > > Test: > hotspot_runtime, hotspot_serviceability, vmTestbase_nsk_monitoring, > vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, vmTestbase_vm_jdwp > on Linux x64 > > Eyeball output of jsnap > > Thanks, > > -Zhengyu > From jini.george at oracle.com Sat Feb 2 02:51:15 2019 From: jini.george at oracle.com (Jini George) Date: Sat, 2 Feb 2019 08:21:15 +0530 Subject: Is RegisterMap updated? In-Reply-To: References: <21e8d6ff-41fa-10d6-813b-4d079196d34b@redhat.com> Message-ID: Hi David, This got removed in JDK-9 as a part of SA-JDI removal. (https://bugs.openjdk.java.net/browse/JDK-8158050). Could you let us know as to why are you using SA-JDI ? Thanks, Jini. On 2/1/2019 9:56 PM, David Griffiths wrote: > Had a nice simple little reproduction test, went to try it on Java 9 > and... oh no, sun.jvm.hotspot.jdi.SACoreAttachingConnector has > disappeared! Has it gone for good? > > Cheers, > > David > > On Wed, 30 Jan 2019 at 10:38, Andrew Haley wrote: >> >> On 1/30/19 10:00 AM, David Griffiths wrote: >>> I'm not sure this works though for the frame at the top of the stack. >>> The pushing of the registers that you mention appears to take place in >>> the updateRegisterMap method which is called when getting the sender. >>> At the top of the stack the register will be live and not saved >>> anywhere? >> >> No the pushing of the register happens in generated code. >> >>> Whatever, I'm seeing a NPE caused by a location that has >>> WHERE_IN_REGISTER and a register number of 16 that doesn't have >>> locationValid set in the map. If I modify createStackValue to check >>> valueAddr being null then it avoids the NPE and getLocals then returns >>> all the locals except for the one held in a register (the other ones >>> are on the stack). Not sure what a register number of 16 equates to on >>> x86, is that supposed to correspond to "not set" or something? >> >> You're not helping. Are you sure you've got an up-to-date HotSpot >> checkout? You're not falling over bug 8217407? >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.griffiths at gmail.com Sat Feb 2 09:29:46 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Sat, 2 Feb 2019 09:29:46 +0000 Subject: Is RegisterMap updated? In-Reply-To: References: <21e8d6ff-41fa-10d6-813b-4d079196d34b@redhat.com> Message-ID: Hi Jini, for that particular case, it just provides a simple way to reproduce more general problems in SA: first I run a program under gdb and with the option "-XX:CompileCommand=print,...", then I put a breakpoint at a particular place that I suspect the stack walker code has problems with. When the breakpoint hits, I do gcore in gdb and then have a core file to reproduce the problem with jstack or jdb using SACoreAttachingConnector etc. In this particular case I just enter the jdb "locals" command. The more general thing that I'm doing with the SA code (not sure what is defined as SA and what is SA-JDI but I think the classes I use are still there in Java 9, just harder to access) and that I mentioned to Andrew once and who probably thinks I'm nuts is to use it to effectively debug a java application under gdb. So it's a bit like the attaching to a live process situation using the pid (or a core file for that matter). The nature of our application means that we can't attach to the normal JDWP agent inside the JVM - we have to use gdb and cannot modify the state of the running JVM. I know the code I'm using is a bit fuzzy and imprecise - AMD64CurrentFrameGuess is a prime example that I've had to improve - but fuzzy is actually enough most of the time. Cheers, David On Sat, 2 Feb 2019 at 02:51, Jini George wrote: > > Hi David, > > This got removed in JDK-9 as a part of SA-JDI removal. > (https://bugs.openjdk.java.net/browse/JDK-8158050). Could you let us > know as to why are you using SA-JDI ? > > Thanks, > Jini. > > On 2/1/2019 9:56 PM, David Griffiths wrote: > > Had a nice simple little reproduction test, went to try it on Java 9 > > and... oh no, sun.jvm.hotspot.jdi.SACoreAttachingConnector has > > disappeared! Has it gone for good? > > > > Cheers, > > > > David > > > > On Wed, 30 Jan 2019 at 10:38, Andrew Haley wrote: > >> > >> On 1/30/19 10:00 AM, David Griffiths wrote: > >>> I'm not sure this works though for the frame at the top of the stack. > >>> The pushing of the registers that you mention appears to take place in > >>> the updateRegisterMap method which is called when getting the sender. > >>> At the top of the stack the register will be live and not saved > >>> anywhere? > >> > >> No the pushing of the register happens in generated code. > >> > >>> Whatever, I'm seeing a NPE caused by a location that has > >>> WHERE_IN_REGISTER and a register number of 16 that doesn't have > >>> locationValid set in the map. If I modify createStackValue to check > >>> valueAddr being null then it avoids the NPE and getLocals then returns > >>> all the locals except for the one held in a register (the other ones > >>> are on the stack). Not sure what a register number of 16 equates to on > >>> x86, is that supposed to correspond to "not set" or something? > >> > >> You're not helping. Are you sure you've got an up-to-date HotSpot > >> checkout? You're not falling over bug 8217407? > >> > >> -- > >> Andrew Haley > >> Java Platform Lead Engineer > >> Red Hat UK Ltd. > >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Sat Feb 2 13:38:11 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Sat, 02 Feb 2019 08:38:11 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> Message-ID: <1549114691.31327.157.camel@redhat.com> On Sat, 2019-02-02 at 11:01 +1000, David Holmes wrote: > On 2/02/2019 4:27 am, zgu at redhat.com wrote: > > After FastTLABRefill was removed, let's cleanup related perf > > counters. > > I removed perf counters for fast refill, and renamed perf counters > > for > > slow refill. > > > > I am not all clear what implication of renaming/removing exported > > symbols, and have no idea what aliasmap is for. So I ran all tests > > I > > think could be affected, showed no problem. > > Will need to check how perfcounters may be accessed before removing > them. I don't know if external tools may access them as jvmstat does. Yep, but It is hard to find out. I can not image this is the first one, how we dealt with before? Removing "_reserve_for_allocation_prefetch" breaks JDK8 tools, how it was communicated? Thanks, -Zhengyu > > David > ----- > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ > > > > Test: > > hotspot_runtime, hotspot_serviceability, > > vmTestbase_nsk_monitoring, > > vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, vmTestbase_vm_jdwp > > on Linux x64 > > > > Eyeball output of jsnap > > > > Thanks, > > > > -Zhengyu > > From zgu at redhat.com Sat Feb 2 14:09:02 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Sat, 02 Feb 2019 09:09:02 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549114691.31327.157.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> Message-ID: <1549116542.31327.159.camel@redhat.com> On Sat, 2019-02-02 at 08:38 -0500, zgu at redhat.com wrote: > On Sat, 2019-02-02 at 11:01 +1000, David Holmes wrote: > > On 2/02/2019 4:27 am, zgu at redhat.com wrote: > > > After FastTLABRefill was removed, let's cleanup related perf > > > counters. > > > I removed perf counters for fast refill, and renamed perf > > > counters > > > for > > > slow refill. > > > > > > I am not all clear what implication of renaming/removing exported > > > symbols, and have no idea what aliasmap is for. So I ran all > > > tests > > > I > > > think could be affected, showed no problem. > > > > Will need to check how perfcounters may be accessed before > > removing > > them. I don't know if external tools may access them as jvmstat > > does. > > Yep, but It is hard to find out. I can not image this is the first s/image/imagine -Zhengyu > one, > how we dealt with before? > > Removing "_reserve_for_allocation_prefetch" breaks JDK8 tools, how it > was communicated? > > Thanks, > > -Zhengyu > > > > > > David > > ----- > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ > > > > > > Test: > > > hotspot_runtime, hotspot_serviceability, > > > vmTestbase_nsk_monitoring, > > > vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, vmTestbase_vm_jdwp > > > on Linux x64 > > > > > > Eyeball output of jsnap > > > > > > Thanks, > > > > > > -Zhengyu > > > From Nick.Gasson at arm.com Sun Feb 3 03:01:38 2019 From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China)) Date: Sun, 3 Feb 2019 03:01:38 +0000 Subject: RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <4de13272-0f19-7897-3f4d-f4b5b56ca73f@oracle.com> References: <4de13272-0f19-7897-3f4d-f4b5b56ca73f@oracle.com> Message-ID: <5a9ebe53-0dea-6259-c070-6ed090f6895f@arm.com> Hi Jini, On 02/02/2019 02:16, Jini George wrote: > Do we reach here after AARCH64CurrentFrameGuess.run() fails to get the > PC ? Yes, that's right. It's the else branch (not interpreter and not compiler) that sets this.pc to null. > If so, was wondering if it would make more sense to scan from the > top of stack sp obtained from > context.getRegisterAsAddress(AARCH64ThreadContext.SP) to the sp of the > last known java frame with thread.getLastJavaSP() in > AARCH64CurrentFrameGuess.run() -- otherwise was wondering if we are > risking an exception by running off the top of the stack while scanning > in the upward direction (towards lower addresses) for > CALLEE_FRAME_SEARCH_LIMIT * addressSize from the previous Java SP > (though the scan range is small). > I think this is much better, thanks. But we still have the problem that the two-argument AARCH64Frame constructor is wrong: I don't think it's ever correct to assume the PC is at SP[-1]. And so we need to fix the other uses of it. I've made another patch that moves the frame scanning into LinuxAARCH64JavaThreadPDAccess.java, searching between the last-known Java SP and and current thread SP as described above. And we now use this to find a PC any time we would have called the two argument constructor before. http://cr.openjdk.java.net/~ngasson/8209413/webrev.02/ Please let me know what you think. + Assert.that(jcw.getLastJavaPC() != null, "last Java pc should be set"); I believe this is OK because the last Java SP/FP/PC are set by MacroAssembler::set_last_Java_frame, and I can't see any case where it would set SP and FP but not PC. Thanks, Nick From david.holmes at oracle.com Sun Feb 3 05:13:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 3 Feb 2019 15:13:23 +1000 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549114691.31327.157.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> Message-ID: Hi Zhengyu, On 2/02/2019 11:38 pm, zgu at redhat.com wrote: > On Sat, 2019-02-02 at 11:01 +1000, David Holmes wrote: >> On 2/02/2019 4:27 am, zgu at redhat.com wrote: >>> After FastTLABRefill was removed, let's cleanup related perf >>> counters. >>> I removed perf counters for fast refill, and renamed perf counters >>> for >>> slow refill. >>> >>> I am not all clear what implication of renaming/removing exported >>> symbols, and have no idea what aliasmap is for. So I ran all tests >>> I >>> think could be affected, showed no problem. >> >> Will need to check how perfcounters may be accessed before removing >> them. I don't know if external tools may access them as jvmstat does. > Yep, but It is hard to find out. I can not image this is the first one, > how we dealt with before? > > Removing "_reserve_for_allocation_prefetch" breaks JDK8 tools, how it > was communicated? I don't know what you are referring to. _reserve_for_allocation_prefetch was moved in 9 from Abstract_VM_Version to ThreadLocalAllocBuffer. http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6525e4ba82a1 It still exists there. And it is a plain int not a perf counter/variable. That aside we have in threadLocalAllocBuffer.cpp: 320 return PerfDataManager::create_variable(SUN_GC, PerfDataManager::counter_name("tlab", name), unit, THREAD); So these are in the SUN_GC namespace and anything in the sun namespace is unstable and unsupported: hotspot/share/runtime/perfData.cpp const char* PerfDataManager::_name_spaces[] = { // top level name spaces "java", // stable and supported name space "com.sun", // unstable but supported name space "sun", // unstable and unsupported name space So this should be okay. Thanks, David ----- > > Thanks, > > -Zhengyu > > >> >> David >> ----- >> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 >>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ >>> >>> Test: >>> hotspot_runtime, hotspot_serviceability, >>> vmTestbase_nsk_monitoring, >>> vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, vmTestbase_vm_jdwp >>> on Linux x64 >>> >>> Eyeball output of jsnap >>> >>> Thanks, >>> >>> -Zhengyu >>> From zgu at redhat.com Sun Feb 3 13:13:30 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Sun, 03 Feb 2019 08:13:30 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> Message-ID: <1549199610.31327.166.camel@redhat.com> > > Yep, but It is hard to find out. I can not image this is the first > > one, > > how we dealt with before? > > > > Removing "_reserve_for_allocation_prefetch" breaks JDK8 tools, how > > it > > was communicated? > > I don't know what you are referring to. > _reserve_for_allocation_prefetch > was moved in 9 from Abstract_VM_Version to ThreadLocalAllocBuffer. > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6525e4ba82a1 > > It still exists there. And it is a plain int not a perf > counter/variable. If I use JDK8's jinfo against java process using JDK13, I see following error: Attaching to process ID 31669, please wait... Error attaching to process: java.lang.RuntimeException: can't determine target's VM version : field "_reserve_for_allocation_prefetch" not found in type Abstract_VM_Version sun.jvm.hotspot.debugger.DebuggerException: java.lang.RuntimeException: can't determine target's VM version : field "_reserve_for_allocation_prefetch" not found in type Abstract_VM_Version at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:435) at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305) at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140) at sun.jvm.hotspot.tools.Tool.start(Tool.java:185) at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) at sun.jvm.hotspot.tools.JInfo.main(JInfo.java:138) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja va:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso rImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at sun.tools.jinfo.JInfo.runTool(JInfo.java:108) at sun.tools.jinfo.JInfo.main(JInfo.java:76) Caused by: java.lang.RuntimeException: can't determine target's VM version : field "_reserve_for_allocation_prefetch" not found in type Abstract_VM_Version at sun.jvm.hotspot.runtime.VM.(VM.java:291) at sun.jvm.hotspot.runtime.VM.initialize(VM.java:370) at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:431) ... 11 more I assume that this is the worst case if external tools are not updated accordingly. > > That aside we have in threadLocalAllocBuffer.cpp: > > 320 return PerfDataManager::create_variable(SUN_GC, > PerfDataManager::counter_name("tlab", name), unit, THREAD); > > So these are in the SUN_GC namespace and anything in the sun > namespace > is unstable and unsupported: > > hotspot/share/runtime/perfData.cpp > > const char* PerfDataManager::_name_spaces[] = { > // top level name spaces > "java", // stable and supported name space > "com.sun", // unstable but supported name space > "sun", // unstable and unsupported name space > > So this should be okay. Thanks for investigating and explaining. Can I take it as "reviewed"? -Zhengyu > > Thanks, > David > ----- > > > > > Thanks, > > > > -Zhengyu > > > > > > > > > > David > > > ----- > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ > > > > > > > > Test: > > > > hotspot_runtime, hotspot_serviceability, > > > > vmTestbase_nsk_monitoring, > > > > vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, > > > > vmTestbase_vm_jdwp > > > > on Linux x64 > > > > > > > > Eyeball output of jsnap > > > > > > > > Thanks, > > > > > > > > -Zhengyu > > > > From david.holmes at oracle.com Sun Feb 3 20:48:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Feb 2019 06:48:37 +1000 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549199610.31327.166.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> Message-ID: <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> On 3/02/2019 11:13 pm, zgu at redhat.com wrote: > >>> Yep, but It is hard to find out. I can not image this is the first >>> one, >>> how we dealt with before? >>> >>> Removing "_reserve_for_allocation_prefetch" breaks JDK8 tools, how >>> it >>> was communicated? >> >> I don't know what you are referring to. >> _reserve_for_allocation_prefetch >> was moved in 9 from Abstract_VM_Version to ThreadLocalAllocBuffer. >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6525e4ba82a1 >> >> It still exists there. And it is a plain int not a perf >> counter/variable. > > If I use JDK8's jinfo against java process using JDK13, I see following > error: Right you generally can't use the SA tools from one release with another release as the SA knows about the internal VM data structures. > Attaching to process ID 31669, please wait... > Error attaching to process: java.lang.RuntimeException: can't determine > target's VM version : field "_reserve_for_allocation_prefetch" not > found in type Abstract_VM_Version > sun.jvm.hotspot.debugger.DebuggerException: java.lang.RuntimeException: > can't determine target's VM version : field > "_reserve_for_allocation_prefetch" not found in type > Abstract_VM_Version Right as I said it was moved in 9 from Abstract_VM_Version to ThreadLocalAllocBuffer. > at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:435) > at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:305) > at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:140) > at sun.jvm.hotspot.tools.Tool.start(Tool.java:185) > at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) > at sun.jvm.hotspot.tools.JInfo.main(JInfo.java:138) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja > va:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso > rImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.tools.jinfo.JInfo.runTool(JInfo.java:108) > at sun.tools.jinfo.JInfo.main(JInfo.java:76) > Caused by: java.lang.RuntimeException: can't determine target's VM > version : field "_reserve_for_allocation_prefetch" not found in type > Abstract_VM_Version > at sun.jvm.hotspot.runtime.VM.(VM.java:291) > at sun.jvm.hotspot.runtime.VM.initialize(VM.java:370) > at sun.jvm.hotspot.HotSpotAgent.setupVM(HotSpotAgent.java:431) > ... 11 more > > I assume that this is the worst case if external tools are not updated > accordingly. What you encountered here is an issue with using the wrong version of the SA. Removing a public perf variable/counter is a different scenario, but would likely lead to a similar exception. >> >> That aside we have in threadLocalAllocBuffer.cpp: >> >> 320 return PerfDataManager::create_variable(SUN_GC, >> PerfDataManager::counter_name("tlab", name), unit, THREAD); >> >> So these are in the SUN_GC namespace and anything in the sun >> namespace >> is unstable and unsupported: >> >> hotspot/share/runtime/perfData.cpp >> >> const char* PerfDataManager::_name_spaces[] = { >> // top level name spaces >> "java", // stable and supported name space >> "com.sun", // unstable but supported name space >> "sun", // unstable and unsupported name space >> >> So this should be okay. > > Thanks for investigating and explaining. Can I take it as "reviewed"? No sorry I didn't review it. Not at all familiar with TLAB or these stats. Isn't this more a GC than runtime issue? David ----- > -Zhengyu > > >> >> Thanks, >> David >> ----- >> >>> >>> Thanks, >>> >>> -Zhengyu >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 >>>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ >>>>> >>>>> Test: >>>>> hotspot_runtime, hotspot_serviceability, >>>>> vmTestbase_nsk_monitoring, >>>>> vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, >>>>> vmTestbase_vm_jdwp >>>>> on Linux x64 >>>>> >>>>> Eyeball output of jsnap >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> From zgu at redhat.com Sun Feb 3 21:41:37 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Sun, 03 Feb 2019 16:41:37 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> Message-ID: <1549230097.31327.171.camel@redhat.com> > > > > Thanks for investigating and explaining. Can I take it as > > "reviewed"? > > No sorry I didn't review it. Not at all familiar with TLAB or these > stats. Isn't this more a GC than runtime issue? > I think it is more on GC side, but JDK-8194084 was fixed under Runtime. Cc'd gc-dev. Thanks, -Zhengy > David > ----- > > > -Zhengyu > > > > > > > > > > Thanks, > > > David > > > ----- > > > > > > > > > > > Thanks, > > > > > > > > -Zhengyu > > > > > > > > > > > > > > > > > > David > > > > > ----- > > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > > > > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev. > > > > > > 00/ > > > > > > > > > > > > Test: > > > > > > hotspot_runtime, hotspot_serviceability, > > > > > > vmTestbase_nsk_monitoring, > > > > > > vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, > > > > > > vmTestbase_vm_jdwp > > > > > > on Linux x64 > > > > > > > > > > > > Eyeball output of jsnap > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -Zhengyu > > > > > > From zgu at redhat.com Sun Feb 3 21:43:00 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Sun, 03 Feb 2019 16:43:00 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> Message-ID: <1549230180.31327.172.camel@redhat.com> > > No sorry I didn't review it. Not at all familiar with TLAB or these > stats. Isn't this more a GC than runtime issue? > I think it is more on GC side, but JDK-8194084 was fixed under Runtime. Cc'd gc-dev. Thanks, -Zhengy > David > ----- > > > -Zhengyu > > > > > > > > > > Thanks, > > > David > > > ----- > > > > > > > > > > > Thanks, > > > > > > > > -Zhengyu > > > > > > > > > > > > > > > > > > David > > > > > ----- > > > > > > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > > > > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev. > > > > > > 00/ > > > > > > > > > > > > Test: > > > > > > hotspot_runtime, hotspot_serviceability, > > > > > > vmTestbase_nsk_monitoring, > > > > > > vmTestbase_nsk_jdi, vmTestbase_nsk_jvmti, > > > > > > vmTestbase_vm_jdwp > > > > > > on Linux x64 > > > > > > > > > > > > Eyeball output of jsnap > > > > > > > > > > > > Thanks, > > > > > > > > > > > > -Zhengyu > > > > > > From david.holmes at oracle.com Mon Feb 4 08:40:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 4 Feb 2019 18:40:57 +1000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <4c797f80a87748c5bb260ea5715be75e@jd.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> Message-ID: Hi Lin, Sorry but can I just confirm that you have signed the OCA [1]? I don't see you listed individually and I can't tell what company you work for or whether your are contributing on their behalf. Thanks, David [1] http://www.oracle.com/technetwork/oca-405177.pdf On 31/01/2019 4:42 pm, ?? wrote: > Hi David, Paul, > I have uploaded the refined webrev at > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > May I ask your help to review? > Thanks! > > BRs, > Lin > ________________________________________ > From: David Holmes > Sent: Thursday, January 31, 2019 9:19:31 AM > To: Hohensee, Paul; ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: >> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > Yes. Changes to command-line flags need a CSR. > > Thanks, > David > >> Thanks, >> >> Paul >> >> ?On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: >> >> A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. >> >> vm.heapHisto("", "-live") >> >> Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to >> >> * 'vm.heapHisto("", "-live")' will request a full GC >> >> In attachListener.cpp, the line >> >> out->print_cr("Invalid argument to dumpheap operation: %s", arg1); >> >> should be >> >> out->print_cr("Invalid argument to inspectheap operation: %s", arg1); >> >> Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. >> >> Paul >> >> On 1/30/19, 12:18 AM, "??" wrote: >> >> Dear All, >> This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. >> I have identified the root cause of the issue. it is caused by 2 problems. >> 1. The path processing in heap_inspection() at attachListener.cpp. >> The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. >> I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. >> >> 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. >> >> I have upload a webrev05: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ >> >> May I ask your help for review? >> >> Thanks, >> Lin >> ________________________________________ >> From: ?? >> Sent: Monday, January 28, 2019 5:49:42 PM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear all, >> I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. >> Thanks! >> >> BRs, >> Lin >> ________________________________________ >> From: ?? >> Sent: Friday, January 25, 2019 9:00:19 AM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear All, >> May I get more review about this webrev? >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ >> >> Thanks! >> BRs, >> Lin >> ________________________________________ >> From: ?? >> Sent: Tuesday, January 22, 2019 2:18:06 PM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Paul, >> Thanks a lot for your review. I have refined it based on your comments. >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ >> Would you like to help review it again? Thanks >> >> BRs, >> Lin >> ________________________________________ >> From: Hohensee, Paul >> Sent: Friday, January 18, 2019 6:11:14 AM >> To: ??; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Just a few small things. >> >> In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. >> >> In attachListener.cpp, line 275, change "Fail to" to "Failed to". >> >> In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. >> >> Thanks, >> >> Paul >> >> On 1/11/19, 1:39 AM, "??" wrote: >> >> Hi Jc, Paul and All, >> Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ >> would you like to help review? >> >> Thanks, >> Lin >> ________________________________________ >> From: ?? >> Sent: Friday, January 11, 2019 10:25:27 AM >> To: JC Beyler >> Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net >> Subject: ??: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Jc, >> Thanks a lot. it is not a necessary change, I forget to omit it:) >> >> BRs, >> Lin >> ________________________________ >> ???: JC Beyler >> ????: 2019?1?11? 0:58:22 >> ???: ?? >> ??: Hohensee, Paul; serviceability-dev at openjdk.java.net >> ??: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> Small nit: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html >> >> needs a copyright update, >> Jc >> >> >> On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: >> Dear All, >> I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ >> Would you like to help review? Thanks! >> >> BRs, >> Lin >> From: ?? >> Sent: Wednesday, January 9, 2019 11:00 AM >> To: 'JC Beyler' > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: RE: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear JC, >> Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. >> >> Cheers, >> Lin >> >> From: JC Beyler > >> Sent: Wednesday, January 9, 2019 10:51 AM >> To: ?? > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> Inlined as well :-) >> >> On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: >> Dear JC, >> Thanks for your comments, I inlined my comments here: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? >> --- (Lin) I will do that in next webrev. >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) >> --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? >> >> >> No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? >> >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". >> ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. >> >> I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. >> >> Thanks! >> Jc >> >> >> All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. >> >> Cheers, >> Lin >> >> >> From: JC Beyler > >> Sent: Wednesday, January 9, 2019 1:42 AM >> To: ?? > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> I have a few nits: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> >> You could fix the spaces arount the for loop you changed: >> >> + for (int i=0; i<4; i++) { >> to >> >> + for (int i = 0; i < 4; i++) { >> >> >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) >> >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html >> + filename = opt.substring(5); >> + if (filename != null) { >> -> I don't see how filename can be null here >> -> same filename could just be declared in the if >> >> >> >> + } else if (subopt.startsWith("file=")) { >> + filename = parseFileName(subopt); >> >> -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? >> >> -> in the option string printouts, you don't specify that all is an option as well, is that normal? >> >> >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". >> >> Thanks, >> Jc >> >> On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: >> >> Hi Paul, >> I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. >> And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ >> >> Hi All, >> May I also ask your help for reviewing this webrev? >> webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 >> >> Thanks! >> Lin >> >> ________________________________ >> ???: serviceability-dev > ?? ?? > >> ????: 2019?1?3? 10:21 >> ???: Hohensee, Paul; serviceability-dev at openjdk.java.net >> ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo >> >> >> Dear Paul, >> >> Thanks a lot for your review! I am trying to remend the patch >> >> One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. >> >> so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would >> >> be more reasonable than the ?if else? ? >> >> Thanks >> >> >> >> BRs, >> >> Lin >> >> >> >> >> >> >> >> From: Hohensee, Paul > >> Sent: Saturday, December 29, 2018 3:54 AM >> To: ?? >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> >> >> Update the copyright dates to 2019 please, since this won?t get pushed until then. >> >> >> >> In JMap.java, I?d emulate dump() and use >> >> >> >> String filename = null; >> >> String subopts[] = options.split(","); >> >> >> >> for (String subopt : subopts){ >> >> if (subopt.isEmpty() || subopt.equals("all")) { >> >> // pass >> >> } else if (subopt.equals("live")) { >> >> liveopt = "-live"; >> >> } else if (subopt.startsWith("file=")) { >> >> // file= - check that is specified >> >> if (subopt.length() > 5) { >> >> filename = subopt.substring(5); >> >> } >> >> } else { >> >> usage(1); >> >> } >> >> } >> >> >> >> // get the canonical path - important to avoid just passing >> >> // a "heap.bin" and having the dump created in the target VM >> >> // working directory rather than the directory where jmap >> >> // is executed. >> >> filename = new File(filename).getCanonicalPath(); >> >> // inspectHeap is not the same as jcmd GC.class_histogram >> >> executeCommandForPid(pid, "inspectheap", filename, liveopt); >> >> >> >> I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). >> >> >> >> The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. >> >> >> >> Thanks, >> >> >> >> Paul >> >> >> >> From: serviceability-dev > on behalf of ?? > >> Date: Thursday, December 20, 2018 at 11:03 PM >> To: "serviceability-dev at openjdk.java.net" > >> Subject: [RFR]8215622: Add dump to file support for jmap histo >> >> >> >> Hi All, >> >> May I ask your help to review this patch for enhance jmap ?histo. >> >> It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. >> >> This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. >> >> >> >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 >> >> >> >> Thanks. >> >> >> >> BRs, >> >> Lin >> >> >> >> >> >> >> >> >> -- >> >> Thanks, >> Jc >> >> >> -- >> >> Thanks, >> Jc >> >> >> -- >> >> Thanks, >> Jc >> >> >> >> >> >> From yasuenag at gmail.com Mon Feb 4 12:30:04 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 4 Feb 2019 21:30:04 +0900 Subject: PING: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: PING: Could you review it? >> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ Thanks, Yasumasa On 2019/01/28 9:35, Yasumasa Suenaga wrote: > Hi all, > > This change has passed tests as below (all of jhsdb related tests): > > ?- Submit repo > ?- All hotspot/jtreg/serviceability/sa > ?- hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > ?- All jdk/sun/tools/jhsdb > ?- jdk/tools/launcher/HelpFlagsTest.java > > > Comments are welcome. > > > Thanks, > > Yasumasa > > > On 2019/01/26 13:43, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ >> >> SA will handle `Flags` enums to get flag origin. >> However SA has const value for bitmask for flag, and shows as raw (int) value. >> This issue is commented in [1]. >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] http://hg.openjdk.java.net/jdk/jdk/file/8c035b34248d/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java#l166 From jini.george at oracle.com Mon Feb 4 13:39:29 2019 From: jini.george at oracle.com (Jini George) Date: Mon, 4 Feb 2019 19:09:29 +0530 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: <2744c4d7-a75b-a916-9b6a-e746cc6c3e50@oracle.com> References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> <2744c4d7-a75b-a916-9b6a-e746cc6c3e50@oracle.com> Message-ID: <7c13fc0e-060e-65f2-e5f4-68641e1f7c67@oracle.com> Pinging again -- requesting for a Reviewer to take a look. The patch has been rebased again to include the changes of JDK-8217473 to rethrow SkippedException for the tests refactored to use ClhsdbLauncher. webrev: http://cr.openjdk.java.net/~jgeorge/8215568/webrev.04/index.html Thanks, Jini. On 1/16/2019 9:59 AM, Jini George wrote: > Ping! > > Need a Reviewer please. > > The patch rebased to the latest changes is at: > > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.03/index.html > > Thanks, > Jini. > > On 1/10/2019 8:40 PM, Jini George wrote: >> Gentle reminder -- Could I please let a Reviewer to take a look at this? >> >> Thanks, >> Jini. >> >> On 1/8/2019 10:36 PM, Jini George wrote: >>> Thank you so much for the great catch, JC! Yes, indeed, the test >>> passed inspite of 'printmado' being an unrecognized command. I have >>> filed https://bugs.openjdk.java.net/browse/JDK-8216352 to handle >>> issues like these. >>> >>> I have the corrected webrev at: >>> >>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.02/index.html >>> >>> Could I get a Reviewer also to take a look at this ? >>> >>> Thank you, >>> Jini. >>> >>> On 1/8/2019 12:12 AM, JC Beyler wrote: >>>> Hi Jini, >>>> >>>> I saw this typo: >>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>> >>>> >>>> +? ? ? ? ? ? List cmds = List.of("printmado -a"); >>>> >>>> Should it not be printmdo and not printmado? does printmado exist? >>>> If it doesn't how does the test pass (my guess is that we do not >>>> catch a "unexpected command" and that the hashmaps are not finding >>>> the keys so they are not checking the expected/unexpected results; >>>> if so perhaps a follow-up should fix that an unknown command fails a >>>> test trying to do that / and perhaps if the key is not found, the >>>> test fails as well?) >>>> >>>> Thanks! >>>> Jc >>>> >>>> On Tue, Jan 1, 2019 at 9:07 PM Jini George >>> > wrote: >>>> >>>> ??? Thank you very much for the review, JC. My comments inline. >>>> >>>> >>>> ???? > I saw this potential issue with one of the test conversions: >>>> ???? > >>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>> >>>> ???? >? ? ?- It seems like there is a missing "unexpected" strings >>>> check >>>> ??? here no? >>>> ???? >? ? ? ? - The original test was doing >>>> ???? > - >>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("missing reason for ")) { >>>> ???? > -? ? ? ? ? ? ? ? ? ? unexpected = new >>>> ??? RuntimeException("Unexpected msg: >>>> ???? > missing reason for "); >>>> ???? > -? ? ? ? ? ? ? ? ? ? break; >>>> ???? > -? ? ? ? ? ? ? ? } >>>> ???? > >>>> ???? > whereas the new test is not seemingly (though >>>> ???? > >>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java.udiff.html >>>> >>>> >>>> ???? > does do it so I think this is an oversight?). >>>> >>>> ??? Thank you very much for pointing this out! This was an oversight. I >>>> ??? have >>>> ??? added the unexpected strings check. >>>> >>>> ???? > >>>> ???? >? ? ?- Also interesting is that the original test was trying to >>>> ??? find one >>>> ???? > of X: >>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("VirtualCallData")? || >>>> ???? > -? ? ? ? ? ? ? ? ? ? line.contains("CounterData")? ? ? || >>>> ???? > -? ? ? ? ? ? ? ? ? ? line.contains("ReceiverTypeData")) { >>>> ???? > -? ? ? ? ? ? ? ? ? ? knownProfileDataTypeFound = true; >>>> ???? > -? ? ? ? ? ? ? ? } >>>> ???? > >>>> ???? > whereas you are now wanting to find all of them. Is that >>>> ??? normal/wanted? >>>> >>>> ??? I was being extra cautious when I had written this test case in the >>>> ??? beginning :-). As far as I have seen, the printmdo output does >>>> contain >>>> ??? all of these. (The test passes with 50 repeated runs across all hs >>>> ??? tiers >>>> ??? with the changes -- so I believe it is OK). >>>> >>>> ??? I have the new webrev at: >>>> >>>> ??? http://cr.openjdk.java.net/~jgeorge/8215568/webrev.01/ >>>> >>>> ??? I have additionally modified the copyright year to 2019. >>>> >>>> ??? Thank you, >>>> ??? Jini. >>>> >>>> >>>> ???? > >>>> ???? > The rest looked good to me, though I wish there were a way to >>>> not >>>> ??? have >>>> ???? > to change all the strings to be regex friendly but I fail to see >>>> ??? how to >>>> ???? > do that without writing a runCmdWithoutRegexMatcher, which seems >>>> ???? > overkill :-) >>>> ???? > Jc >>>> ???? > >>>> ???? > On Tue, Dec 18, 2018 at 8:55 PM Jini George >>>> ??? >>>> ???? > >> >>>> ??? wrote: >>>> ???? > >>>> ???? >? ? ?Hello! >>>> ???? > >>>> ???? >? ? ?Requesting reviews for: >>>> ???? > >>>> ???? > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/ >>>> ???? > >>>> ???? >? ? ?BugID: https://bugs.openjdk.java.net/browse/JDK-8215568 >>>> ???? > >>>> ???? >? ? ?No new failures with the SA tests (hs-tiers 1-5) with these >>>> ??? changes. >>>> ???? >? ? ?The >>>> ???? >? ? ?changes here include: >>>> ???? > >>>> ???? >? ? ?* Refactoring the SA tests which test clhsdb commands to use >>>> ???? >? ? ?ClhsdbLauncher for uniformity and ease of maintainence. >>>> ???? >? ? ?* Testing for regular expressions with shouldMatch rather >>>> than >>>> ???? >? ? ?shouldContain. >>>> ???? >? ? ?* Minor cleanups. >>>> ???? > >>>> ???? >? ? ?Thank you, >>>> ???? >? ? ?Jini. >>>> ???? > >>>> ???? > >>>> ???? > >>>> ???? > >>>> ???? > -- >>>> ???? > >>>> ???? > Thanks, >>>> ???? > Jc >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc From gary.adams at oracle.com Mon Feb 4 14:01:22 2019 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 04 Feb 2019 09:01:22 -0500 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier Message-ID: <5C5845B2.40004@oracle.com> Two of the redefine classes tests (021, 023) have been on the ProblemList since they were first brought into the open repos. Both tests made an incorrect assumption about the access modifiers in class files. There is a single bit in the binary class file that defines if an interface is public or not public (See JVMS Table 4.1-B ACC_PUBLIC). When the test classes are compiled for use in the redefine operation, if a source used public or protected the ACC_PUBLIC bit was set. Several modifiers are used in these tests to confirm UnsupportedOperationException is thrown or not thrown. This proposed change simply corrects the expected results according to the JVM Specification. Webrev: http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html From coleen.phillimore at oracle.com Mon Feb 4 15:08:35 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 10:08:35 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks Message-ID: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> Summary: Walk code cache and deoptimize once per redefinition.* *This change touches the AOT and code cache code.? I tried to describe it in the comments in the RFE.? Basically, for redefinition, we walk the code cache per class redefined in order to find evol_method dependencies, then deoptimize if we find them, and then walk the code cache again to mark the deoptimized nmethods as not_entrant. I replaced this with only marking any nmethods for the class's methods to deoptimize (following InstanceKlass::_methods), also marking aot methods dependent on the class, and then doing the code cache walk to follow the evol_method dependencies at the end of redefinition for all the classes.?? The new code uses the Method::is_old() flag rather than comparing each method in the InstanceKlass.? Then deoptimization and marking not_entrant is done once at the end of the redefinition as well. Tested with tier1-6, all the redefinition tests locally: make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >&redefine.out make test TEST=open/test/jdk/java/lang/instrument >&instrument.out new test, and JMH test (see CR for results). Thanks, Coleen -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Mon Feb 4 17:43:21 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Feb 2019 17:43:21 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <5a9ebe53-0dea-6259-c070-6ed090f6895f@arm.com> References: <4de13272-0f19-7897-3f4d-f4b5b56ca73f@oracle.com> <5a9ebe53-0dea-6259-c070-6ed090f6895f@arm.com> Message-ID: <2f5666be-ee9c-e6bf-aa72-eb999ad6aba5@redhat.com> On 2/3/19 3:01 AM, Nick Gasson (Arm Technology China) wrote: > I think this is much better, thanks. But we still have the problem > that the two-argument AARCH64Frame constructor is wrong: I don't > think it's ever correct to assume the PC is at SP[-1]. Really? We push it there when we make runtime calls from C2 and that's also where we put it in all compiler-generated code. I'll grant you that's not where native-compiler-generated code puts it, so we can't guarantee it'll be there. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jcbeyler at google.com Mon Feb 4 17:47:30 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 4 Feb 2019 09:47:30 -0800 Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: References: <1b6d4030-4980-7fd0-7784-72987239647a@oracle.com> Message-ID: Hi Jini, The webrev looks good to me but I was wondering why you are changing the tests really. For example: http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/test/hotspot/jtreg/serviceability/sa/ClhsdbAttach.java.html The main method already is declared to be throwing the top class Exception. It seems to me that you could then skip updating the tests: + } catch (SkippedException se) { + throw se; no? Probably I'm missing something but seemed like you didn't need to add this if you were just rethrowing it. On Wed, Jan 30, 2019 at 8:39 PM Jini George wrote: > Thank you, David! > > - Jini. > > On 1/31/2019 7:45 AM, David Holmes wrote: > > Hi Jini, > > > > This looks reasonable to me. > > > > Thanks, > > David > > > > On 30/01/2019 9:59 pm, Jini George wrote: > >> Requesting reviews for: > >> > >> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 > >> Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html > >> > >> The patch includes changes to use SkippedException to skip the tests > >> when canPtraceAttachLinux() in Platform.java returns false. > >> > >> Thanks, > >> Jini. > >> > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Feb 4 18:01:38 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 4 Feb 2019 10:01:38 -0800 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <5C5845B2.40004@oracle.com> References: <5C5845B2.40004@oracle.com> Message-ID: Hi Gary, The webrev looks good to me (I don't like the general way the tests are written with "i" as a test iterator but that's a different conversation ;-)) Thanks, Jc On Mon, Feb 4, 2019 at 6:03 AM Gary Adams wrote: > Two of the redefine classes tests (021, 023) have been on the > ProblemList since they > were first brought into the open repos. Both tests made an incorrect > assumption > about the access modifiers in class files. There is a single bit in the > binary class file that > defines if an interface is public or not public (See JVMS Table 4.1-B > ACC_PUBLIC). > When the test classes are compiled for use in the redefine operation, if > a source > used public or protected the ACC_PUBLIC bit was set. > > Several modifiers are used in these tests to confirm > UnsupportedOperationException > is thrown or not thrown. This proposed change simply corrects the > expected results > according to the JVM Specification. > > Webrev: http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Mon Feb 4 18:25:34 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 Feb 2019 18:25:34 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: Message-ID: On 2/1/19 9:22 AM, Nick Gasson (Arm Technology China) wrote: > It takes the last-known Java SP and FP, and tries to find the PC > following the BL instruction that jumped to the native code. At the > moment it assumes this is at SP[-1]: That's where it should be. Please tell me which code it is that jumps to the native code. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From serguei.spitsyn at oracle.com Mon Feb 4 18:40:37 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 10:40:37 -0800 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <5C5845B2.40004@oracle.com> References: <5C5845B2.40004@oracle.com> Message-ID: Hi Gary, Looks good to me. Thank you for the update! Thanks, Serguei On 2/4/19 06:01, Gary Adams wrote: > Two of the redefine classes tests (021, 023) have been on the > ProblemList since they > were first brought into the open repos. Both tests made an incorrect > assumption > about the access modifiers in class files. There is a single bit in > the binary class file that > defines if an interface is public or not public (See JVMS Table 4.1-B > ACC_PUBLIC). > When the test classes are compiled for use in the redefine operation, > if a source > used public or protected the ACC_PUBLIC bit was set. > > Several modifiers are used in these tests to confirm > UnsupportedOperationException > is thrown or not thrown. This proposed change simply corrects the > expected results > according to the JVM Specification. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html From Nick.Gasson at arm.com Mon Feb 4 18:51:52 2019 From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China)) Date: Mon, 4 Feb 2019 18:51:52 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: , Message-ID: Hi Andrew > Please tell me which code it is that jumps to the native code. SharedRuntime::generate_native_wrapper. The SP here is saved in the thread state by set_last_Java_frame. Nick ________________________________ From: Andrew Haley Sent: 05 February 2019 02:25:34 To: Nick Gasson (Arm Technology China); serviceability-dev at openjdk.java.net Cc: nd; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command On 2/1/19 9:22 AM, Nick Gasson (Arm Technology China) wrote: > It takes the last-known Java SP and FP, and tries to find the PC > following the BL instruction that jumped to the native code. At the > moment it assumes this is at SP[-1]: That's where it should be. Please tell me which code it is that jumps to the native code. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon Feb 4 20:34:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 12:34:21 -0800 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> Message-ID: <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> Added the serviceability-dev back. Thanks, Serguei On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8139551 > > The links. > Thanks, > Coleen > > On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >> Summary: Walk code cache and deoptimize once per redefinition.* >> >> *This change touches the AOT and code cache code.? I tried to >> describe it in the comments in the RFE.? Basically, for redefinition, >> we walk the code cache per class redefined in order to find >> evol_method dependencies, then deoptimize if we find them, and then >> walk the code cache again to mark the deoptimized nmethods as >> not_entrant. >> >> I replaced this with only marking any nmethods for the class's >> methods to deoptimize (following InstanceKlass::_methods), also >> marking aot methods dependent on the class, and then doing the code >> cache walk to follow the evol_method dependencies at the end of >> redefinition for all the classes.?? The new code uses the >> Method::is_old() flag rather than comparing each method in the >> InstanceKlass.? Then deoptimization and marking not_entrant is done >> once at the end of the redefinition as well. >> >> Tested with tier1-6, all the redefinition tests locally: >> >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >> >&redefine.out >> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >> >> new test, and JMH test (see CR for results). >> >> Thanks, >> Coleen >> >> > From daniil.x.titov at oracle.com Mon Feb 4 21:24:02 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 04 Feb 2019 13:24:02 -0800 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> References: <8550b971-eede-c9ce-6eb9-4ec1671dbce3@oracle.com> <3C6EC1EF-672D-4577-9EEF-2CF73BDED256@oracle.com> <2a75f4de-6a77-615e-1648-0fcca59c6ea2@oracle.com> <0B661A5C-E59D-481C-BC3B-0951621F1F51@oracle.com> <5e9c223c-71c5-980e-03b9-679e69942f23@oracle.com> <0194722E-CFE1-4E3A-A521-14910D88B378@oracle.com> <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> Message-ID: <2599EF95-2EC5-4CE7-8036-33D9863631CB@oracle.com> Hi Serguei, Thank you for reviewing this fix. Please review a new version of the fix that includes all changes you suggested but one about lines 88-91 and 97-101. 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { 89 i++; 90 continue; 91 } ... 97 // If this is a classpath option then skip the next part as well ( the classpath itself) 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { 99 i++; 100 continue; 101 } 102 // Skip all other Java options 103 if (parts[i].startsWith("-")) { 104 continue; 105 } You are right, these statements are needed to filter out the parts which have nothing to do with the mainClass. But we cannot remove these lines and just return the latest part[i] that was not filtered out as the mainClass since it will not work in the case when the command line includes arguments specified after the main class. In the approach we use the main class is the *first* part[i] (with i > 0) that is not a Java option ( part[i] that doesn't start with '-' and is not classpath, module path, jar file path or module name). This condition that the mainClass is not null is checked on line 89 inside for loop. 89 for (int i = 1; i < parts.length && mainClass == null; i++) { To simplify the code in the new version of the patch the lines 88-91 and 97-101 are combined in the one "if" block. Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.04 Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks. --Daniil From: "serguei.spitsyn at oracle.com" Date: Thursday, January 31, 2019 at 1:23 PM To: David Holmes , Daniil Titov , serviceability-dev Subject: Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out Hi Daniil, I have some secondary comment on new file: http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java.html 70 for (int i = 0; i < parts.length && mainClass == null; i++) { 71 // Check the executable 72 if (i == 0) { 73 String[] executablePath = parts[i].split("/"); 74 if (executablePath.length > 0) { 75 String binaryName = executablePath[executablePath.length - 1]; 76 if (!"java".equals(binaryName)) { 77 // Skip the process if it is not started with java launcher 78 return null; 79 } 80 } 81 continue; 82 } ? It is better execute the logic in lines 73-80 before the loop. ? It will simplify the code a little bit. String[] executablePath = parts[i].split("/"); if (executablePath.length > 0) { String binaryName = executablePath[executablePath.length - 1]; if (!binaryName.equals("java") { return null; // Skip the process if it is not started with java launcher } } for (int i = 1; i < parts.length && mainClass == null; i++) { In the fragment below: ? 83 // Check if the module is executed with explicitly specified main class 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { 85 mainClass = getMainClassFromModuleArg(parts[i + 1]); 86 break; 87 } would it better to just return the main class instead of having a break statement? : 85 return getMainClassFromModuleArg(parts[i + 1]); The lines: 108 if (jarFile != null) { 109 return getMainClassFromJar(jarFile, pid); 110 } is better to execute inside the loop the same as it is done for getMainClassFromModuleArg(). // Check if the main class needs to be read from the manifest.mf in a JAR file if (parts[i].equals("-jar") && i < parts.length - 1) { return getMainClassFromJar(jarFile, pid); } In the if statements: 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { ... ?93 if (parts[i].equals("-jar") && i < parts.length - 1) { the last condition (i < parts.length - 1) is better to make the first (pre-condition). They even can be combined together like below: if (i < parts.length - 1) { if ((parts[i].equals("-m") || parts[i].equals("--module"))) { return getMainClassFromModuleArg(parts[i + 1]); } // Check if the main class needs to be read from the manifest.mf in a JAR file if (parts[i].equals("-jar") ) { return getMainClassFromJar(jarFile, pid); } } ? The biggest concern are the fragments: 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { 89 i++; 90 continue; 91 } ... 97 // If this is a classpath option then skip the next part as well ( the classpath itself) 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { 99 i++; 100 continue; 101 } 102 // Skip all other Java options 103 if (parts[i].startsWith("-")) { 104 continue; 105 } ?If I understand it correctly, these statements are needed to filter out ?the parts which have nothing to do with the mainClass. ?The latest part[i] that was not filtered out is returned as the mainClass. ?I'm thinking about more general approach here. Probably, we just need to remove ?the fragments 88-91 and 97-101 as they are covered by the fragment 102-105. ?It will also simplify the code. ?With all the suggestion above it should converge to something like this: String[] parts = cmdLine.split(" "); ?String mainClass = null; String[] executablePath = parts[i].split("/"); if (executablePath.length > 0) { String binaryName = executablePath[executablePath.length - 1]; if (!binaryName.equals("java") { return null; // Skip the process if it is not started with java launcher } } for (int 1 = 0; i < parts.length && mainClass == null; i++) { if (i < parts.length - 1) { if ((parts[i].equals("-m") || parts[i].equals("--module"))) { return getMainClassFromModuleArg(parts[i + 1]); } // Check if the main class needs to be read from the manifest.mf in a JAR file if (parts[i].equals("-jar") ) { return getMainClassFromJar(parts[i + 1], pid); } } // Skip all other Java options if (parts[i].startsWith("-")) { continue; } mainClass = parts[i]; } return mainClass; http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java.html 49 if (cmd.equals("quit")) { 50 log("'quit' received"); 51 52 } else { The empty line 51 can be removed. ?Looking at this command-line processing I kind of understand the David's concern. Thanks, Serguei On 1/20/19 21:18, David Holmes wrote: Thanks for the update Daniil. I still remain concerned about the robustness of the command-line parsing - this seems like a feature that needs its own set of tests. I'll leave it up to Serguei and others as to how to proceed. David ----- On 19/01/2019 9:08 am, Daniil Titov wrote: Hi David and Serguei, Please review a new version of the fix that now covers the case when Java executes a module with the main class name explicitly specified in the command line. Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.03 Bug: : https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks! --Daniil ?On 1/8/19, 6:05 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: ???? Hi Daniil, ???? ???? Sorry this slipped through the Xmas break cracks :) ???? ???? On 22/12/2018 12:04 pm, Daniil Titov wrote: ???? > Hi David and Serguei, ???? > ???? > Please review a new version of the fix that for Linux platform uses the proc filesystem to retrieve the main class name for the running Java process. ???? > ???? > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.02/ ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 ???? ???? It's more complex than I had envisaged but seems to be doing the job. ???? I'm not sure how robust the command-line parsing is, in particular it ???? doesn't handle these forms: ???? ???????? or? java [options] -m [/] [args...] ???????????? java [options] --module [/] [args...] ???????????????? (to execute the main class in a module) ???? ???? I can't really comment on all the details. ???? ???? Thanks, ???? David ???? ----- ???? ???? > Thanks, ???? > Daniil ???? > ???? > ?On 11/29/18, 4:52 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: ???? > ???? >????? Hi Daniil, ???? > ???? >????? On 30/11/2018 7:30 am, Daniil Titov wrote: ???? >????? > Thank you, David! ???? >????? > ???? >????? > The proposed fix didn't help. It still hangs at some occasions.? Additional tracing showed that when jcmd is invoked with the main class name it iterates over all running Java processes and temporary attaches to them to retrieve the main class name. It hangs while trying to attach to one of the running Java processes. There are numerous Java processes running at the host machine some associated with the test framework itself and another with the tests running in parallel. It is not clear what exact is this particular process since the jcmd hangs before retrieving the process' main class name, but after all tests terminated the process with this id is no longer running.? I have to revoke this review since more investigation is required. ???? > ???? >????? That sounds like an unsolvable problem for the test. You can't control ???? >????? other Java processes on the machine, and searching by name requires ???? >????? asking each of them in turn. ???? > ???? >????? How do we get the list of Java processes in the first place? Perhaps we ???? >????? need to do some /proc//cmdline peeking? ???? > ???? >????? Cheers, ???? >????? David ???? > ???? >????? > ???? >????? > Best regards, ???? >????? > Daniil ???? >????? > ???? >????? > ???? >????? > ???? >????? > ?On 11/11/18, 1:35 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: ???? >????? > ???? >????? >????? Hi Daniil, ???? >????? > ???? >????? >????? I took a quick look at this one ... two minor comments ???? >????? > ???? >????? >????? The static class names could just be "Process" as they will acquire the ???? >????? >????? enclosing class name as part of their own name anyway. As it is this ???? >????? >????? gets repeated eg: ???? >????? > ???? >????? >????? HelpTest$HelpTestProcess ???? >????? >????? InvalidCommandTest$InvalidCommandTestProcess ???? >????? > ???? >????? >????? TestJavaProcess.java: ???? >????? > ???? >????? >????? 39???? public static void main(String argv[]) { ???? >????? > ???? >????? >????? Nit: Should be "String[] argv" in Java style ???? >????? > ???? >????? >????? Thanks, ???? >????? >????? David ???? >????? > ???? >????? >????? On 10/11/2018 3:18 PM, Daniil Titov wrote: ???? >????? >????? > Please review the change that fixes serviceability/dcmd/framework/* tests from a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with each other and there are no multiple tests running simultaneously since all they do share the common main class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks like the? tests from other directories still might run in parallel with these tests and they also have com.sun.javatest.regtest.agent.MainWrapper as a main class. ???? >????? >????? > ???? >????? >????? > The fix? ensures that each serviceability/dcmd/framework/* test uses a Java process with a unique main class name when connecting to this process with jcmd and the main class name. ???? >????? >????? > ???? >????? >????? > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 ???? >????? >????? > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/ ???? >????? >????? > ???? >????? >????? > Best regards, ???? >????? >????? > Daniil ???? >????? >????? > ???? >????? >????? > ???? >????? > ???? >????? > ???? >????? > ???? > ???? > ???? > ???? From serguei.spitsyn at oracle.com Mon Feb 4 22:26:19 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 14:26:19 -0800 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: <2599EF95-2EC5-4CE7-8036-33D9863631CB@oracle.com> References: <8550b971-eede-c9ce-6eb9-4ec1671dbce3@oracle.com> <3C6EC1EF-672D-4577-9EEF-2CF73BDED256@oracle.com> <2a75f4de-6a77-615e-1648-0fcca59c6ea2@oracle.com> <0B661A5C-E59D-481C-BC3B-0951621F1F51@oracle.com> <5e9c223c-71c5-980e-03b9-679e69942f23@oracle.com> <0194722E-CFE1-4E3A-A521-14910D88B378@oracle.com> <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> <2599EF95-2EC5-4CE7-8036-33D9863631CB@oracle.com> Message-ID: <56cdb16d-f761-7212-cc27-c0f68e882169@oracle.com> Hi Daniil, Thank you for the update! It looks good in general. I think, it can be a good idea to add a simple tests for this command-line processing. It should save us from any surprises. Thanks, Serguei On 2/4/19 13:24, Daniil Titov wrote: > Hi Serguei, > > Thank you for reviewing this fix. > > Please review a new version of the fix that includes all changes you suggested but one about lines 88-91 and 97-101. > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > 89 i++; > 90 continue; > 91 } > ... > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > 99 i++; > 100 continue; > 101 } > 102 // Skip all other Java options > 103 if (parts[i].startsWith("-")) { > 104 continue; > 105 } > > You are right, these statements are needed to filter out the parts which have nothing to do with the mainClass. But we cannot remove these lines and just return the latest part[i] that was not filtered out as the mainClass since it will not work in the case when the command line includes arguments specified after the main class. In the approach we use the main class is the *first* part[i] (with i > 0) that is not a Java option ( part[i] that doesn't start with '-' and is not classpath, module path, jar file path or module name). This condition that the mainClass is not null is checked on line 89 inside for loop. > > 89 for (int i = 1; i < parts.length && mainClass == null; i++) { > > To simplify the code in the new version of the patch the lines 88-91 and 97-101 are combined in the one "if" block. > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.04 > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > Thanks. > --Daniil > > From: "serguei.spitsyn at oracle.com" > Date: Thursday, January 31, 2019 at 1:23 PM > To: David Holmes , Daniil Titov , serviceability-dev > Subject: Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out > > Hi Daniil, > > > I have some secondary comment on new file: > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java.html > > 70 for (int i = 0; i < parts.length && mainClass == null; i++) { > 71 // Check the executable > 72 if (i == 0) { > 73 String[] executablePath = parts[i].split("/"); > 74 if (executablePath.length > 0) { > 75 String binaryName = executablePath[executablePath.length - 1]; > 76 if (!"java".equals(binaryName)) { > 77 // Skip the process if it is not started with java launcher > 78 return null; > 79 } > 80 } > 81 continue; > 82 } > > ? It is better execute the logic in lines 73-80 before the loop. > ? It will simplify the code a little bit. > String[] executablePath = parts[i].split("/"); > if (executablePath.length > 0) { > String binaryName = executablePath[executablePath.length - 1]; > if (!binaryName.equals("java") { > return null; // Skip the process if it is not started with java launcher > > } > } > for (int i = 1; i < parts.length && mainClass == null; i++) { > > In the fragment below: > > 83 // Check if the module is executed with explicitly specified main class > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > 85 mainClass = getMainClassFromModuleArg(parts[i + 1]); > 86 break; > 87 } > > would it better to just return the main class instead of having a break statement? : > 85 return getMainClassFromModuleArg(parts[i + 1]); > > > The lines: > 108 if (jarFile != null) { > 109 return getMainClassFromJar(jarFile, pid); > 110 } > > is better to execute inside the loop the same as it is done for getMainClassFromModuleArg(). > > // Check if the main class needs to be read from the manifest.mf in a JAR file > if (parts[i].equals("-jar") && i < parts.length - 1) { > return getMainClassFromJar(jarFile, pid); > } > > In the if statements: > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > ... > ?93 if (parts[i].equals("-jar") && i < parts.length - 1) { > > the last condition (i < parts.length - 1) is better to make the first (pre-condition). > They even can be combined together like below: > if (i < parts.length - 1) { > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > return getMainClassFromModuleArg(parts[i + 1]); > } > // Check if the main class needs to be read from the manifest.mf in a JAR file > if (parts[i].equals("-jar") ) { > return getMainClassFromJar(jarFile, pid); > } > } > > ? The biggest concern are the fragments: > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > 89 i++; > 90 continue; > 91 } > ... > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > 99 i++; > 100 continue; > 101 } > 102 // Skip all other Java options > 103 if (parts[i].startsWith("-")) { > 104 continue; > 105 } > ?If I understand it correctly, these statements are needed to filter out > ?the parts which have nothing to do with the mainClass. > ?The latest part[i] that was not filtered out is returned as the mainClass. > > ?I'm thinking about more general approach here. Probably, we just need to remove > ?the fragments 88-91 and 97-101 as they are covered by the fragment 102-105. > ?It will also simplify the code. > > ?With all the suggestion above it should converge to something like this: > String[] parts = cmdLine.split(" "); > ?String mainClass = null; > > String[] executablePath = parts[i].split("/"); > if (executablePath.length > 0) { > String binaryName = executablePath[executablePath.length - 1]; > if (!binaryName.equals("java") { > return null; // Skip the process if it is not started with java launcher > > } > } > for (int 1 = 0; i < parts.length && mainClass == null; i++) { > if (i < parts.length - 1) { > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > return getMainClassFromModuleArg(parts[i + 1]); > } > // Check if the main class needs to be read from the manifest.mf in a JAR file > if (parts[i].equals("-jar") ) { > return getMainClassFromJar(parts[i + 1], pid); > } > } > // Skip all other Java options > if (parts[i].startsWith("-")) { > continue; > } > mainClass = parts[i]; > } > return mainClass; > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java.html > > 49 if (cmd.equals("quit")) { > 50 log("'quit' received"); > 51 > 52 } else { > > The empty line 51 can be removed. > > ?Looking at this command-line processing I kind of understand the David's concern. > > Thanks, > Serguei > > > On 1/20/19 21:18, David Holmes wrote: > Thanks for the update Daniil. I still remain concerned about the robustness of the command-line parsing - this seems like a feature that needs its own set of tests. > > I'll leave it up to Serguei and others as to how to proceed. > > David > ----- > > On 19/01/2019 9:08 am, Daniil Titov wrote: > > Hi David and Serguei, > > Please review a new version of the fix that now covers the case when Java executes a module with the main class name explicitly specified in the command line. > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.03 > Bug: : https://bugs.openjdk.java.net/browse/JDK-8205654 > > Thanks! > --Daniil > > ?On 1/8/19, 6:05 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > ???? Hi Daniil, > ???? ???? Sorry this slipped through the Xmas break cracks :) > ???? ???? On 22/12/2018 12:04 pm, Daniil Titov wrote: > ???? > Hi David and Serguei, > ???? > > ???? > Please review a new version of the fix that for Linux platform uses the proc filesystem to retrieve the main class name for the running Java process. > ???? > > ???? > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.02/ > ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > ???? ???? It's more complex than I had envisaged but seems to be doing the job. > ???? I'm not sure how robust the command-line parsing is, in particular it > ???? doesn't handle these forms: > ???? ???????? or? java [options] -m [/] [args...] > ???????????? java [options] --module [/] [args...] > ???????????????? (to execute the main class in a module) > ???? ???? I can't really comment on all the details. > ???? ???? Thanks, > ???? David > ???? ----- > ???? ???? > Thanks, > ???? > Daniil > ???? > > ???? > ?On 11/29/18, 4:52 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > ???? > > ???? >????? Hi Daniil, > ???? > > ???? >????? On 30/11/2018 7:30 am, Daniil Titov wrote: > ???? >????? > Thank you, David! > ???? >????? > > ???? >????? > The proposed fix didn't help. It still hangs at some occasions.? Additional tracing showed that when jcmd is invoked with the main class name it iterates over all running Java processes and temporary attaches to them to retrieve the main class name. It hangs while trying to attach to one of the running Java processes. There are numerous Java processes running at the host machine some associated with the test framework itself and another with the tests running in parallel. It is not clear what exact is this particular process since the jcmd hangs before retrieving the process' main class name, but after all tests terminated the process with this id is no longer running.? I have to revoke this review since more investigation is required. > ???? > > ???? >????? That sounds like an unsolvable problem for the test. You can't control > ???? >????? other Java processes on the machine, and searching by name requires > ???? >????? asking each of them in turn. > ???? > > ???? >????? How do we get the list of Java processes in the first place? Perhaps we > ???? >????? need to do some /proc//cmdline peeking? > ???? > > ???? >????? Cheers, > ???? >????? David > ???? > > ???? >????? > > ???? >????? > Best regards, > ???? >????? > Daniil > ???? >????? > > ???? >????? > > ???? >????? > > ???? >????? > ?On 11/11/18, 1:35 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > ???? >????? > > ???? >????? >????? Hi Daniil, > ???? >????? > > ???? >????? >????? I took a quick look at this one ... two minor comments > ???? >????? > > ???? >????? >????? The static class names could just be "Process" as they will acquire the > ???? >????? >????? enclosing class name as part of their own name anyway. As it is this > ???? >????? >????? gets repeated eg: > ???? >????? > > ???? >????? >????? HelpTest$HelpTestProcess > ???? >????? >????? InvalidCommandTest$InvalidCommandTestProcess > ???? >????? > > ???? >????? >????? TestJavaProcess.java: > ???? >????? > > ???? >????? >????? 39???? public static void main(String argv[]) { > ???? >????? > > ???? >????? >????? Nit: Should be "String[] argv" in Java style > ???? >????? > > ???? >????? >????? Thanks, > ???? >????? >????? David > ???? >????? > > ???? >????? >????? On 10/11/2018 3:18 PM, Daniil Titov wrote: > ???? >????? >????? > Please review the change that fixes serviceability/dcmd/framework/* tests from a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with each other and there are no multiple tests running simultaneously since all they do share the common main class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks like the? tests from other directories still might run in parallel with these tests and they also have com.sun.javatest.regtest.agent.MainWrapper as a main class. > ???? >????? >????? > > ???? >????? >????? > The fix? ensures that each serviceability/dcmd/framework/* test uses a Java process with a unique main class name when connecting to this process with jcmd and the main class name. > ???? >????? >????? > > ???? >????? >????? > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > ???? >????? >????? > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/ > ???? >????? >????? > > ???? >????? >????? > Best regards, > ???? >????? >????? > Daniil > ???? >????? >????? > > ???? >????? >????? > > ???? >????? > > ???? >????? > > ???? >????? > > ???? > > ???? > > ???? > > > > > > From serguei.spitsyn at oracle.com Mon Feb 4 22:30:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 14:30:14 -0800 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> Message-ID: <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Feb 4 23:05:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 09:05:12 +1000 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> Message-ID: <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> On 5/02/2019 8:30 am, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Looks good in general. > > Just a couple minor comments below. > > I hope, you will update the copyright years before the push. > > > http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html > > ? Nice test! > > 37 import java.lang.reflect.*; > 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; > 39 import java.lang.instrument.*; > > ? The imports above can be re-ordered. > > 44 return new String("public class B" + count + " {" + > 45 " public static void compiledMethod() { " + > 46 " try{" + > 47 " Thread.currentThread().sleep(1); " + > 48 " } catch(InterruptedException ie) {" + > 49 " }" + > 50 " }" + > 51 "}"); > > ? Not clear, why sleep is needed here. Presumably just to give it some code and consume some time. Nit: But it should just be: Thread.sleep(1) not Thread.currentThread().sleep(1); sleep is a static method and as with all Thread static methods always applies to the current thread. David > > Thanks, > Serguei > > > On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >> Added the serviceability-dev back. >> >> Thanks, >> Serguei >> >> >> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>> >>> The links. >>> Thanks, >>> Coleen >>> >>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>> >>>> *This change touches the AOT and code cache code.? I tried to >>>> describe it in the comments in the RFE.? Basically, for >>>> redefinition, we walk the code cache per class redefined in order to >>>> find evol_method dependencies, then deoptimize if we find them, and >>>> then walk the code cache again to mark the deoptimized nmethods as >>>> not_entrant. >>>> >>>> I replaced this with only marking any nmethods for the class's >>>> methods to deoptimize (following InstanceKlass::_methods), also >>>> marking aot methods dependent on the class, and then doing the code >>>> cache walk to follow the evol_method dependencies at the end of >>>> redefinition for all the classes. The new code uses the >>>> Method::is_old() flag rather than comparing each method in the >>>> InstanceKlass.? Then deoptimization and marking not_entrant is done >>>> once at the end of the redefinition as well. >>>> >>>> Tested with tier1-6, all the redefinition tests locally: >>>> >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>> >&redefine.out >>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>> >>>> new test, and JMH test (see CR for results). >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Tue Feb 5 00:00:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 16:00:21 -0800 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> Message-ID: On 2/4/19 15:05, David Holmes wrote: > On 5/02/2019 8:30 am, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Looks good in general. >> >> Just a couple minor comments below. >> >> I hope, you will update the copyright years before the push. >> >> >> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html >> >> >> ?? Nice test! >> >> ?? 37 import java.lang.reflect.*; >> ?? 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; >> ?? 39 import java.lang.instrument.*; >> >> ?? The imports above can be re-ordered. >> >> ?? 44???????? return new String("public class B" + count + " {" + >> ?? 45???????????????? "?? public static void compiledMethod() { " + >> ?? 46???????????????? "?????? try{" + >> ?? 47???????????????? " Thread.currentThread().sleep(1); " + >> ?? 48???????????????? "?????? } catch(InterruptedException ie) {" + >> ?? 49???????????????? "?????? }" + >> ?? 50???????????????? "?? }" + >> ?? 51???????????????? "}"); >> >> ?? Not clear, why sleep is needed here. > > Presumably just to give it some code and consume some time. Some print statement would be more simple and useful. But it is really minor. :) Thanks, Serguei > Nit: But it should just be: > > Thread.sleep(1) > > not > > Thread.currentThread().sleep(1); > > sleep is a static method and as with all Thread static methods always > applies to the current thread. > > David > >> >> Thanks, >> Serguei >> >> >> On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >>> Added the serviceability-dev back. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>>> >>>> The links. >>>> Thanks, >>>> Coleen >>>> >>>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>>> >>>>> *This change touches the AOT and code cache code.? I tried to >>>>> describe it in the comments in the RFE.? Basically, for >>>>> redefinition, we walk the code cache per class redefined in order >>>>> to find evol_method dependencies, then deoptimize if we find them, >>>>> and then walk the code cache again to mark the deoptimized >>>>> nmethods as not_entrant. >>>>> >>>>> I replaced this with only marking any nmethods for the class's >>>>> methods to deoptimize (following InstanceKlass::_methods), also >>>>> marking aot methods dependent on the class, and then doing the >>>>> code cache walk to follow the evol_method dependencies at the end >>>>> of redefinition for all the classes. The new code uses the >>>>> Method::is_old() flag rather than comparing each method in the >>>>> InstanceKlass.? Then deoptimization and marking not_entrant is >>>>> done once at the end of the redefinition as well. >>>>> >>>>> Tested with tier1-6, all the redefinition tests locally: >>>>> >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>>> >&jvmti.out >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>>> >&redefine.out >>>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>>> >>>>> new test, and JMH test (see CR for results). >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> From david.holmes at oracle.com Tue Feb 5 01:04:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 11:04:25 +1000 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <5C5845B2.40004@oracle.com> References: <5C5845B2.40004@oracle.com> Message-ID: <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> Hi Gary, On 5/02/2019 12:01 am, Gary Adams wrote: > Two of the redefine classes tests (021, 023) have been on the > ProblemList since they > were first brought into the open repos. Both tests made an incorrect > assumption > about the access modifiers in class files. There is a single bit in the > binary class file that > defines if an interface is public or not public (See JVMS Table 4.1-B > ACC_PUBLIC). > When the test classes are compiled for use in the redefine operation, if > a source > used public or protected the ACC_PUBLIC bit was set. > > Several modifiers are used in these tests to confirm > UnsupportedOperationException > is thrown or not thrown. This proposed change simply corrects the > expected results > according to the JVM Specification. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java 62 * Test cases 3 (private) and 4 (static) map to not public, so will "static" is not related to access modifiers so the ACC_PUBLIC bit is not relevant. "static" can only be applied to (nested) member types and is represented by the ACC_STATIC bit as per JVMS "Table 4.7.6-A. Nested class access and property flags". What this testcase does is add "static" to a nested interface and expects JVM TI to check if the class modifier has changed. But the "static" is not encoded in the class "access flags", but in the inner class attribute (inner_class_access_flags). To me this testcase should throw UOE, but JVM TI is not checking the right flags. David From david.holmes at oracle.com Tue Feb 5 01:10:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 11:10:00 +1000 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: <7c13fc0e-060e-65f2-e5f4-68641e1f7c67@oracle.com> References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> <2744c4d7-a75b-a916-9b6a-e746cc6c3e50@oracle.com> <7c13fc0e-060e-65f2-e5f4-68641e1f7c67@oracle.com> Message-ID: <4e12480a-9d6d-a993-5596-9b02c7296e61@oracle.com> Hi Jini, This looks fine to me - Reviewed. Thanks, David On 4/02/2019 11:39 pm, Jini George wrote: > Pinging again -- requesting for a Reviewer to take a look. > > The patch has been rebased again to include the changes of JDK-8217473 > to rethrow SkippedException for the tests refactored to use ClhsdbLauncher. > > webrev: > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.04/index.html > > Thanks, > Jini. > > On 1/16/2019 9:59 AM, Jini George wrote: >> Ping! >> >> Need a Reviewer please. >> >> The patch rebased to the latest changes is at: >> >> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.03/index.html >> >> Thanks, >> Jini. >> >> On 1/10/2019 8:40 PM, Jini George wrote: >>> Gentle reminder -- Could I please let a Reviewer to take a look at this? >>> >>> Thanks, >>> Jini. >>> >>> On 1/8/2019 10:36 PM, Jini George wrote: >>>> Thank you so much for the great catch, JC! Yes, indeed, the test >>>> passed inspite of 'printmado' being an unrecognized command. I have >>>> filed https://bugs.openjdk.java.net/browse/JDK-8216352 to handle >>>> issues like these. >>>> >>>> I have the corrected webrev at: >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.02/index.html >>>> >>>> Could I get a Reviewer also to take a look at this ? >>>> >>>> Thank you, >>>> Jini. >>>> >>>> On 1/8/2019 12:12 AM, JC Beyler wrote: >>>>> Hi Jini, >>>>> >>>>> I saw this typo: >>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>>> >>>>> >>>>> +? ? ? ? ? ? List cmds = List.of("printmado -a"); >>>>> >>>>> Should it not be printmdo and not printmado? does printmado exist? >>>>> If it doesn't how does the test pass (my guess is that we do not >>>>> catch a "unexpected command" and that the hashmaps are not finding >>>>> the keys so they are not checking the expected/unexpected results; >>>>> if so perhaps a follow-up should fix that an unknown command fails >>>>> a test trying to do that / and perhaps if the key is not found, the >>>>> test fails as well?) >>>>> >>>>> Thanks! >>>>> Jc >>>>> >>>>> On Tue, Jan 1, 2019 at 9:07 PM Jini George >>>> > wrote: >>>>> >>>>> ??? Thank you very much for the review, JC. My comments inline. >>>>> >>>>> >>>>> ???? > I saw this potential issue with one of the test conversions: >>>>> ???? > >>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>>> >>>>> ???? >? ? ?- It seems like there is a missing "unexpected" strings >>>>> check >>>>> ??? here no? >>>>> ???? >? ? ? ? - The original test was doing >>>>> ???? > - >>>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("missing reason for ")) { >>>>> ???? > -? ? ? ? ? ? ? ? ? ? unexpected = new >>>>> ??? RuntimeException("Unexpected msg: >>>>> ???? > missing reason for "); >>>>> ???? > -? ? ? ? ? ? ? ? ? ? break; >>>>> ???? > -? ? ? ? ? ? ? ? } >>>>> ???? > >>>>> ???? > whereas the new test is not seemingly (though >>>>> ???? > >>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java.udiff.html >>>>> >>>>> >>>>> ???? > does do it so I think this is an oversight?). >>>>> >>>>> ??? Thank you very much for pointing this out! This was an >>>>> oversight. I >>>>> ??? have >>>>> ??? added the unexpected strings check. >>>>> >>>>> ???? > >>>>> ???? >? ? ?- Also interesting is that the original test was trying to >>>>> ??? find one >>>>> ???? > of X: >>>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("VirtualCallData")? || >>>>> ???? > -? ? ? ? ? ? ? ? ? ? line.contains("CounterData")? ? ? || >>>>> ???? > -? ? ? ? ? ? ? ? ? ? line.contains("ReceiverTypeData")) { >>>>> ???? > -? ? ? ? ? ? ? ? ? ? knownProfileDataTypeFound = true; >>>>> ???? > -? ? ? ? ? ? ? ? } >>>>> ???? > >>>>> ???? > whereas you are now wanting to find all of them. Is that >>>>> ??? normal/wanted? >>>>> >>>>> ??? I was being extra cautious when I had written this test case in >>>>> the >>>>> ??? beginning :-). As far as I have seen, the printmdo output does >>>>> contain >>>>> ??? all of these. (The test passes with 50 repeated runs across all hs >>>>> ??? tiers >>>>> ??? with the changes -- so I believe it is OK). >>>>> >>>>> ??? I have the new webrev at: >>>>> >>>>> ??? http://cr.openjdk.java.net/~jgeorge/8215568/webrev.01/ >>>>> >>>>> ??? I have additionally modified the copyright year to 2019. >>>>> >>>>> ??? Thank you, >>>>> ??? Jini. >>>>> >>>>> >>>>> ???? > >>>>> ???? > The rest looked good to me, though I wish there were a way >>>>> to not >>>>> ??? have >>>>> ???? > to change all the strings to be regex friendly but I fail to >>>>> see >>>>> ??? how to >>>>> ???? > do that without writing a runCmdWithoutRegexMatcher, which >>>>> seems >>>>> ???? > overkill :-) >>>>> ???? > Jc >>>>> ???? > >>>>> ???? > On Tue, Dec 18, 2018 at 8:55 PM Jini George >>>>> ??? >>>>> ???? > >>>> >> >>>>> ??? wrote: >>>>> ???? > >>>>> ???? >? ? ?Hello! >>>>> ???? > >>>>> ???? >? ? ?Requesting reviews for: >>>>> ???? > >>>>> ???? > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/ >>>>> ???? > >>>>> ???? >? ? ?BugID: https://bugs.openjdk.java.net/browse/JDK-8215568 >>>>> ???? > >>>>> ???? >? ? ?No new failures with the SA tests (hs-tiers 1-5) with these >>>>> ??? changes. >>>>> ???? >? ? ?The >>>>> ???? >? ? ?changes here include: >>>>> ???? > >>>>> ???? >? ? ?* Refactoring the SA tests which test clhsdb commands to >>>>> use >>>>> ???? >? ? ?ClhsdbLauncher for uniformity and ease of maintainence. >>>>> ???? >? ? ?* Testing for regular expressions with shouldMatch >>>>> rather than >>>>> ???? >? ? ?shouldContain. >>>>> ???? >? ? ?* Minor cleanups. >>>>> ???? > >>>>> ???? >? ? ?Thank you, >>>>> ???? >? ? ?Jini. >>>>> ???? > >>>>> ???? > >>>>> ???? > >>>>> ???? > >>>>> ???? > -- >>>>> ???? > >>>>> ???? > Thanks, >>>>> ???? > Jc >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc From david.holmes at oracle.com Tue Feb 5 01:13:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 11:13:12 +1000 Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: References: <1b6d4030-4980-7fd0-7784-72987239647a@oracle.com> Message-ID: <71c59a20-7669-e05c-e203-ee4eac527938@oracle.com> Hi Jc, On 5/02/2019 3:47 am, Jean Christophe Beyler wrote: > Hi Jini, > > The webrev looks good to me but I was wondering why you are changing the > tests really. For example: > http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/test/hotspot/jtreg/serviceability/sa/ClhsdbAttach.java.html > > The main method already is declared to be throwing the top class > Exception. It seems to me that you could then skip updating the tests: > > +? ? ? ? } catch (SkippedException se) { > +? ? ? ? ? ? throw se; > > no? > > Probably I'm missing something but seemed like you didn't need to add > this if you were just rethrowing it. It has to be caught to be rethrown, otherwise it is caught by the following clause (which catches all Exception types) and a RuntimeException thrown instead. David ----- > On Wed, Jan 30, 2019 at 8:39 PM Jini George > wrote: > > Thank you, David! > > - Jini. > > On 1/31/2019 7:45 AM, David Holmes wrote: > > Hi Jini, > > > > This looks reasonable to me. > > > > Thanks, > > David > > > > On 30/01/2019 9:59 pm, Jini George wrote: > >> Requesting reviews for: > >> > >> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 > >> > Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html > >> > >> The patch includes changes to use SkippedException to skip the > tests > >> when canPtraceAttachLinux() in Platform.java returns false. > >> > >> Thanks, > >> Jini. > >> > > > > -- > > Thanks, > Jc From serguei.spitsyn at oracle.com Tue Feb 5 02:15:12 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 18:15:12 -0800 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: <7c13fc0e-060e-65f2-e5f4-68641e1f7c67@oracle.com> References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> <2744c4d7-a75b-a916-9b6a-e746cc6c3e50@oracle.com> <7c13fc0e-060e-65f2-e5f4-68641e1f7c67@oracle.com> Message-ID: <0b0c3416-5e3c-87a5-e990-38346e19d9f6@oracle.com> Hi Jini, It looks good to me. Thanks, Serguei On 2/4/19 05:39, Jini George wrote: > Pinging again -- requesting for a Reviewer to take a look. > > The patch has been rebased again to include the changes of JDK-8217473 > to rethrow SkippedException for the tests refactored to use > ClhsdbLauncher. > > webrev: > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.04/index.html > > Thanks, > Jini. > > On 1/16/2019 9:59 AM, Jini George wrote: >> Ping! >> >> Need a Reviewer please. >> >> The patch rebased to the latest changes is at: >> >> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.03/index.html >> >> Thanks, >> Jini. >> >> On 1/10/2019 8:40 PM, Jini George wrote: >>> Gentle reminder -- Could I please let a Reviewer to take a look at >>> this? >>> >>> Thanks, >>> Jini. >>> >>> On 1/8/2019 10:36 PM, Jini George wrote: >>>> Thank you so much for the great catch, JC! Yes, indeed, the test >>>> passed inspite of 'printmado' being an unrecognized command. I have >>>> filed https://bugs.openjdk.java.net/browse/JDK-8216352 to handle >>>> issues like these. >>>> >>>> I have the corrected webrev at: >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.02/index.html >>>> >>>> Could I get a Reviewer also to take a look at this ? >>>> >>>> Thank you, >>>> Jini. >>>> >>>> On 1/8/2019 12:12 AM, JC Beyler wrote: >>>>> Hi Jini, >>>>> >>>>> I saw this typo: >>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>>> >>>>> >>>>> +? ? ? ? ? ? List cmds = List.of("printmado -a"); >>>>> >>>>> Should it not be printmdo and not printmado? does printmado exist? >>>>> If it doesn't how does the test pass (my guess is that we do not >>>>> catch a "unexpected command" and that the hashmaps are not finding >>>>> the keys so they are not checking the expected/unexpected results; >>>>> if so perhaps a follow-up should fix that an unknown command fails >>>>> a test trying to do that / and perhaps if the key is not found, >>>>> the test fails as well?) >>>>> >>>>> Thanks! >>>>> Jc >>>>> >>>>> On Tue, Jan 1, 2019 at 9:07 PM Jini George >>>> > wrote: >>>>> >>>>> ??? Thank you very much for the review, JC. My comments inline. >>>>> >>>>> >>>>> ???? > I saw this potential issue with one of the test conversions: >>>>> ???? > >>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>>> >>>>> ???? >? ? ?- It seems like there is a missing "unexpected" strings >>>>> check >>>>> ??? here no? >>>>> ???? >? ? ? ? - The original test was doing >>>>> ???? > - >>>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("missing reason for ")) { >>>>> ???? > -? ? ? ? ? ? ? ? ? ? unexpected = new >>>>> ??? RuntimeException("Unexpected msg: >>>>> ???? > missing reason for "); >>>>> ???? > -? ? ? ? ? ? ? ? ? ? break; >>>>> ???? > -? ? ? ? ? ? ? ? } >>>>> ???? > >>>>> ???? > whereas the new test is not seemingly (though >>>>> ???? > >>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java.udiff.html >>>>> >>>>> >>>>> ???? > does do it so I think this is an oversight?). >>>>> >>>>> ??? Thank you very much for pointing this out! This was an >>>>> oversight. I >>>>> ??? have >>>>> ??? added the unexpected strings check. >>>>> >>>>> ???? > >>>>> ???? >? ? ?- Also interesting is that the original test was trying to >>>>> ??? find one >>>>> ???? > of X: >>>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("VirtualCallData")? || >>>>> ???? > - line.contains("CounterData")? ? ? || >>>>> ???? > - line.contains("ReceiverTypeData")) { >>>>> ???? > -? ? ? ? ? ? ? ? ? ? knownProfileDataTypeFound = true; >>>>> ???? > -? ? ? ? ? ? ? ? } >>>>> ???? > >>>>> ???? > whereas you are now wanting to find all of them. Is that >>>>> ??? normal/wanted? >>>>> >>>>> ??? I was being extra cautious when I had written this test case >>>>> in the >>>>> ??? beginning :-). As far as I have seen, the printmdo output does >>>>> contain >>>>> ??? all of these. (The test passes with 50 repeated runs across >>>>> all hs >>>>> ??? tiers >>>>> ??? with the changes -- so I believe it is OK). >>>>> >>>>> ??? I have the new webrev at: >>>>> >>>>> ??? http://cr.openjdk.java.net/~jgeorge/8215568/webrev.01/ >>>>> >>>>> ??? I have additionally modified the copyright year to 2019. >>>>> >>>>> ??? Thank you, >>>>> ??? Jini. >>>>> >>>>> >>>>> ???? > >>>>> ???? > The rest looked good to me, though I wish there were a way >>>>> to not >>>>> ??? have >>>>> ???? > to change all the strings to be regex friendly but I fail >>>>> to see >>>>> ??? how to >>>>> ???? > do that without writing a runCmdWithoutRegexMatcher, which >>>>> seems >>>>> ???? > overkill :-) >>>>> ???? > Jc >>>>> ???? > >>>>> ???? > On Tue, Dec 18, 2018 at 8:55 PM Jini George >>>>> ??? >>>>> ???? > >>>> >> >>>>> ??? wrote: >>>>> ???? > >>>>> ???? >? ? ?Hello! >>>>> ???? > >>>>> ???? >? ? ?Requesting reviews for: >>>>> ???? > >>>>> ???? > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/ >>>>> ???? > >>>>> ???? >? ? ?BugID: https://bugs.openjdk.java.net/browse/JDK-8215568 >>>>> ???? > >>>>> ???? >? ? ?No new failures with the SA tests (hs-tiers 1-5) with >>>>> these >>>>> ??? changes. >>>>> ???? >? ? ?The >>>>> ???? >? ? ?changes here include: >>>>> ???? > >>>>> ???? >? ? ?* Refactoring the SA tests which test clhsdb commands >>>>> to use >>>>> ???? >? ? ?ClhsdbLauncher for uniformity and ease of maintainence. >>>>> ???? >? ? ?* Testing for regular expressions with shouldMatch >>>>> rather than >>>>> ???? >? ? ?shouldContain. >>>>> ???? >? ? ?* Minor cleanups. >>>>> ???? > >>>>> ???? >? ? ?Thank you, >>>>> ???? >? ? ?Jini. >>>>> ???? > >>>>> ???? > >>>>> ???? > >>>>> ???? > >>>>> ???? > -- >>>>> ???? > >>>>> ???? > Thanks, >>>>> ???? > Jc >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc From jini.george at oracle.com Tue Feb 5 02:27:37 2019 From: jini.george at oracle.com (Jini George) Date: Tue, 5 Feb 2019 07:57:37 +0530 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: <0b0c3416-5e3c-87a5-e990-38346e19d9f6@oracle.com> References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> <2744c4d7-a75b-a916-9b6a-e746cc6c3e50@oracle.com> <7c13fc0e-060e-65f2-e5f4-68641e1f7c67@oracle.com> <0b0c3416-5e3c-87a5-e990-38346e19d9f6@oracle.com> Message-ID: <60cf4cd2-649e-d2ce-4ea4-67b72af941ad@oracle.com> Thank you very much, Serguei. - Jini. On 2/5/2019 7:45 AM, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > It looks good to me. > > Thanks, > Serguei > > > On 2/4/19 05:39, Jini George wrote: >> Pinging again -- requesting for a Reviewer to take a look. >> >> The patch has been rebased again to include the changes of JDK-8217473 >> to rethrow SkippedException for the tests refactored to use >> ClhsdbLauncher. >> >> webrev: >> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.04/index.html >> >> Thanks, >> Jini. >> >> On 1/16/2019 9:59 AM, Jini George wrote: >>> Ping! >>> >>> Need a Reviewer please. >>> >>> The patch rebased to the latest changes is at: >>> >>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.03/index.html >>> >>> Thanks, >>> Jini. >>> >>> On 1/10/2019 8:40 PM, Jini George wrote: >>>> Gentle reminder -- Could I please let a Reviewer to take a look at >>>> this? >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 1/8/2019 10:36 PM, Jini George wrote: >>>>> Thank you so much for the great catch, JC! Yes, indeed, the test >>>>> passed inspite of 'printmado' being an unrecognized command. I have >>>>> filed https://bugs.openjdk.java.net/browse/JDK-8216352 to handle >>>>> issues like these. >>>>> >>>>> I have the corrected webrev at: >>>>> >>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.02/index.html >>>>> >>>>> Could I get a Reviewer also to take a look at this ? >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>>>> On 1/8/2019 12:12 AM, JC Beyler wrote: >>>>>> Hi Jini, >>>>>> >>>>>> I saw this typo: >>>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>>>> >>>>>> >>>>>> +? ? ? ? ? ? List cmds = List.of("printmado -a"); >>>>>> >>>>>> Should it not be printmdo and not printmado? does printmado exist? >>>>>> If it doesn't how does the test pass (my guess is that we do not >>>>>> catch a "unexpected command" and that the hashmaps are not finding >>>>>> the keys so they are not checking the expected/unexpected results; >>>>>> if so perhaps a follow-up should fix that an unknown command fails >>>>>> a test trying to do that / and perhaps if the key is not found, >>>>>> the test fails as well?) >>>>>> >>>>>> Thanks! >>>>>> Jc >>>>>> >>>>>> On Tue, Jan 1, 2019 at 9:07 PM Jini George >>>>> > wrote: >>>>>> >>>>>> ??? Thank you very much for the review, JC. My comments inline. >>>>>> >>>>>> >>>>>> ???? > I saw this potential issue with one of the test conversions: >>>>>> ???? > >>>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>>>> >>>>>> ???? >? ? ?- It seems like there is a missing "unexpected" strings >>>>>> check >>>>>> ??? here no? >>>>>> ???? >? ? ? ? - The original test was doing >>>>>> ???? > - >>>>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("missing reason for ")) { >>>>>> ???? > -? ? ? ? ? ? ? ? ? ? unexpected = new >>>>>> ??? RuntimeException("Unexpected msg: >>>>>> ???? > missing reason for "); >>>>>> ???? > -? ? ? ? ? ? ? ? ? ? break; >>>>>> ???? > -? ? ? ? ? ? ? ? } >>>>>> ???? > >>>>>> ???? > whereas the new test is not seemingly (though >>>>>> ???? > >>>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java.udiff.html >>>>>> >>>>>> >>>>>> ???? > does do it so I think this is an oversight?). >>>>>> >>>>>> ??? Thank you very much for pointing this out! This was an >>>>>> oversight. I >>>>>> ??? have >>>>>> ??? added the unexpected strings check. >>>>>> >>>>>> ???? > >>>>>> ???? >? ? ?- Also interesting is that the original test was trying to >>>>>> ??? find one >>>>>> ???? > of X: >>>>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("VirtualCallData")? || >>>>>> ???? > - line.contains("CounterData")? ? ? || >>>>>> ???? > - line.contains("ReceiverTypeData")) { >>>>>> ???? > -? ? ? ? ? ? ? ? ? ? knownProfileDataTypeFound = true; >>>>>> ???? > -? ? ? ? ? ? ? ? } >>>>>> ???? > >>>>>> ???? > whereas you are now wanting to find all of them. Is that >>>>>> ??? normal/wanted? >>>>>> >>>>>> ??? I was being extra cautious when I had written this test case >>>>>> in the >>>>>> ??? beginning :-). As far as I have seen, the printmdo output does >>>>>> contain >>>>>> ??? all of these. (The test passes with 50 repeated runs across >>>>>> all hs >>>>>> ??? tiers >>>>>> ??? with the changes -- so I believe it is OK). >>>>>> >>>>>> ??? I have the new webrev at: >>>>>> >>>>>> ??? http://cr.openjdk.java.net/~jgeorge/8215568/webrev.01/ >>>>>> >>>>>> ??? I have additionally modified the copyright year to 2019. >>>>>> >>>>>> ??? Thank you, >>>>>> ??? Jini. >>>>>> >>>>>> >>>>>> ???? > >>>>>> ???? > The rest looked good to me, though I wish there were a way >>>>>> to not >>>>>> ??? have >>>>>> ???? > to change all the strings to be regex friendly but I fail >>>>>> to see >>>>>> ??? how to >>>>>> ???? > do that without writing a runCmdWithoutRegexMatcher, which >>>>>> seems >>>>>> ???? > overkill :-) >>>>>> ???? > Jc >>>>>> ???? > >>>>>> ???? > On Tue, Dec 18, 2018 at 8:55 PM Jini George >>>>>> ??? >>>>>> ???? > >>>>> >> >>>>>> ??? wrote: >>>>>> ???? > >>>>>> ???? >? ? ?Hello! >>>>>> ???? > >>>>>> ???? >? ? ?Requesting reviews for: >>>>>> ???? > >>>>>> ???? > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/ >>>>>> ???? > >>>>>> ???? >? ? ?BugID: https://bugs.openjdk.java.net/browse/JDK-8215568 >>>>>> ???? > >>>>>> ???? >? ? ?No new failures with the SA tests (hs-tiers 1-5) with >>>>>> these >>>>>> ??? changes. >>>>>> ???? >? ? ?The >>>>>> ???? >? ? ?changes here include: >>>>>> ???? > >>>>>> ???? >? ? ?* Refactoring the SA tests which test clhsdb commands >>>>>> to use >>>>>> ???? >? ? ?ClhsdbLauncher for uniformity and ease of maintainence. >>>>>> ???? >? ? ?* Testing for regular expressions with shouldMatch >>>>>> rather than >>>>>> ???? >? ? ?shouldContain. >>>>>> ???? >? ? ?* Minor cleanups. >>>>>> ???? > >>>>>> ???? >? ? ?Thank you, >>>>>> ???? >? ? ?Jini. >>>>>> ???? > >>>>>> ???? > >>>>>> ???? > >>>>>> ???? > >>>>>> ???? > -- >>>>>> ???? > >>>>>> ???? > Thanks, >>>>>> ???? > Jc >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc > From coleen.phillimore at oracle.com Tue Feb 5 02:26:44 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 21:26:44 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> Message-ID: <33a1dbcb-d7c3-5d1a-1e65-8c9b85c9ca02@oracle.com> On 2/4/19 5:30 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > Looks good in general. > > Just a couple minor comments below. > > I hope, you will update the copyright years before the push. Hi Serguei,? Thanks for reviewing this. Yes, I update the copyright years in my commit script. > > > http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html > > ? Nice test! > 37 import java.lang.reflect.*; > 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; > 39 import java.lang.instrument.*; > ? The imports above can be re-ordered. Alphabetically? > > 44 return new String("public class B" + count + " {" + > 45 " public static void compiledMethod() { " + > 46 " try{" + > 47 " Thread.currentThread().sleep(1); " + > 48 " } catch(InterruptedException ie) {" + > 49 " }" + > 50 " }" + > 51 "}"); > ? Not clear, why sleep is needed here. > Yes, the sleep was there so that the compiler didn't optimize away the function.? I didn't put a print because it would print too many times. Thanks, Coleen > > Thanks, > Serguei > > > On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >> Added the serviceability-dev back. >> >> Thanks, >> Serguei >> >> >> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>> >>> open webrev at >>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>> >>> The links. >>> Thanks, >>> Coleen >>> >>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>> >>>> *This change touches the AOT and code cache code.? I tried to >>>> describe it in the comments in the RFE.? Basically, for >>>> redefinition, we walk the code cache per class redefined in order >>>> to find evol_method dependencies, then deoptimize if we find them, >>>> and then walk the code cache again to mark the deoptimized nmethods >>>> as not_entrant. >>>> >>>> I replaced this with only marking any nmethods for the class's >>>> methods to deoptimize (following InstanceKlass::_methods), also >>>> marking aot methods dependent on the class, and then doing the code >>>> cache walk to follow the evol_method dependencies at the end of >>>> redefinition for all the classes.?? The new code uses the >>>> Method::is_old() flag rather than comparing each method in the >>>> InstanceKlass.? Then deoptimization and marking not_entrant is done >>>> once at the end of the redefinition as well. >>>> >>>> Tested with tier1-6, all the redefinition tests locally: >>>> >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>> >&jvmti.out >>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>> >&redefine.out >>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>> >>>> new test, and JMH test (see CR for results). >>>> >>>> Thanks, >>>> Coleen >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Tue Feb 5 02:27:00 2019 From: jini.george at oracle.com (Jini George) Date: Tue, 5 Feb 2019 07:57:00 +0530 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: <4e12480a-9d6d-a993-5596-9b02c7296e61@oracle.com> References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> <2744c4d7-a75b-a916-9b6a-e746cc6c3e50@oracle.com> <7c13fc0e-060e-65f2-e5f4-68641e1f7c67@oracle.com> <4e12480a-9d6d-a993-5596-9b02c7296e61@oracle.com> Message-ID: Thank you very much, David. - Jini. On 2/5/2019 6:40 AM, David Holmes wrote: > Hi Jini, > > This looks fine to me - Reviewed. > > Thanks, > David > > On 4/02/2019 11:39 pm, Jini George wrote: >> Pinging again -- requesting for a Reviewer to take a look. >> >> The patch has been rebased again to include the changes of JDK-8217473 >> to rethrow SkippedException for the tests refactored to use >> ClhsdbLauncher. >> >> webrev: >> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.04/index.html >> >> Thanks, >> Jini. >> >> On 1/16/2019 9:59 AM, Jini George wrote: >>> Ping! >>> >>> Need a Reviewer please. >>> >>> The patch rebased to the latest changes is at: >>> >>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.03/index.html >>> >>> Thanks, >>> Jini. >>> >>> On 1/10/2019 8:40 PM, Jini George wrote: >>>> Gentle reminder -- Could I please let a Reviewer to take a look at >>>> this? >>>> >>>> Thanks, >>>> Jini. >>>> >>>> On 1/8/2019 10:36 PM, Jini George wrote: >>>>> Thank you so much for the great catch, JC! Yes, indeed, the test >>>>> passed inspite of 'printmado' being an unrecognized command. I have >>>>> filed https://bugs.openjdk.java.net/browse/JDK-8216352 to handle >>>>> issues like these. >>>>> >>>>> I have the corrected webrev at: >>>>> >>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.02/index.html >>>>> >>>>> Could I get a Reviewer also to take a look at this ? >>>>> >>>>> Thank you, >>>>> Jini. >>>>> >>>>> On 1/8/2019 12:12 AM, JC Beyler wrote: >>>>>> Hi Jini, >>>>>> >>>>>> I saw this typo: >>>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>>>> >>>>>> >>>>>> +? ? ? ? ? ? List cmds = List.of("printmado -a"); >>>>>> >>>>>> Should it not be printmdo and not printmado? does printmado exist? >>>>>> If it doesn't how does the test pass (my guess is that we do not >>>>>> catch a "unexpected command" and that the hashmaps are not finding >>>>>> the keys so they are not checking the expected/unexpected results; >>>>>> if so perhaps a follow-up should fix that an unknown command fails >>>>>> a test trying to do that / and perhaps if the key is not found, >>>>>> the test fails as well?) >>>>>> >>>>>> Thanks! >>>>>> Jc >>>>>> >>>>>> On Tue, Jan 1, 2019 at 9:07 PM Jini George >>>>> > wrote: >>>>>> >>>>>> ??? Thank you very much for the review, JC. My comments inline. >>>>>> >>>>>> >>>>>> ???? > I saw this potential issue with one of the test conversions: >>>>>> ???? > >>>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html >>>>>> >>>>>> ???? >? ? ?- It seems like there is a missing "unexpected" strings >>>>>> check >>>>>> ??? here no? >>>>>> ???? >? ? ? ? - The original test was doing >>>>>> ???? > - >>>>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("missing reason for ")) { >>>>>> ???? > -? ? ? ? ? ? ? ? ? ? unexpected = new >>>>>> ??? RuntimeException("Unexpected msg: >>>>>> ???? > missing reason for "); >>>>>> ???? > -? ? ? ? ? ? ? ? ? ? break; >>>>>> ???? > -? ? ? ? ? ? ? ? } >>>>>> ???? > >>>>>> ???? > whereas the new test is not seemingly (though >>>>>> ???? > >>>>>> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java.udiff.html >>>>>> >>>>>> >>>>>> ???? > does do it so I think this is an oversight?). >>>>>> >>>>>> ??? Thank you very much for pointing this out! This was an >>>>>> oversight. I >>>>>> ??? have >>>>>> ??? added the unexpected strings check. >>>>>> >>>>>> ???? > >>>>>> ???? >? ? ?- Also interesting is that the original test was trying to >>>>>> ??? find one >>>>>> ???? > of X: >>>>>> ???? > -? ? ? ? ? ? ? ? if (line.contains("VirtualCallData")? || >>>>>> ???? > -? ? ? ? ? ? ? ? ? ? line.contains("CounterData")? ? ? || >>>>>> ???? > -? ? ? ? ? ? ? ? ? ? line.contains("ReceiverTypeData")) { >>>>>> ???? > -? ? ? ? ? ? ? ? ? ? knownProfileDataTypeFound = true; >>>>>> ???? > -? ? ? ? ? ? ? ? } >>>>>> ???? > >>>>>> ???? > whereas you are now wanting to find all of them. Is that >>>>>> ??? normal/wanted? >>>>>> >>>>>> ??? I was being extra cautious when I had written this test case >>>>>> in the >>>>>> ??? beginning :-). As far as I have seen, the printmdo output does >>>>>> contain >>>>>> ??? all of these. (The test passes with 50 repeated runs across >>>>>> all hs >>>>>> ??? tiers >>>>>> ??? with the changes -- so I believe it is OK). >>>>>> >>>>>> ??? I have the new webrev at: >>>>>> >>>>>> ??? http://cr.openjdk.java.net/~jgeorge/8215568/webrev.01/ >>>>>> >>>>>> ??? I have additionally modified the copyright year to 2019. >>>>>> >>>>>> ??? Thank you, >>>>>> ??? Jini. >>>>>> >>>>>> >>>>>> ???? > >>>>>> ???? > The rest looked good to me, though I wish there were a way >>>>>> to not >>>>>> ??? have >>>>>> ???? > to change all the strings to be regex friendly but I fail >>>>>> to see >>>>>> ??? how to >>>>>> ???? > do that without writing a runCmdWithoutRegexMatcher, which >>>>>> seems >>>>>> ???? > overkill :-) >>>>>> ???? > Jc >>>>>> ???? > >>>>>> ???? > On Tue, Dec 18, 2018 at 8:55 PM Jini George >>>>>> ??? >>>>>> ???? > >>>>> >> >>>>>> ??? wrote: >>>>>> ???? > >>>>>> ???? >? ? ?Hello! >>>>>> ???? > >>>>>> ???? >? ? ?Requesting reviews for: >>>>>> ???? > >>>>>> ???? > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/ >>>>>> ???? > >>>>>> ???? >? ? ?BugID: https://bugs.openjdk.java.net/browse/JDK-8215568 >>>>>> ???? > >>>>>> ???? >? ? ?No new failures with the SA tests (hs-tiers 1-5) with >>>>>> these >>>>>> ??? changes. >>>>>> ???? >? ? ?The >>>>>> ???? >? ? ?changes here include: >>>>>> ???? > >>>>>> ???? >? ? ?* Refactoring the SA tests which test clhsdb commands >>>>>> to use >>>>>> ???? >? ? ?ClhsdbLauncher for uniformity and ease of maintainence. >>>>>> ???? >? ? ?* Testing for regular expressions with shouldMatch >>>>>> rather than >>>>>> ???? >? ? ?shouldContain. >>>>>> ???? >? ? ?* Minor cleanups. >>>>>> ???? > >>>>>> ???? >? ? ?Thank you, >>>>>> ???? >? ? ?Jini. >>>>>> ???? > >>>>>> ???? > >>>>>> ???? > >>>>>> ???? > >>>>>> ???? > -- >>>>>> ???? > >>>>>> ???? > Thanks, >>>>>> ???? > Jc >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc From coleen.phillimore at oracle.com Tue Feb 5 02:28:40 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 21:28:40 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> <582dc6c6-29c4-4db9-d458-f34d7ddcabda@oracle.com> Message-ID: <7e4fa698-40cf-47b4-7eb3-ae1716ce939f@oracle.com> On 2/4/19 6:05 PM, David Holmes wrote: > On 5/02/2019 8:30 am, serguei.spitsyn at oracle.com wrote: >> Hi Coleen, >> >> Looks good in general. >> >> Just a couple minor comments below. >> >> I hope, you will update the copyright years before the push. >> >> >> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html >> >> >> ?? Nice test! >> >> ?? 37 import java.lang.reflect.*; >> ?? 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; >> ?? 39 import java.lang.instrument.*; >> >> ?? The imports above can be re-ordered. >> >> ?? 44???????? return new String("public class B" + count + " {" + >> ?? 45???????????????? "?? public static void compiledMethod() { " + >> ?? 46???????????????? "?????? try{" + >> ?? 47???????????????? " Thread.currentThread().sleep(1); " + >> ?? 48???????????????? "?????? } catch(InterruptedException ie) {" + >> ?? 49???????????????? "?????? }" + >> ?? 50???????????????? "?? }" + >> ?? 51???????????????? "}"); >> >> ?? Not clear, why sleep is needed here. > > Presumably just to give it some code and consume some time. Yes and so it wouldn't be optimized away. > > Nit: But it should just be: > > Thread.sleep(1) > > not > > Thread.currentThread().sleep(1); > Got it. Thanks, Coleen > sleep is a static method and as with all Thread static methods always > applies to the current thread. > > David > >> >> Thanks, >> Serguei >> >> >> On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >>> Added the serviceability-dev back. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>>> >>>> open webrev at >>>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>>> >>>> The links. >>>> Thanks, >>>> Coleen >>>> >>>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>>> >>>>> *This change touches the AOT and code cache code.? I tried to >>>>> describe it in the comments in the RFE.? Basically, for >>>>> redefinition, we walk the code cache per class redefined in order >>>>> to find evol_method dependencies, then deoptimize if we find them, >>>>> and then walk the code cache again to mark the deoptimized >>>>> nmethods as not_entrant. >>>>> >>>>> I replaced this with only marking any nmethods for the class's >>>>> methods to deoptimize (following InstanceKlass::_methods), also >>>>> marking aot methods dependent on the class, and then doing the >>>>> code cache walk to follow the evol_method dependencies at the end >>>>> of redefinition for all the classes. The new code uses the >>>>> Method::is_old() flag rather than comparing each method in the >>>>> InstanceKlass.? Then deoptimization and marking not_entrant is >>>>> done once at the end of the redefinition as well. >>>>> >>>>> Tested with tier1-6, all the redefinition tests locally: >>>>> >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>>> >&jvmti.out >>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>>> >&redefine.out >>>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>>> >>>>> new test, and JMH test (see CR for results). >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>> >>> >> From serguei.spitsyn at oracle.com Tue Feb 5 02:32:12 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 18:32:12 -0800 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <33a1dbcb-d7c3-5d1a-1e65-8c9b85c9ca02@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> <33a1dbcb-d7c3-5d1a-1e65-8c9b85c9ca02@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Feb 5 02:40:28 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 4 Feb 2019 18:40:28 -0800 Subject: PING: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: Hi Yasumasa, The fix looks good to me. Thanks, Serguei On 2/4/19 04:30, Yasumasa Suenaga wrote: > PING: Could you review it? > >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ > > > Thanks, > > Yasumasa > > > On 2019/01/28 9:35, Yasumasa Suenaga wrote: >> Hi all, >> >> This change has passed tests as below (all of jhsdb related tests): >> >> ??- Submit repo >> ??- All hotspot/jtreg/serviceability/sa >> ??- hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >> ??- All jdk/sun/tools/jhsdb >> ??- jdk/tools/launcher/HelpFlagsTest.java >> >> >> Comments are welcome. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/01/26 13:43, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ >>> >>> SA will handle `Flags` enums to get flag origin. >>> However SA has const value for bitmask for flag, and shows as raw >>> (int) value. >>> This issue is commented in [1]. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/8c035b34248d/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java#l166 From yasuenag at gmail.com Tue Feb 5 02:47:08 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 5 Feb 2019 11:47:08 +0900 Subject: PING: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: Thanks Serguei! Yasumasa 2019?2?5?(?) 11:40 serguei.spitsyn at oracle.com : > > Hi Yasumasa, > > The fix looks good to me. > > Thanks, > Serguei > > > On 2/4/19 04:30, Yasumasa Suenaga wrote: > > PING: Could you review it? > > > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 > >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2019/01/28 9:35, Yasumasa Suenaga wrote: > >> Hi all, > >> > >> This change has passed tests as below (all of jhsdb related tests): > >> > >> - Submit repo > >> - All hotspot/jtreg/serviceability/sa > >> - hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > >> - All jdk/sun/tools/jhsdb > >> - jdk/tools/launcher/HelpFlagsTest.java > >> > >> > >> Comments are welcome. > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >> On 2019/01/26 13:43, Yasumasa Suenaga wrote: > >>> Hi all, > >>> > >>> Please review this change: > >>> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 > >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ > >>> > >>> SA will handle `Flags` enums to get flag origin. > >>> However SA has const value for bitmask for flag, and shows as raw > >>> (int) value. > >>> This issue is commented in [1]. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>> [1] > >>> http://hg.openjdk.java.net/jdk/jdk/file/8c035b34248d/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java#l166 > From jini.george at oracle.com Tue Feb 5 03:01:13 2019 From: jini.george at oracle.com (Jini George) Date: Tue, 5 Feb 2019 08:31:13 +0530 Subject: PING: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: Hi Yasumasa, Thanks a bunch for this welcome change. Looks good to me overall -- a few points though. 1. Nit: alignment: 180 // See JVMFlag::print_origin() in HotSpot 2. In test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java, 156 expStrMap.put("flags", 157 List.of("command line", "ergonomic", "default")); I think you don't need to do one more round of testing by starting LingeredApp again and issuing the 'flags' command with runFlagOriginTest(). You should be able to check for the origin strings in runBasicTest() itself. You can add "command line", "ergonomic", "default" to 66 expStrMap.put("flags", List.of( 67 "UnlockDiagnosticVMOptions = true", 68 "MaxFDLimit = false", 69 "MaxJavaStackTraceDepth = 1024", 70 "VerifyMergedCPBytecodes", 71 "ConcGCThreads", "UseThreadPriorities", 72 "ShowHiddenFrames")); You can have it like this: 65 Map> expStrMap = new HashMap<>(); 66 expStrMap.put("flags", List.of( 67 "command line", "ergonomic", "default", 68 "UnlockDiagnosticVMOptions = true", 69 "MaxFDLimit = false", 70 "MaxJavaStackTraceDepth = 1024", 71 "VerifyMergedCPBytecodes", 72 "ConcGCThreads", "UseThreadPriorities", 73 "ShowHiddenFrames")); Thank you, Jini. On 2/4/2019 6:00 PM, Yasumasa Suenaga wrote: > PING: Could you review it? > >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ > > > Thanks, > > Yasumasa > > > On 2019/01/28 9:35, Yasumasa Suenaga wrote: >> Hi all, >> >> This change has passed tests as below (all of jhsdb related tests): >> >> ??- Submit repo >> ??- All hotspot/jtreg/serviceability/sa >> ??- hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >> ??- All jdk/sun/tools/jhsdb >> ??- jdk/tools/launcher/HelpFlagsTest.java >> >> >> Comments are welcome. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/01/26 13:43, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ >>> >>> SA will handle `Flags` enums to get flag origin. >>> However SA has const value for bitmask for flag, and shows as raw >>> (int) value. >>> This issue is commented in [1]. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/8c035b34248d/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java#l166 >>> From coleen.phillimore at oracle.com Tue Feb 5 03:32:37 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 4 Feb 2019 22:32:37 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> <5d49496d-1066-a75f-0bce-d16a75add792@oracle.com> <05aa3357-0696-84e4-7e23-3b7a7a3f90e6@oracle.com> <32fd7304-5ebb-99b3-d3fa-b23e22439084@oracle.com> <33a1dbcb-d7c3-5d1a-1e65-8c9b85c9ca02@oracle.com> Message-ID: <676e9102-4cea-acfb-48ab-3feb7f41f4c3@oracle.com> Thanks Serguei! Coleen On 2/4/19 9:32 PM, serguei.spitsyn at oracle.com wrote: > Hi Coleen, > > > On 2/4/19 18:26, coleen.phillimore at oracle.com wrote: >> >> >> On 2/4/19 5:30 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Coleen, >>> >>> Looks good in general. >>> >>> Just a couple minor comments below. >>> >>> I hope, you will update the copyright years before the push. >> >> Hi Serguei,? Thanks for reviewing this. >> >> Yes, I update the copyright years in my commit script. >>> >>> >>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev/test/hotspot/jtreg/runtime/RedefineTests/TestMultipleClasses.java.html >>> >>> ? Nice test! >>> 37 import java.lang.reflect.*; >>> 38 import jdk.test.lib.compiler.InMemoryJavaCompiler; >>> 39 import java.lang.instrument.*; >>> ? The imports above can be re-ordered. >> >> Alphabetically? > > Yes. (No need in another webrev) > >>> >>> 44 return new String("public class B" + count + " {" + >>> 45 " public static void compiledMethod() { " + >>> 46 " try{" + >>> 47 " Thread.currentThread().sleep(1); " + >>> 48 " } catch(InterruptedException ie) {" + >>> 49 " }" + >>> 50 " }" + >>> 51 "}"); >>> ? Not clear, why sleep is needed here. >>> >> >> Yes, the sleep was there so that the compiler didn't optimize away >> the function.? I didn't put a print because it would print too many >> times. > > Okay. > I hate, I placed this comment. :) > > Thanks, > Serguei > > >> Thanks, >> Coleen >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/4/19 12:34, serguei.spitsyn at oracle.com wrote: >>>> Added the serviceability-dev back. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 2/4/19 07:18, coleen.phillimore at oracle.com wrote: >>>>> >>>>> open webrev at >>>>> http://cr.openjdk.java.net/~coleenp/2019/8139551.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8139551 >>>>> >>>>> The links. >>>>> Thanks, >>>>> Coleen >>>>> >>>>> On 2/4/19 10:08 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Walk code cache and deoptimize once per redefinition.* >>>>>> >>>>>> *This change touches the AOT and code cache code.? I tried to >>>>>> describe it in the comments in the RFE. Basically, for >>>>>> redefinition, we walk the code cache per class redefined in order >>>>>> to find evol_method dependencies, then deoptimize if we find >>>>>> them, and then walk the code cache again to mark the deoptimized >>>>>> nmethods as not_entrant. >>>>>> >>>>>> I replaced this with only marking any nmethods for the class's >>>>>> methods to deoptimize (following InstanceKlass::_methods), also >>>>>> marking aot methods dependent on the class, and then doing the >>>>>> code cache walk to follow the evol_method dependencies at the end >>>>>> of redefinition for all the classes.?? The new code uses the >>>>>> Method::is_old() flag rather than comparing each method in the >>>>>> InstanceKlass.? Then deoptimization and marking not_entrant is >>>>>> done once at the end of the redefinition as well. >>>>>> >>>>>> Tested with tier1-6, all the redefinition tests locally: >>>>>> >>>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >>>>>> >&jvmti.out >>>>>> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >>>>>> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >>>>>> >&redefine.out >>>>>> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >>>>>> >>>>>> new test, and JMH test (see CR for results). >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Feb 5 03:37:29 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 4 Feb 2019 19:37:29 -0800 Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: <71c59a20-7669-e05c-e203-ee4eac527938@oracle.com> References: <1b6d4030-4980-7fd0-7784-72987239647a@oracle.com> <71c59a20-7669-e05c-e203-ee4eac527938@oracle.com> Message-ID: Hi David, Good point :). Thanks! Jc On Mon, Feb 4, 2019 at 5:13 PM David Holmes wrote: > Hi Jc, > > On 5/02/2019 3:47 am, Jean Christophe Beyler wrote: > > Hi Jini, > > > > The webrev looks good to me but I was wondering why you are changing the > > tests really. For example: > > > http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/test/hotspot/jtreg/serviceability/sa/ClhsdbAttach.java.html > > > > The main method already is declared to be throwing the top class > > Exception. It seems to me that you could then skip updating the tests: > > > > + } catch (SkippedException se) { > > + throw se; > > > > no? > > > > Probably I'm missing something but seemed like you didn't need to add > > this if you were just rethrowing it. > > It has to be caught to be rethrown, otherwise it is caught by the > following clause (which catches all Exception types) and a > RuntimeException thrown instead. > > David > ----- > > > On Wed, Jan 30, 2019 at 8:39 PM Jini George > > wrote: > > > > Thank you, David! > > > > - Jini. > > > > On 1/31/2019 7:45 AM, David Holmes wrote: > > > Hi Jini, > > > > > > This looks reasonable to me. > > > > > > Thanks, > > > David > > > > > > On 30/01/2019 9:59 pm, Jini George wrote: > > >> Requesting reviews for: > > >> > > >> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473 > > >> > > Webrev: > http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html > > >> > > >> The patch includes changes to use SkippedException to skip the > > tests > > >> when canPtraceAttachLinux() in Platform.java returns false. > > >> > > >> Thanks, > > >> Jini. > > >> > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Tue Feb 5 04:55:37 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 5 Feb 2019 13:55:37 +0900 Subject: PING: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: Hi Jini, Thank you for your comment! I uploaded new webrev. Could you review again? http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.01/ Diff from previous webrev is here: http://hg.openjdk.java.net/jdk/submit/rev/6e603980ab28 Yasumasa 2019?2?5?(?) 12:01 Jini George : > > Hi Yasumasa, > > Thanks a bunch for this welcome change. Looks good to me overall -- a > few points though. > > 1. Nit: alignment: > 180 // See JVMFlag::print_origin() in HotSpot > > 2. In test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java, > > 156 expStrMap.put("flags", > 157 List.of("command line", "ergonomic", > "default")); > > I think you don't need to do one more round of testing by starting > LingeredApp again and issuing the 'flags' command with > runFlagOriginTest(). You should be able to check for the origin strings > in runBasicTest() itself. You can add "command line", "ergonomic", > "default" to > > 66 expStrMap.put("flags", List.of( > 67 "UnlockDiagnosticVMOptions = true", > 68 "MaxFDLimit = false", > 69 "MaxJavaStackTraceDepth = 1024", > 70 "VerifyMergedCPBytecodes", > 71 "ConcGCThreads", "UseThreadPriorities", > 72 "ShowHiddenFrames")); > > You can have it like this: > > 65 Map> expStrMap = new HashMap<>(); > 66 expStrMap.put("flags", List.of( > 67 "command line", "ergonomic", "default", > 68 "UnlockDiagnosticVMOptions = true", > 69 "MaxFDLimit = false", > 70 "MaxJavaStackTraceDepth = 1024", > 71 "VerifyMergedCPBytecodes", > 72 "ConcGCThreads", "UseThreadPriorities", > 73 "ShowHiddenFrames")); > > Thank you, > Jini. > > > On 2/4/2019 6:00 PM, Yasumasa Suenaga wrote: > > PING: Could you review it? > > > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 > >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2019/01/28 9:35, Yasumasa Suenaga wrote: > >> Hi all, > >> > >> This change has passed tests as below (all of jhsdb related tests): > >> > >> - Submit repo > >> - All hotspot/jtreg/serviceability/sa > >> - hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > >> - All jdk/sun/tools/jhsdb > >> - jdk/tools/launcher/HelpFlagsTest.java > >> > >> > >> Comments are welcome. > >> > >> > >> Thanks, > >> > >> Yasumasa > >> > >> > >> On 2019/01/26 13:43, Yasumasa Suenaga wrote: > >>> Hi all, > >>> > >>> Please review this change: > >>> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 > >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ > >>> > >>> SA will handle `Flags` enums to get flag origin. > >>> However SA has const value for bitmask for flag, and shows as raw > >>> (int) value. > >>> This issue is commented in [1]. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>> [1] > >>> http://hg.openjdk.java.net/jdk/jdk/file/8c035b34248d/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java#l166 > >>> From jini.george at oracle.com Tue Feb 5 05:18:41 2019 From: jini.george at oracle.com (Jini George) Date: Tue, 5 Feb 2019 10:48:41 +0530 Subject: PING: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: Looks ok to me. Thanks! -Jini. On 2/5/2019 10:25 AM, Yasumasa Suenaga wrote: > Hi Jini, > > Thank you for your comment! > I uploaded new webrev. Could you review again? > > http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.01/ > > Diff from previous webrev is here: > > http://hg.openjdk.java.net/jdk/submit/rev/6e603980ab28 > > > Yasumasa > > 2019?2?5?(?) 12:01 Jini George : >> >> Hi Yasumasa, >> >> Thanks a bunch for this welcome change. Looks good to me overall -- a >> few points though. >> >> 1. Nit: alignment: >> 180 // See JVMFlag::print_origin() in HotSpot >> >> 2. In test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java, >> >> 156 expStrMap.put("flags", >> 157 List.of("command line", "ergonomic", >> "default")); >> >> I think you don't need to do one more round of testing by starting >> LingeredApp again and issuing the 'flags' command with >> runFlagOriginTest(). You should be able to check for the origin strings >> in runBasicTest() itself. You can add "command line", "ergonomic", >> "default" to >> >> 66 expStrMap.put("flags", List.of( >> 67 "UnlockDiagnosticVMOptions = true", >> 68 "MaxFDLimit = false", >> 69 "MaxJavaStackTraceDepth = 1024", >> 70 "VerifyMergedCPBytecodes", >> 71 "ConcGCThreads", "UseThreadPriorities", >> 72 "ShowHiddenFrames")); >> >> You can have it like this: >> >> 65 Map> expStrMap = new HashMap<>(); >> 66 expStrMap.put("flags", List.of( >> 67 "command line", "ergonomic", "default", >> 68 "UnlockDiagnosticVMOptions = true", >> 69 "MaxFDLimit = false", >> 70 "MaxJavaStackTraceDepth = 1024", >> 71 "VerifyMergedCPBytecodes", >> 72 "ConcGCThreads", "UseThreadPriorities", >> 73 "ShowHiddenFrames")); >> >> Thank you, >> Jini. >> >> >> On 2/4/2019 6:00 PM, Yasumasa Suenaga wrote: >>> PING: Could you review it? >>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/01/28 9:35, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> This change has passed tests as below (all of jhsdb related tests): >>>> >>>> - Submit repo >>>> - All hotspot/jtreg/serviceability/sa >>>> - hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >>>> - All jdk/sun/tools/jhsdb >>>> - jdk/tools/launcher/HelpFlagsTest.java >>>> >>>> >>>> Comments are welcome. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/01/26 13:43, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ >>>>> >>>>> SA will handle `Flags` enums to get flag origin. >>>>> However SA has const value for bitmask for flag, and shows as raw >>>>> (int) value. >>>>> This issue is commented in [1]. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/8c035b34248d/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java#l166 >>>>> From yasuenag at gmail.com Tue Feb 5 05:20:54 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 5 Feb 2019 14:20:54 +0900 Subject: PING: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: Thanks Jini! Yasumasa 2019?2?5?(?) 14:18 Jini George : > > Looks ok to me. Thanks! > > -Jini. > > On 2/5/2019 10:25 AM, Yasumasa Suenaga wrote: > > Hi Jini, > > > > Thank you for your comment! > > I uploaded new webrev. Could you review again? > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.01/ > > > > Diff from previous webrev is here: > > > > http://hg.openjdk.java.net/jdk/submit/rev/6e603980ab28 > > > > > > Yasumasa > > > > 2019?2?5?(?) 12:01 Jini George : > >> > >> Hi Yasumasa, > >> > >> Thanks a bunch for this welcome change. Looks good to me overall -- a > >> few points though. > >> > >> 1. Nit: alignment: > >> 180 // See JVMFlag::print_origin() in HotSpot > >> > >> 2. In test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java, > >> > >> 156 expStrMap.put("flags", > >> 157 List.of("command line", "ergonomic", > >> "default")); > >> > >> I think you don't need to do one more round of testing by starting > >> LingeredApp again and issuing the 'flags' command with > >> runFlagOriginTest(). You should be able to check for the origin strings > >> in runBasicTest() itself. You can add "command line", "ergonomic", > >> "default" to > >> > >> 66 expStrMap.put("flags", List.of( > >> 67 "UnlockDiagnosticVMOptions = true", > >> 68 "MaxFDLimit = false", > >> 69 "MaxJavaStackTraceDepth = 1024", > >> 70 "VerifyMergedCPBytecodes", > >> 71 "ConcGCThreads", "UseThreadPriorities", > >> 72 "ShowHiddenFrames")); > >> > >> You can have it like this: > >> > >> 65 Map> expStrMap = new HashMap<>(); > >> 66 expStrMap.put("flags", List.of( > >> 67 "command line", "ergonomic", "default", > >> 68 "UnlockDiagnosticVMOptions = true", > >> 69 "MaxFDLimit = false", > >> 70 "MaxJavaStackTraceDepth = 1024", > >> 71 "VerifyMergedCPBytecodes", > >> 72 "ConcGCThreads", "UseThreadPriorities", > >> 73 "ShowHiddenFrames")); > >> > >> Thank you, > >> Jini. > >> > >> > >> On 2/4/2019 6:00 PM, Yasumasa Suenaga wrote: > >>> PING: Could you review it? > >>> > >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 > >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ > >>> > >>> > >>> Thanks, > >>> > >>> Yasumasa > >>> > >>> > >>> On 2019/01/28 9:35, Yasumasa Suenaga wrote: > >>>> Hi all, > >>>> > >>>> This change has passed tests as below (all of jhsdb related tests): > >>>> > >>>> - Submit repo > >>>> - All hotspot/jtreg/serviceability/sa > >>>> - hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > >>>> - All jdk/sun/tools/jhsdb > >>>> - jdk/tools/launcher/HelpFlagsTest.java > >>>> > >>>> > >>>> Comments are welcome. > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>> On 2019/01/26 13:43, Yasumasa Suenaga wrote: > >>>>> Hi all, > >>>>> > >>>>> Please review this change: > >>>>> > >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 > >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ > >>>>> > >>>>> SA will handle `Flags` enums to get flag origin. > >>>>> However SA has const value for bitmask for flag, and shows as raw > >>>>> (int) value. > >>>>> This issue is commented in [1]. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yasumasa > >>>>> > >>>>> > >>>>> [1] > >>>>> http://hg.openjdk.java.net/jdk/jdk/file/8c035b34248d/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java#l166 > >>>>> From dean.long at oracle.com Tue Feb 5 06:50:48 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 4 Feb 2019 22:50:48 -0800 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> Message-ID: Could you move this code: ???? // Mark dependent AOT nmethods, which are only found via the class redefined. ???? AOTLoader::mark_evol_dependent_methods(ik); into this function: ???? CodeCache::mark_for_evol_deoptimization(ik) The rest looks good. dl On 2/4/19 7:08 AM, coleen.phillimore at oracle.com wrote: > Summary: Walk code cache and deoptimize once per redefinition.* > > *This change touches the AOT and code cache code.? I tried to describe > it in the comments in the RFE.? Basically, for redefinition, we walk > the code cache per class redefined in order to find evol_method > dependencies, then deoptimize if we find them, and then walk the code > cache again to mark the deoptimized nmethods as not_entrant. > > I replaced this with only marking any nmethods for the class's methods > to deoptimize (following InstanceKlass::_methods), also marking aot > methods dependent on the class, and then doing the code cache walk to > follow the evol_method dependencies at the end of redefinition for all > the classes.?? The new code uses the Method::is_old() flag rather than > comparing each method in the InstanceKlass.? Then deoptimization and > marking not_entrant is done once at the end of the redefinition as well. > > Tested with tier1-6, all the redefinition tests locally: > > make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out > make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out > make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests > >&redefine.out > make test TEST=open/test/jdk/java/lang/instrument >&instrument.out > > new test, and JMH test (see CR for results). > > Thanks, > Coleen > > From serguei.spitsyn at oracle.com Tue Feb 5 08:08:06 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Feb 2019 00:08:06 -0800 Subject: PING: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: <5c052737-0c5d-3cb4-7ba7-6b0c7906734e@oracle.com> +1 Thanks, Serguei On 2/4/19 21:18, Jini George wrote: > Looks ok to me. Thanks! > > -Jini. > > On 2/5/2019 10:25 AM, Yasumasa Suenaga wrote: >> Hi Jini, >> >> Thank you for your comment! >> I uploaded new webrev. Could you review again? >> >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.01/ >> >> Diff from previous webrev is here: >> >> ?? http://hg.openjdk.java.net/jdk/submit/rev/6e603980ab28 >> >> >> Yasumasa >> >> 2019?2?5?(?) 12:01 Jini George : >>> >>> Hi Yasumasa, >>> >>> Thanks a bunch for this welcome change. Looks good to me overall -- a >>> few points though. >>> >>> 1. Nit: alignment: >>> ??? 180???? // See JVMFlag::print_origin() in HotSpot >>> >>> 2. In test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java, >>> >>> 156???????????? expStrMap.put("flags", >>> 157?????????????????????????? List.of("command line", "ergonomic", >>> "default")); >>> >>> I think you don't need to do one more round of testing by starting >>> LingeredApp again and issuing the 'flags' command with >>> runFlagOriginTest(). You should be able to check for the origin strings >>> in runBasicTest() itself. You can add "command line", "ergonomic", >>> "default" to >>> >>> ?? 66???????????? expStrMap.put("flags", List.of( >>> ?? 67???????????????????? "UnlockDiagnosticVMOptions = true", >>> ?? 68???????????????????? "MaxFDLimit = false", >>> ?? 69???????????????????? "MaxJavaStackTraceDepth = 1024", >>> ?? 70???????????????????? "VerifyMergedCPBytecodes", >>> ?? 71???????????????????? "ConcGCThreads", "UseThreadPriorities", >>> ?? 72???????????????????? "ShowHiddenFrames")); >>> >>> You can have it like this: >>> >>> ?? 65???????????? Map> expStrMap = new >>> HashMap<>(); >>> ?? 66???????????? expStrMap.put("flags", List.of( >>> ?? 67???????????????????? "command line", "ergonomic", "default", >>> ?? 68???????????????????? "UnlockDiagnosticVMOptions = true", >>> ?? 69???????????????????? "MaxFDLimit = false", >>> ?? 70???????????????????? "MaxJavaStackTraceDepth = 1024", >>> ?? 71???????????????????? "VerifyMergedCPBytecodes", >>> ?? 72???????????????????? "ConcGCThreads", "UseThreadPriorities", >>> ?? 73???????????????????? "ShowHiddenFrames")); >>> >>> Thank you, >>> Jini. >>> >>> >>> On 2/4/2019 6:00 PM, Yasumasa Suenaga wrote: >>>> PING: Could you review it? >>>> >>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >>>>>> ??? webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/01/28 9:35, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> This change has passed tests as below (all of jhsdb related tests): >>>>> >>>>> ?? - Submit repo >>>>> ?? - All hotspot/jtreg/serviceability/sa >>>>> ?? - >>>>> hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >>>>> ?? - All jdk/sun/tools/jhsdb >>>>> ?? - jdk/tools/launcher/HelpFlagsTest.java >>>>> >>>>> >>>>> Comments are welcome. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2019/01/26 13:43, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change: >>>>>> >>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217845 >>>>>> ??? webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217845/webrev.00/ >>>>>> >>>>>> SA will handle `Flags` enums to get flag origin. >>>>>> However SA has const value for bitmask for flag, and shows as raw >>>>>> (int) value. >>>>>> This issue is commented in [1]. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/8c035b34248d/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java#l166 >>>>>> >>>>>> From hohensee at amazon.com Tue Feb 5 08:38:30 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 5 Feb 2019 08:38:30 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> Message-ID: <58343A66-F855-4FF3-8390-6B1C3A82E14E@amazon.com> Lin works for JDPower, which afaik has signed the OCA. ?On 2/4/19, 12:42 AM, "David Holmes" wrote: Hi Lin, Sorry but can I just confirm that you have signed the OCA [1]? I don't see you listed individually and I can't tell what company you work for or whether your are contributing on their behalf. Thanks, David [1] http://www.oracle.com/technetwork/oca-405177.pdf On 31/01/2019 4:42 pm, ?? wrote: > Hi David, Paul, > I have uploaded the refined webrev at > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > May I ask your help to review? > Thanks! > > BRs, > Lin > ________________________________________ > From: David Holmes > Sent: Thursday, January 31, 2019 9:19:31 AM > To: Hohensee, Paul; ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: >> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > Yes. Changes to command-line flags need a CSR. > > Thanks, > David > >> Thanks, >> >> Paul >> >> On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: >> >> A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. >> >> vm.heapHisto("", "-live") >> >> Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to >> >> * 'vm.heapHisto("", "-live")' will request a full GC >> >> In attachListener.cpp, the line >> >> out->print_cr("Invalid argument to dumpheap operation: %s", arg1); >> >> should be >> >> out->print_cr("Invalid argument to inspectheap operation: %s", arg1); >> >> Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. >> >> Paul >> >> On 1/30/19, 12:18 AM, "??" wrote: >> >> Dear All, >> This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. >> I have identified the root cause of the issue. it is caused by 2 problems. >> 1. The path processing in heap_inspection() at attachListener.cpp. >> The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. >> I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. >> >> 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. >> >> I have upload a webrev05: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ >> >> May I ask your help for review? >> >> Thanks, >> Lin >> ________________________________________ >> From: ?? >> Sent: Monday, January 28, 2019 5:49:42 PM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear all, >> I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. >> Thanks! >> >> BRs, >> Lin >> ________________________________________ >> From: ?? >> Sent: Friday, January 25, 2019 9:00:19 AM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear All, >> May I get more review about this webrev? >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ >> >> Thanks! >> BRs, >> Lin >> ________________________________________ >> From: ?? >> Sent: Tuesday, January 22, 2019 2:18:06 PM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Paul, >> Thanks a lot for your review. I have refined it based on your comments. >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ >> Would you like to help review it again? Thanks >> >> BRs, >> Lin >> ________________________________________ >> From: Hohensee, Paul >> Sent: Friday, January 18, 2019 6:11:14 AM >> To: ??; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Just a few small things. >> >> In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. >> >> In attachListener.cpp, line 275, change "Fail to" to "Failed to". >> >> In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. >> >> Thanks, >> >> Paul >> >> On 1/11/19, 1:39 AM, "??" wrote: >> >> Hi Jc, Paul and All, >> Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ >> would you like to help review? >> >> Thanks, >> Lin >> ________________________________________ >> From: ?? >> Sent: Friday, January 11, 2019 10:25:27 AM >> To: JC Beyler >> Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net >> Subject: ??: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Jc, >> Thanks a lot. it is not a necessary change, I forget to omit it:) >> >> BRs, >> Lin >> ________________________________ >> ???: JC Beyler >> ????: 2019?1?11? 0:58:22 >> ???: ?? >> ??: Hohensee, Paul; serviceability-dev at openjdk.java.net >> ??: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> Small nit: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html >> >> needs a copyright update, >> Jc >> >> >> On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: >> Dear All, >> I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ >> Would you like to help review? Thanks! >> >> BRs, >> Lin >> From: ?? >> Sent: Wednesday, January 9, 2019 11:00 AM >> To: 'JC Beyler' > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: RE: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear JC, >> Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. >> >> Cheers, >> Lin >> >> From: JC Beyler > >> Sent: Wednesday, January 9, 2019 10:51 AM >> To: ?? > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> Inlined as well :-) >> >> On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: >> Dear JC, >> Thanks for your comments, I inlined my comments here: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? >> --- (Lin) I will do that in next webrev. >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) >> --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? >> >> >> No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? >> >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". >> ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. >> >> I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. >> >> Thanks! >> Jc >> >> >> All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. >> >> Cheers, >> Lin >> >> >> From: JC Beyler > >> Sent: Wednesday, January 9, 2019 1:42 AM >> To: ?? > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> I have a few nits: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> >> You could fix the spaces arount the for loop you changed: >> >> + for (int i=0; i<4; i++) { >> to >> >> + for (int i = 0; i < 4; i++) { >> >> >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) >> >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html >> + filename = opt.substring(5); >> + if (filename != null) { >> -> I don't see how filename can be null here >> -> same filename could just be declared in the if >> >> >> >> + } else if (subopt.startsWith("file=")) { >> + filename = parseFileName(subopt); >> >> -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? >> >> -> in the option string printouts, you don't specify that all is an option as well, is that normal? >> >> >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". >> >> Thanks, >> Jc >> >> On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: >> >> Hi Paul, >> I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. >> And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ >> >> Hi All, >> May I also ask your help for reviewing this webrev? >> webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 >> >> Thanks! >> Lin >> >> ________________________________ >> ???: serviceability-dev > ?? ?? > >> ????: 2019?1?3? 10:21 >> ???: Hohensee, Paul; serviceability-dev at openjdk.java.net >> ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo >> >> >> Dear Paul, >> >> Thanks a lot for your review! I am trying to remend the patch >> >> One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. >> >> so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would >> >> be more reasonable than the ?if else? ? >> >> Thanks >> >> >> >> BRs, >> >> Lin >> >> >> >> >> >> >> >> From: Hohensee, Paul > >> Sent: Saturday, December 29, 2018 3:54 AM >> To: ?? >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> >> >> Update the copyright dates to 2019 please, since this won?t get pushed until then. >> >> >> >> In JMap.java, I?d emulate dump() and use >> >> >> >> String filename = null; >> >> String subopts[] = options.split(","); >> >> >> >> for (String subopt : subopts){ >> >> if (subopt.isEmpty() || subopt.equals("all")) { >> >> // pass >> >> } else if (subopt.equals("live")) { >> >> liveopt = "-live"; >> >> } else if (subopt.startsWith("file=")) { >> >> // file= - check that is specified >> >> if (subopt.length() > 5) { >> >> filename = subopt.substring(5); >> >> } >> >> } else { >> >> usage(1); >> >> } >> >> } >> >> >> >> // get the canonical path - important to avoid just passing >> >> // a "heap.bin" and having the dump created in the target VM >> >> // working directory rather than the directory where jmap >> >> // is executed. >> >> filename = new File(filename).getCanonicalPath(); >> >> // inspectHeap is not the same as jcmd GC.class_histogram >> >> executeCommandForPid(pid, "inspectheap", filename, liveopt); >> >> >> >> I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). >> >> >> >> The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. >> >> >> >> Thanks, >> >> >> >> Paul >> >> >> >> From: serviceability-dev > on behalf of ?? > >> Date: Thursday, December 20, 2018 at 11:03 PM >> To: "serviceability-dev at openjdk.java.net" > >> Subject: [RFR]8215622: Add dump to file support for jmap histo >> >> >> >> Hi All, >> >> May I ask your help to review this patch for enhance jmap ?histo. >> >> It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. >> >> This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. >> >> >> >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 >> >> >> >> Thanks. >> >> >> >> BRs, >> >> Lin >> >> >> >> >> >> >> >> >> -- >> >> Thanks, >> Jc >> >> >> -- >> >> Thanks, >> Jc >> >> >> -- >> >> Thanks, >> Jc >> >> >> >> >> >> From david.holmes at oracle.com Tue Feb 5 09:28:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 19:28:57 +1000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <58343A66-F855-4FF3-8390-6B1C3A82E14E@amazon.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <58343A66-F855-4FF3-8390-6B1C3A82E14E@amazon.com> Message-ID: <1a0ec6fc-9677-2ec1-9a7c-5d5ebd750fbf@oracle.com> Hi Paul, On 5/02/2019 6:38 pm, Hohensee, Paul wrote: > Lin works for JDPower, which afaik has signed the OCA. I don't see them listed at: https://www.oracle.com/technetwork/community/oca-486395.html Thanks, David > ?On 2/4/19, 12:42 AM, "David Holmes" wrote: > > Hi Lin, > > Sorry but can I just confirm that you have signed the OCA [1]? I don't > see you listed individually and I can't tell what company you work for > or whether your are contributing on their behalf. > > Thanks, > David > > [1] http://www.oracle.com/technetwork/oca-405177.pdf > > On 31/01/2019 4:42 pm, ?? wrote: > > Hi David, Paul, > > I have uploaded the refined webrev at > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > > May I ask your help to review? > > Thanks! > > > > BRs, > > Lin > > ________________________________________ > > From: David Holmes > > Sent: Thursday, January 31, 2019 9:19:31 AM > > To: Hohensee, Paul; ??; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > >> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > Yes. Changes to command-line flags need a CSR. > > > > Thanks, > > David > > > >> Thanks, > >> > >> Paul > >> > >> On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > >> > >> A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > >> > >> vm.heapHisto("", "-live") > >> > >> Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > >> > >> * 'vm.heapHisto("", "-live")' will request a full GC > >> > >> In attachListener.cpp, the line > >> > >> out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > >> > >> should be > >> > >> out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > >> > >> Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > >> > >> Paul > >> > >> On 1/30/19, 12:18 AM, "??" wrote: > >> > >> Dear All, > >> This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > >> I have identified the root cause of the issue. it is caused by 2 problems. > >> 1. The path processing in heap_inspection() at attachListener.cpp. > >> The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > >> I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > >> > >> 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > >> > >> I have upload a webrev05: > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > >> > >> May I ask your help for review? > >> > >> Thanks, > >> Lin > >> ________________________________________ > >> From: ?? > >> Sent: Monday, January 28, 2019 5:49:42 PM > >> To: Hohensee, Paul; JC Beyler > >> Cc: serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Dear all, > >> I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > >> Thanks! > >> > >> BRs, > >> Lin > >> ________________________________________ > >> From: ?? > >> Sent: Friday, January 25, 2019 9:00:19 AM > >> To: Hohensee, Paul; JC Beyler > >> Cc: serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Dear All, > >> May I get more review about this webrev? > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > >> > >> Thanks! > >> BRs, > >> Lin > >> ________________________________________ > >> From: ?? > >> Sent: Tuesday, January 22, 2019 2:18:06 PM > >> To: Hohensee, Paul; JC Beyler > >> Cc: serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Paul, > >> Thanks a lot for your review. I have refined it based on your comments. > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > >> Would you like to help review it again? Thanks > >> > >> BRs, > >> Lin > >> ________________________________________ > >> From: Hohensee, Paul > >> Sent: Friday, January 18, 2019 6:11:14 AM > >> To: ??; JC Beyler > >> Cc: serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Just a few small things. > >> > >> In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > >> > >> In attachListener.cpp, line 275, change "Fail to" to "Failed to". > >> > >> In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > >> > >> Thanks, > >> > >> Paul > >> > >> On 1/11/19, 1:39 AM, "??" wrote: > >> > >> Hi Jc, Paul and All, > >> Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > >> would you like to help review? > >> > >> Thanks, > >> Lin > >> ________________________________________ > >> From: ?? > >> Sent: Friday, January 11, 2019 10:25:27 AM > >> To: JC Beyler > >> Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > >> Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Jc, > >> Thanks a lot. it is not a necessary change, I forget to omit it:) > >> > >> BRs, > >> Lin > >> ________________________________ > >> ???: JC Beyler > >> ????: 2019?1?11? 0:58:22 > >> ???: ?? > >> ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > >> ??: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Lin, > >> > >> Small nit: > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > >> > >> needs a copyright update, > >> Jc > >> > >> > >> On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > >> Dear All, > >> I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > >> Would you like to help review? Thanks! > >> > >> BRs, > >> Lin > >> From: ?? > >> Sent: Wednesday, January 9, 2019 11:00 AM > >> To: 'JC Beyler' > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > >> Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Dear JC, > >> Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > >> > >> Cheers, > >> Lin > >> > >> From: JC Beyler > > >> Sent: Wednesday, January 9, 2019 10:51 AM > >> To: ?? > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Lin, > >> > >> Inlined as well :-) > >> > >> On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > >> Dear JC, > >> Thanks for your comments, I inlined my comments here: > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > >> --- (Lin) I will do that in next webrev. > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > >> --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > >> > >> > >> No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > >> > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > >> ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > >> > >> I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > >> > >> Thanks! > >> Jc > >> > >> > >> All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > >> > >> Cheers, > >> Lin > >> > >> > >> From: JC Beyler > > >> Sent: Wednesday, January 9, 2019 1:42 AM > >> To: ?? > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Lin, > >> > >> I have a few nits: > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > >> > >> You could fix the spaces arount the for loop you changed: > >> > >> + for (int i=0; i<4; i++) { > >> to > >> > >> + for (int i = 0; i < 4; i++) { > >> > >> > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > >> > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > >> + filename = opt.substring(5); > >> + if (filename != null) { > >> -> I don't see how filename can be null here > >> -> same filename could just be declared in the if > >> > >> > >> > >> + } else if (subopt.startsWith("file=")) { > >> + filename = parseFileName(subopt); > >> > >> -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > >> > >> -> in the option string printouts, you don't specify that all is an option as well, is that normal? > >> > >> > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > >> > >> Thanks, > >> Jc > >> > >> On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > >> > >> Hi Paul, > >> I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > >> And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > >> > >> Hi All, > >> May I also ask your help for reviewing this webrev? > >> webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > >> > >> Thanks! > >> Lin > >> > >> ________________________________ > >> ???: serviceability-dev > ?? ?? > > >> ????: 2019?1?3? 10:21 > >> ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > >> ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > >> > >> > >> Dear Paul, > >> > >> Thanks a lot for your review! I am trying to remend the patch > >> > >> One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > >> > >> so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > >> > >> be more reasonable than the ?if else? ? > >> > >> Thanks > >> > >> > >> > >> BRs, > >> > >> Lin > >> > >> > >> > >> > >> > >> > >> > >> From: Hohensee, Paul > > >> Sent: Saturday, December 29, 2018 3:54 AM > >> To: ?? >; serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> > >> > >> Update the copyright dates to 2019 please, since this won?t get pushed until then. > >> > >> > >> > >> In JMap.java, I?d emulate dump() and use > >> > >> > >> > >> String filename = null; > >> > >> String subopts[] = options.split(","); > >> > >> > >> > >> for (String subopt : subopts){ > >> > >> if (subopt.isEmpty() || subopt.equals("all")) { > >> > >> // pass > >> > >> } else if (subopt.equals("live")) { > >> > >> liveopt = "-live"; > >> > >> } else if (subopt.startsWith("file=")) { > >> > >> // file= - check that is specified > >> > >> if (subopt.length() > 5) { > >> > >> filename = subopt.substring(5); > >> > >> } > >> > >> } else { > >> > >> usage(1); > >> > >> } > >> > >> } > >> > >> > >> > >> // get the canonical path - important to avoid just passing > >> > >> // a "heap.bin" and having the dump created in the target VM > >> > >> // working directory rather than the directory where jmap > >> > >> // is executed. > >> > >> filename = new File(filename).getCanonicalPath(); > >> > >> // inspectHeap is not the same as jcmd GC.class_histogram > >> > >> executeCommandForPid(pid, "inspectheap", filename, liveopt); > >> > >> > >> > >> I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > >> > >> > >> > >> The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > >> > >> > >> > >> Thanks, > >> > >> > >> > >> Paul > >> > >> > >> > >> From: serviceability-dev > on behalf of ?? > > >> Date: Thursday, December 20, 2018 at 11:03 PM > >> To: "serviceability-dev at openjdk.java.net" > > >> Subject: [RFR]8215622: Add dump to file support for jmap histo > >> > >> > >> > >> Hi All, > >> > >> May I ask your help to review this patch for enhance jmap ?histo. > >> > >> It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > >> > >> This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > >> > >> > >> > >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > >> > >> > >> > >> Thanks. > >> > >> > >> > >> BRs, > >> > >> Lin > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > >> > >> > >> -- > >> > >> Thanks, > >> Jc > >> > >> > >> -- > >> > >> Thanks, > >> Jc > >> > >> > >> > >> > >> > >> > > From hohensee at amazon.com Tue Feb 5 11:17:47 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 5 Feb 2019 11:17:47 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <1a0ec6fc-9677-2ec1-9a7c-5d5ebd750fbf@oracle.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <58343A66-F855-4FF3-8390-6B1C3A82E14E@amazon.com> <1a0ec6fc-9677-2ec1-9a7c-5d5ebd750fbf@oracle.com> Message-ID: Hmm. Lin's posting webrevs via xiaofeya (Felix Wang), so technically Felix is publishing the code and so it's ok? Paul ?On 2/5/19, 1:29 AM, "David Holmes" wrote: Hi Paul, On 5/02/2019 6:38 pm, Hohensee, Paul wrote: > Lin works for JDPower, which afaik has signed the OCA. I don't see them listed at: https://www.oracle.com/technetwork/community/oca-486395.html Thanks, David > On 2/4/19, 12:42 AM, "David Holmes" wrote: > > Hi Lin, > > Sorry but can I just confirm that you have signed the OCA [1]? I don't > see you listed individually and I can't tell what company you work for > or whether your are contributing on their behalf. > > Thanks, > David > > [1] http://www.oracle.com/technetwork/oca-405177.pdf > > On 31/01/2019 4:42 pm, ?? wrote: > > Hi David, Paul, > > I have uploaded the refined webrev at > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > > May I ask your help to review? > > Thanks! > > > > BRs, > > Lin > > ________________________________________ > > From: David Holmes > > Sent: Thursday, January 31, 2019 9:19:31 AM > > To: Hohensee, Paul; ??; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > >> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > Yes. Changes to command-line flags need a CSR. > > > > Thanks, > > David > > > >> Thanks, > >> > >> Paul > >> > >> On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > >> > >> A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > >> > >> vm.heapHisto("", "-live") > >> > >> Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > >> > >> * 'vm.heapHisto("", "-live")' will request a full GC > >> > >> In attachListener.cpp, the line > >> > >> out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > >> > >> should be > >> > >> out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > >> > >> Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > >> > >> Paul > >> > >> On 1/30/19, 12:18 AM, "??" wrote: > >> > >> Dear All, > >> This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > >> I have identified the root cause of the issue. it is caused by 2 problems. > >> 1. The path processing in heap_inspection() at attachListener.cpp. > >> The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > >> I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > >> > >> 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > >> > >> I have upload a webrev05: > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > >> > >> May I ask your help for review? > >> > >> Thanks, > >> Lin > >> ________________________________________ > >> From: ?? > >> Sent: Monday, January 28, 2019 5:49:42 PM > >> To: Hohensee, Paul; JC Beyler > >> Cc: serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Dear all, > >> I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > >> Thanks! > >> > >> BRs, > >> Lin > >> ________________________________________ > >> From: ?? > >> Sent: Friday, January 25, 2019 9:00:19 AM > >> To: Hohensee, Paul; JC Beyler > >> Cc: serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Dear All, > >> May I get more review about this webrev? > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > >> > >> Thanks! > >> BRs, > >> Lin > >> ________________________________________ > >> From: ?? > >> Sent: Tuesday, January 22, 2019 2:18:06 PM > >> To: Hohensee, Paul; JC Beyler > >> Cc: serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Paul, > >> Thanks a lot for your review. I have refined it based on your comments. > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > >> Would you like to help review it again? Thanks > >> > >> BRs, > >> Lin > >> ________________________________________ > >> From: Hohensee, Paul > >> Sent: Friday, January 18, 2019 6:11:14 AM > >> To: ??; JC Beyler > >> Cc: serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Just a few small things. > >> > >> In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > >> > >> In attachListener.cpp, line 275, change "Fail to" to "Failed to". > >> > >> In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > >> > >> Thanks, > >> > >> Paul > >> > >> On 1/11/19, 1:39 AM, "??" wrote: > >> > >> Hi Jc, Paul and All, > >> Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > >> would you like to help review? > >> > >> Thanks, > >> Lin > >> ________________________________________ > >> From: ?? > >> Sent: Friday, January 11, 2019 10:25:27 AM > >> To: JC Beyler > >> Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > >> Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Jc, > >> Thanks a lot. it is not a necessary change, I forget to omit it:) > >> > >> BRs, > >> Lin > >> ________________________________ > >> ???: JC Beyler > >> ????: 2019?1?11? 0:58:22 > >> ???: ?? > >> ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > >> ??: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Lin, > >> > >> Small nit: > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > >> > >> needs a copyright update, > >> Jc > >> > >> > >> On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > >> Dear All, > >> I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > >> Would you like to help review? Thanks! > >> > >> BRs, > >> Lin > >> From: ?? > >> Sent: Wednesday, January 9, 2019 11:00 AM > >> To: 'JC Beyler' > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > >> Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Dear JC, > >> Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > >> > >> Cheers, > >> Lin > >> > >> From: JC Beyler > > >> Sent: Wednesday, January 9, 2019 10:51 AM > >> To: ?? > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Lin, > >> > >> Inlined as well :-) > >> > >> On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > >> Dear JC, > >> Thanks for your comments, I inlined my comments here: > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > >> --- (Lin) I will do that in next webrev. > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > >> --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > >> > >> > >> No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > >> > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > >> ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > >> > >> I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > >> > >> Thanks! > >> Jc > >> > >> > >> All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > >> > >> Cheers, > >> Lin > >> > >> > >> From: JC Beyler > > >> Sent: Wednesday, January 9, 2019 1:42 AM > >> To: ?? > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> Hi Lin, > >> > >> I have a few nits: > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > >> > >> You could fix the spaces arount the for loop you changed: > >> > >> + for (int i=0; i<4; i++) { > >> to > >> > >> + for (int i = 0; i < 4; i++) { > >> > >> > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > >> > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > >> + filename = opt.substring(5); > >> + if (filename != null) { > >> -> I don't see how filename can be null here > >> -> same filename could just be declared in the if > >> > >> > >> > >> + } else if (subopt.startsWith("file=")) { > >> + filename = parseFileName(subopt); > >> > >> -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > >> > >> -> in the option string printouts, you don't specify that all is an option as well, is that normal? > >> > >> > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > >> > >> Thanks, > >> Jc > >> > >> On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > >> > >> Hi Paul, > >> I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > >> And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > >> > >> Hi All, > >> May I also ask your help for reviewing this webrev? > >> webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > >> > >> Thanks! > >> Lin > >> > >> ________________________________ > >> ???: serviceability-dev > ?? ?? > > >> ????: 2019?1?3? 10:21 > >> ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > >> ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > >> > >> > >> Dear Paul, > >> > >> Thanks a lot for your review! I am trying to remend the patch > >> > >> One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > >> > >> so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > >> > >> be more reasonable than the ?if else? ? > >> > >> Thanks > >> > >> > >> > >> BRs, > >> > >> Lin > >> > >> > >> > >> > >> > >> > >> > >> From: Hohensee, Paul > > >> Sent: Saturday, December 29, 2018 3:54 AM > >> To: ?? >; serviceability-dev at openjdk.java.net > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > >> > >> > >> > >> Update the copyright dates to 2019 please, since this won?t get pushed until then. > >> > >> > >> > >> In JMap.java, I?d emulate dump() and use > >> > >> > >> > >> String filename = null; > >> > >> String subopts[] = options.split(","); > >> > >> > >> > >> for (String subopt : subopts){ > >> > >> if (subopt.isEmpty() || subopt.equals("all")) { > >> > >> // pass > >> > >> } else if (subopt.equals("live")) { > >> > >> liveopt = "-live"; > >> > >> } else if (subopt.startsWith("file=")) { > >> > >> // file= - check that is specified > >> > >> if (subopt.length() > 5) { > >> > >> filename = subopt.substring(5); > >> > >> } > >> > >> } else { > >> > >> usage(1); > >> > >> } > >> > >> } > >> > >> > >> > >> // get the canonical path - important to avoid just passing > >> > >> // a "heap.bin" and having the dump created in the target VM > >> > >> // working directory rather than the directory where jmap > >> > >> // is executed. > >> > >> filename = new File(filename).getCanonicalPath(); > >> > >> // inspectHeap is not the same as jcmd GC.class_histogram > >> > >> executeCommandForPid(pid, "inspectheap", filename, liveopt); > >> > >> > >> > >> I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > >> > >> > >> > >> The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > >> > >> > >> > >> Thanks, > >> > >> > >> > >> Paul > >> > >> > >> > >> From: serviceability-dev > on behalf of ?? > > >> Date: Thursday, December 20, 2018 at 11:03 PM > >> To: "serviceability-dev at openjdk.java.net" > > >> Subject: [RFR]8215622: Add dump to file support for jmap histo > >> > >> > >> > >> Hi All, > >> > >> May I ask your help to review this patch for enhance jmap ?histo. > >> > >> It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > >> > >> This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > >> > >> > >> > >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > >> > >> > >> > >> Thanks. > >> > >> > >> > >> BRs, > >> > >> Lin > >> > >> > >> > >> > >> > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > >> > >> > >> -- > >> > >> Thanks, > >> Jc > >> > >> > >> -- > >> > >> Thanks, > >> Jc > >> > >> > >> > >> > >> > >> > > From david.holmes at oracle.com Tue Feb 5 11:56:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 Feb 2019 21:56:15 +1000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <58343A66-F855-4FF3-8390-6B1C3A82E14E@amazon.com> <1a0ec6fc-9677-2ec1-9a7c-5d5ebd750fbf@oracle.com> Message-ID: On 5/02/2019 9:17 pm, Hohensee, Paul wrote: > Hmm. Lin's posting webrevs via xiaofeya (Felix Wang), so technically Felix is publishing the code and so it's ok? Lin is being listed as Contributor so there needs to be an OCA signed. And what is Felix's status? I don't see him listed and don't know who he works for. David > Paul > > ?On 2/5/19, 1:29 AM, "David Holmes" wrote: > > Hi Paul, > > On 5/02/2019 6:38 pm, Hohensee, Paul wrote: > > Lin works for JDPower, which afaik has signed the OCA. > > I don't see them listed at: > > https://www.oracle.com/technetwork/community/oca-486395.html > > Thanks, > David > > > On 2/4/19, 12:42 AM, "David Holmes" wrote: > > > > Hi Lin, > > > > Sorry but can I just confirm that you have signed the OCA [1]? I don't > > see you listed individually and I can't tell what company you work for > > or whether your are contributing on their behalf. > > > > Thanks, > > David > > > > [1] http://www.oracle.com/technetwork/oca-405177.pdf > > > > On 31/01/2019 4:42 pm, ?? wrote: > > > Hi David, Paul, > > > I have uploaded the refined webrev at > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > > > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > > > May I ask your help to review? > > > Thanks! > > > > > > BRs, > > > Lin > > > ________________________________________ > > > From: David Holmes > > > Sent: Thursday, January 31, 2019 9:19:31 AM > > > To: Hohensee, Paul; ??; JC Beyler > > > Cc: serviceability-dev at openjdk.java.net > > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > > >> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > > > Yes. Changes to command-line flags need a CSR. > > > > > > Thanks, > > > David > > > > > >> Thanks, > > >> > > >> Paul > > >> > > >> On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > >> > > >> A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > >> > > >> vm.heapHisto("", "-live") > > >> > > >> Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > >> > > >> * 'vm.heapHisto("", "-live")' will request a full GC > > >> > > >> In attachListener.cpp, the line > > >> > > >> out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > >> > > >> should be > > >> > > >> out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > >> > > >> Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > >> > > >> Paul > > >> > > >> On 1/30/19, 12:18 AM, "??" wrote: > > >> > > >> Dear All, > > >> This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > > >> I have identified the root cause of the issue. it is caused by 2 problems. > > >> 1. The path processing in heap_inspection() at attachListener.cpp. > > >> The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > > >> I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > >> > > >> 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > >> > > >> I have upload a webrev05: > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > >> > > >> May I ask your help for review? > > >> > > >> Thanks, > > >> Lin > > >> ________________________________________ > > >> From: ?? > > >> Sent: Monday, January 28, 2019 5:49:42 PM > > >> To: Hohensee, Paul; JC Beyler > > >> Cc: serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Dear all, > > >> I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > > >> Thanks! > > >> > > >> BRs, > > >> Lin > > >> ________________________________________ > > >> From: ?? > > >> Sent: Friday, January 25, 2019 9:00:19 AM > > >> To: Hohensee, Paul; JC Beyler > > >> Cc: serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Dear All, > > >> May I get more review about this webrev? > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > >> > > >> Thanks! > > >> BRs, > > >> Lin > > >> ________________________________________ > > >> From: ?? > > >> Sent: Tuesday, January 22, 2019 2:18:06 PM > > >> To: Hohensee, Paul; JC Beyler > > >> Cc: serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Paul, > > >> Thanks a lot for your review. I have refined it based on your comments. > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > >> Would you like to help review it again? Thanks > > >> > > >> BRs, > > >> Lin > > >> ________________________________________ > > >> From: Hohensee, Paul > > >> Sent: Friday, January 18, 2019 6:11:14 AM > > >> To: ??; JC Beyler > > >> Cc: serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Just a few small things. > > >> > > >> In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > >> > > >> In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > >> > > >> In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > >> > > >> Thanks, > > >> > > >> Paul > > >> > > >> On 1/11/19, 1:39 AM, "??" wrote: > > >> > > >> Hi Jc, Paul and All, > > >> Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > > >> would you like to help review? > > >> > > >> Thanks, > > >> Lin > > >> ________________________________________ > > >> From: ?? > > >> Sent: Friday, January 11, 2019 10:25:27 AM > > >> To: JC Beyler > > >> Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > > >> Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Jc, > > >> Thanks a lot. it is not a necessary change, I forget to omit it:) > > >> > > >> BRs, > > >> Lin > > >> ________________________________ > > >> ???: JC Beyler > > >> ????: 2019?1?11? 0:58:22 > > >> ???: ?? > > >> ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > > >> ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Lin, > > >> > > >> Small nit: > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > >> > > >> needs a copyright update, > > >> Jc > > >> > > >> > > >> On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > > >> Dear All, > > >> I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > > >> Would you like to help review? Thanks! > > >> > > >> BRs, > > >> Lin > > >> From: ?? > > >> Sent: Wednesday, January 9, 2019 11:00 AM > > >> To: 'JC Beyler' > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > >> Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Dear JC, > > >> Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > >> > > >> Cheers, > > >> Lin > > >> > > >> From: JC Beyler > > > >> Sent: Wednesday, January 9, 2019 10:51 AM > > >> To: ?? > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Lin, > > >> > > >> Inlined as well :-) > > >> > > >> On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > > >> Dear JC, > > >> Thanks for your comments, I inlined my comments here: > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > >> --- (Lin) I will do that in next webrev. > > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > >> --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > >> > > >> > > >> No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > >> > > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > >> ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > >> > > >> I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > >> > > >> Thanks! > > >> Jc > > >> > > >> > > >> All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > >> > > >> Cheers, > > >> Lin > > >> > > >> > > >> From: JC Beyler > > > >> Sent: Wednesday, January 9, 2019 1:42 AM > > >> To: ?? > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Lin, > > >> > > >> I have a few nits: > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > >> > > >> You could fix the spaces arount the for loop you changed: > > >> > > >> + for (int i=0; i<4; i++) { > > >> to > > >> > > >> + for (int i = 0; i < 4; i++) { > > >> > > >> > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > >> > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > > >> + filename = opt.substring(5); > > >> + if (filename != null) { > > >> -> I don't see how filename can be null here > > >> -> same filename could just be declared in the if > > >> > > >> > > >> > > >> + } else if (subopt.startsWith("file=")) { > > >> + filename = parseFileName(subopt); > > >> > > >> -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > >> > > >> -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > >> > > >> > > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > >> > > >> Thanks, > > >> Jc > > >> > > >> On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > >> > > >> Hi Paul, > > >> I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > > >> And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > >> > > >> Hi All, > > >> May I also ask your help for reviewing this webrev? > > >> webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > >> > > >> Thanks! > > >> Lin > > >> > > >> ________________________________ > > >> ???: serviceability-dev > ?? ?? > > > >> ????: 2019?1?3? 10:21 > > >> ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > > >> ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> > > >> Dear Paul, > > >> > > >> Thanks a lot for your review! I am trying to remend the patch > > >> > > >> One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > >> > > >> so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > >> > > >> be more reasonable than the ?if else? ? > > >> > > >> Thanks > > >> > > >> > > >> > > >> BRs, > > >> > > >> Lin > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> From: Hohensee, Paul > > > >> Sent: Saturday, December 29, 2018 3:54 AM > > >> To: ?? >; serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> > > >> > > >> Update the copyright dates to 2019 please, since this won?t get pushed until then. > > >> > > >> > > >> > > >> In JMap.java, I?d emulate dump() and use > > >> > > >> > > >> > > >> String filename = null; > > >> > > >> String subopts[] = options.split(","); > > >> > > >> > > >> > > >> for (String subopt : subopts){ > > >> > > >> if (subopt.isEmpty() || subopt.equals("all")) { > > >> > > >> // pass > > >> > > >> } else if (subopt.equals("live")) { > > >> > > >> liveopt = "-live"; > > >> > > >> } else if (subopt.startsWith("file=")) { > > >> > > >> // file= - check that is specified > > >> > > >> if (subopt.length() > 5) { > > >> > > >> filename = subopt.substring(5); > > >> > > >> } > > >> > > >> } else { > > >> > > >> usage(1); > > >> > > >> } > > >> > > >> } > > >> > > >> > > >> > > >> // get the canonical path - important to avoid just passing > > >> > > >> // a "heap.bin" and having the dump created in the target VM > > >> > > >> // working directory rather than the directory where jmap > > >> > > >> // is executed. > > >> > > >> filename = new File(filename).getCanonicalPath(); > > >> > > >> // inspectHeap is not the same as jcmd GC.class_histogram > > >> > > >> executeCommandForPid(pid, "inspectheap", filename, liveopt); > > >> > > >> > > >> > > >> I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > >> > > >> > > >> > > >> The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > >> > > >> > > >> > > >> Thanks, > > >> > > >> > > >> > > >> Paul > > >> > > >> > > >> > > >> From: serviceability-dev > on behalf of ?? > > > >> Date: Thursday, December 20, 2018 at 11:03 PM > > >> To: "serviceability-dev at openjdk.java.net" > > > >> Subject: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> > > >> > > >> Hi All, > > >> > > >> May I ask your help to review this patch for enhance jmap ?histo. > > >> > > >> It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > >> > > >> This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > >> > > >> > > >> > > >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > >> > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > >> > > >> > > >> > > >> Thanks. > > >> > > >> > > >> > > >> BRs, > > >> > > >> Lin > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> Thanks, > > >> Jc > > >> > > >> > > >> -- > > >> > > >> Thanks, > > >> Jc > > >> > > >> > > >> -- > > >> > > >> Thanks, > > >> Jc > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > From gary.adams at oracle.com Tue Feb 5 12:17:26 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 05 Feb 2019 07:17:26 -0500 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> References: <5C5845B2.40004@oracle.com> <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> Message-ID: <5C597ED6.3090006@oracle.com> On 2/4/19, 8:04 PM, David Holmes wrote: > Hi Gary, > > On 5/02/2019 12:01 am, Gary Adams wrote: >> Two of the redefine classes tests (021, 023) have been on the >> ProblemList since they >> were first brought into the open repos. Both tests made an incorrect >> assumption >> about the access modifiers in class files. There is a single bit in >> the binary class file that >> defines if an interface is public or not public (See JVMS Table 4.1-B >> ACC_PUBLIC). >> When the test classes are compiled for use in the redefine operation, >> if a source >> used public or protected the ACC_PUBLIC bit was set. >> >> Several modifiers are used in these tests to confirm >> UnsupportedOperationException >> is thrown or not thrown. This proposed change simply corrects the >> expected results >> according to the JVM Specification. >> >> Webrev: >> http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html > > test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java > > > 62 * Test cases 3 (private) and 4 (static) map to not public, so will > > "static" is not related to access modifiers so the ACC_PUBLIC bit is > not relevant. "static" can only be applied to (nested) member types > and is represented by the ACC_STATIC bit as per JVMS "Table 4.7.6-A. > Nested class access and property flags". > > What this testcase does is add "static" to a nested interface and > expects JVM TI to check if the class modifier has changed. But the > "static" is not encoded in the class "access flags", but in the inner > class attribute (inner_class_access_flags). To me this testcase should > throw UOE, but JVM TI is not checking the right flags. > > David I think the test is demonstrating that static does not change the ACC_PUBLIC bit. This changeset does not change the handling of that testcase. From coleen.phillimore at oracle.com Tue Feb 5 13:52:13 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 5 Feb 2019 08:52:13 -0500 Subject: RFR (M) 8139551: Scalability problem with redefinition - multiple code cache walks In-Reply-To: References: <241cfe96-c100-3d8c-2152-6acc204cb31c@oracle.com> Message-ID: Yes, I can do that.? Thank you for reviewing this! Coleen On 2/5/19 1:50 AM, dean.long at oracle.com wrote: > Could you move this code: > > ???? // Mark dependent AOT nmethods, which are only found via the > class redefined. > ???? AOTLoader::mark_evol_dependent_methods(ik); > > into this function: > > ???? CodeCache::mark_for_evol_deoptimization(ik) > > The rest looks good. > > dl > > On 2/4/19 7:08 AM, coleen.phillimore at oracle.com wrote: >> Summary: Walk code cache and deoptimize once per redefinition.* >> >> *This change touches the AOT and code cache code.? I tried to >> describe it in the comments in the RFE.? Basically, for redefinition, >> we walk the code cache per class redefined in order to find >> evol_method dependencies, then deoptimize if we find them, and then >> walk the code cache again to mark the deoptimized nmethods as >> not_entrant. >> >> I replaced this with only marking any nmethods for the class's >> methods to deoptimize (following InstanceKlass::_methods), also >> marking aot methods dependent on the class, and then doing the code >> cache walk to follow the evol_method dependencies at the end of >> redefinition for all the classes.?? The new code uses the >> Method::is_old() flag rather than comparing each method in the >> InstanceKlass.? Then deoptimization and marking not_entrant is done >> once at the end of the redefinition as well. >> >> Tested with tier1-6, all the redefinition tests locally: >> >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jvmti >&jvmti.out >> make test TEST=open/test/hotspot/jtreg/vmTestbase/nsk/jdi >&jdi.out >> make test TEST=open/test/hotspot/jtreg/runtime/RedefineTests >> >&redefine.out >> make test TEST=open/test/jdk/java/lang/instrument >&instrument.out >> >> new test, and JMH test (see CR for results). >> >> Thanks, >> Coleen >> >> > From hohensee at amazon.com Tue Feb 5 14:01:17 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 5 Feb 2019 14:01:17 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <58343A66-F855-4FF3-8390-6B1C3A82E14E@amazon.com> <1a0ec6fc-9677-2ec1-9a7c-5d5ebd750fbf@oracle.com> Message-ID: <7BBB102D-C993-422F-B333-C02414B37D2A@amazon.com> Lin's OOTO (Chinese New Year) but pinged me to say that his company's OCA name is "Beijing Wodong Tianjun Information Technology Co. Ltd. - OpenJDK", which is on the list. Felix Yang (typo in the name, sorry) is a co-worker. Paul ?On 2/5/19, 3:57 AM, "David Holmes" wrote: On 5/02/2019 9:17 pm, Hohensee, Paul wrote: > Hmm. Lin's posting webrevs via xiaofeya (Felix Wang), so technically Felix is publishing the code and so it's ok? Lin is being listed as Contributor so there needs to be an OCA signed. And what is Felix's status? I don't see him listed and don't know who he works for. David > Paul > > On 2/5/19, 1:29 AM, "David Holmes" wrote: > > Hi Paul, > > On 5/02/2019 6:38 pm, Hohensee, Paul wrote: > > Lin works for JDPower, which afaik has signed the OCA. > > I don't see them listed at: > > https://www.oracle.com/technetwork/community/oca-486395.html > > Thanks, > David > > > On 2/4/19, 12:42 AM, "David Holmes" wrote: > > > > Hi Lin, > > > > Sorry but can I just confirm that you have signed the OCA [1]? I don't > > see you listed individually and I can't tell what company you work for > > or whether your are contributing on their behalf. > > > > Thanks, > > David > > > > [1] http://www.oracle.com/technetwork/oca-405177.pdf > > > > On 31/01/2019 4:42 pm, ?? wrote: > > > Hi David, Paul, > > > I have uploaded the refined webrev at > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > > > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > > > May I ask your help to review? > > > Thanks! > > > > > > BRs, > > > Lin > > > ________________________________________ > > > From: David Holmes > > > Sent: Thursday, January 31, 2019 9:19:31 AM > > > To: Hohensee, Paul; ??; JC Beyler > > > Cc: serviceability-dev at openjdk.java.net > > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > > >> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > > > Yes. Changes to command-line flags need a CSR. > > > > > > Thanks, > > > David > > > > > >> Thanks, > > >> > > >> Paul > > >> > > >> On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > >> > > >> A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > >> > > >> vm.heapHisto("", "-live") > > >> > > >> Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > >> > > >> * 'vm.heapHisto("", "-live")' will request a full GC > > >> > > >> In attachListener.cpp, the line > > >> > > >> out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > >> > > >> should be > > >> > > >> out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > >> > > >> Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > >> > > >> Paul > > >> > > >> On 1/30/19, 12:18 AM, "??" wrote: > > >> > > >> Dear All, > > >> This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > > >> I have identified the root cause of the issue. it is caused by 2 problems. > > >> 1. The path processing in heap_inspection() at attachListener.cpp. > > >> The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > > >> I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > >> > > >> 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > >> > > >> I have upload a webrev05: > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > >> > > >> May I ask your help for review? > > >> > > >> Thanks, > > >> Lin > > >> ________________________________________ > > >> From: ?? > > >> Sent: Monday, January 28, 2019 5:49:42 PM > > >> To: Hohensee, Paul; JC Beyler > > >> Cc: serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Dear all, > > >> I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > > >> Thanks! > > >> > > >> BRs, > > >> Lin > > >> ________________________________________ > > >> From: ?? > > >> Sent: Friday, January 25, 2019 9:00:19 AM > > >> To: Hohensee, Paul; JC Beyler > > >> Cc: serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Dear All, > > >> May I get more review about this webrev? > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > >> > > >> Thanks! > > >> BRs, > > >> Lin > > >> ________________________________________ > > >> From: ?? > > >> Sent: Tuesday, January 22, 2019 2:18:06 PM > > >> To: Hohensee, Paul; JC Beyler > > >> Cc: serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Paul, > > >> Thanks a lot for your review. I have refined it based on your comments. > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > >> Would you like to help review it again? Thanks > > >> > > >> BRs, > > >> Lin > > >> ________________________________________ > > >> From: Hohensee, Paul > > >> Sent: Friday, January 18, 2019 6:11:14 AM > > >> To: ??; JC Beyler > > >> Cc: serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Just a few small things. > > >> > > >> In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > >> > > >> In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > >> > > >> In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > >> > > >> Thanks, > > >> > > >> Paul > > >> > > >> On 1/11/19, 1:39 AM, "??" wrote: > > >> > > >> Hi Jc, Paul and All, > > >> Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > > >> would you like to help review? > > >> > > >> Thanks, > > >> Lin > > >> ________________________________________ > > >> From: ?? > > >> Sent: Friday, January 11, 2019 10:25:27 AM > > >> To: JC Beyler > > >> Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > > >> Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Jc, > > >> Thanks a lot. it is not a necessary change, I forget to omit it:) > > >> > > >> BRs, > > >> Lin > > >> ________________________________ > > >> ???: JC Beyler > > >> ????: 2019?1?11? 0:58:22 > > >> ???: ?? > > >> ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > > >> ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Lin, > > >> > > >> Small nit: > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > >> > > >> needs a copyright update, > > >> Jc > > >> > > >> > > >> On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > > >> Dear All, > > >> I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > > >> Would you like to help review? Thanks! > > >> > > >> BRs, > > >> Lin > > >> From: ?? > > >> Sent: Wednesday, January 9, 2019 11:00 AM > > >> To: 'JC Beyler' > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > >> Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Dear JC, > > >> Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > >> > > >> Cheers, > > >> Lin > > >> > > >> From: JC Beyler > > > >> Sent: Wednesday, January 9, 2019 10:51 AM > > >> To: ?? > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Lin, > > >> > > >> Inlined as well :-) > > >> > > >> On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > > >> Dear JC, > > >> Thanks for your comments, I inlined my comments here: > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > >> --- (Lin) I will do that in next webrev. > > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > >> --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > >> > > >> > > >> No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > >> > > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > >> ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > >> > > >> I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > >> > > >> Thanks! > > >> Jc > > >> > > >> > > >> All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > >> > > >> Cheers, > > >> Lin > > >> > > >> > > >> From: JC Beyler > > > >> Sent: Wednesday, January 9, 2019 1:42 AM > > >> To: ?? > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> Hi Lin, > > >> > > >> I have a few nits: > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > >> > > >> You could fix the spaces arount the for loop you changed: > > >> > > >> + for (int i=0; i<4; i++) { > > >> to > > >> > > >> + for (int i = 0; i < 4; i++) { > > >> > > >> > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > >> > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > > >> + filename = opt.substring(5); > > >> + if (filename != null) { > > >> -> I don't see how filename can be null here > > >> -> same filename could just be declared in the if > > >> > > >> > > >> > > >> + } else if (subopt.startsWith("file=")) { > > >> + filename = parseFileName(subopt); > > >> > > >> -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > >> > > >> -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > >> > > >> > > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > >> > > >> Thanks, > > >> Jc > > >> > > >> On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > >> > > >> Hi Paul, > > >> I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > > >> And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > >> > > >> Hi All, > > >> May I also ask your help for reviewing this webrev? > > >> webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > >> > > >> Thanks! > > >> Lin > > >> > > >> ________________________________ > > >> ???: serviceability-dev > ?? ?? > > > >> ????: 2019?1?3? 10:21 > > >> ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > > >> ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> > > >> Dear Paul, > > >> > > >> Thanks a lot for your review! I am trying to remend the patch > > >> > > >> One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > >> > > >> so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > >> > > >> be more reasonable than the ?if else? ? > > >> > > >> Thanks > > >> > > >> > > >> > > >> BRs, > > >> > > >> Lin > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> From: Hohensee, Paul > > > >> Sent: Saturday, December 29, 2018 3:54 AM > > >> To: ?? >; serviceability-dev at openjdk.java.net > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> > > >> > > >> Update the copyright dates to 2019 please, since this won?t get pushed until then. > > >> > > >> > > >> > > >> In JMap.java, I?d emulate dump() and use > > >> > > >> > > >> > > >> String filename = null; > > >> > > >> String subopts[] = options.split(","); > > >> > > >> > > >> > > >> for (String subopt : subopts){ > > >> > > >> if (subopt.isEmpty() || subopt.equals("all")) { > > >> > > >> // pass > > >> > > >> } else if (subopt.equals("live")) { > > >> > > >> liveopt = "-live"; > > >> > > >> } else if (subopt.startsWith("file=")) { > > >> > > >> // file= - check that is specified > > >> > > >> if (subopt.length() > 5) { > > >> > > >> filename = subopt.substring(5); > > >> > > >> } > > >> > > >> } else { > > >> > > >> usage(1); > > >> > > >> } > > >> > > >> } > > >> > > >> > > >> > > >> // get the canonical path - important to avoid just passing > > >> > > >> // a "heap.bin" and having the dump created in the target VM > > >> > > >> // working directory rather than the directory where jmap > > >> > > >> // is executed. > > >> > > >> filename = new File(filename).getCanonicalPath(); > > >> > > >> // inspectHeap is not the same as jcmd GC.class_histogram > > >> > > >> executeCommandForPid(pid, "inspectheap", filename, liveopt); > > >> > > >> > > >> > > >> I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > >> > > >> > > >> > > >> The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > >> > > >> > > >> > > >> Thanks, > > >> > > >> > > >> > > >> Paul > > >> > > >> > > >> > > >> From: serviceability-dev > on behalf of ?? > > > >> Date: Thursday, December 20, 2018 at 11:03 PM > > >> To: "serviceability-dev at openjdk.java.net" > > > >> Subject: [RFR]8215622: Add dump to file support for jmap histo > > >> > > >> > > >> > > >> Hi All, > > >> > > >> May I ask your help to review this patch for enhance jmap ?histo. > > >> > > >> It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > >> > > >> This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > >> > > >> > > >> > > >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > >> > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > >> > > >> > > >> > > >> Thanks. > > >> > > >> > > >> > > >> BRs, > > >> > > >> Lin > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> -- > > >> > > >> Thanks, > > >> Jc > > >> > > >> > > >> -- > > >> > > >> Thanks, > > >> Jc > > >> > > >> > > >> -- > > >> > > >> Thanks, > > >> Jc > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > From hohensee at amazon.com Tue Feb 5 14:02:54 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 5 Feb 2019 14:02:54 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <4c797f80a87748c5bb260ea5715be75e@jd.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> Message-ID: Looks good to me. David, who should review the CSR? Is there someone who "owns" jmap or perhaps the serviceability group lead if there is such a person? Thanks, Paul ?On 1/30/19, 10:43 PM, "??" wrote: Hi David, Paul, I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 May I ask your help to review? Thanks! BRs, Lin ________________________________________ From: David Holmes Sent: Thursday, January 31, 2019 9:19:31 AM To: Hohensee, Paul; ??; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo On 31/01/2019 10:41 am, Hohensee, Paul wrote: > Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? Yes. Changes to command-line flags need a CSR. Thanks, David > Thanks, > > Paul > > On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > vm.heapHisto("", "-live") > > Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > * 'vm.heapHisto("", "-live")' will request a full GC > > In attachListener.cpp, the line > > out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > should be > > out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > Paul > > On 1/30/19, 12:18 AM, "??" wrote: > > Dear All, > This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > I have identified the root cause of the issue. it is caused by 2 problems. > 1. The path processing in heap_inspection() at attachListener.cpp. > The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > I have upload a webrev05: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > May I ask your help for review? > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Monday, January 28, 2019 5:49:42 PM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Dear all, > I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > Thanks! > > BRs, > Lin > ________________________________________ > From: ?? > Sent: Friday, January 25, 2019 9:00:19 AM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Dear All, > May I get more review about this webrev? > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > Thanks! > BRs, > Lin > ________________________________________ > From: ?? > Sent: Tuesday, January 22, 2019 2:18:06 PM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Paul, > Thanks a lot for your review. I have refined it based on your comments. > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > Would you like to help review it again? Thanks > > BRs, > Lin > ________________________________________ > From: Hohensee, Paul > Sent: Friday, January 18, 2019 6:11:14 AM > To: ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Just a few small things. > > In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > Thanks, > > Paul > > On 1/11/19, 1:39 AM, "??" wrote: > > Hi Jc, Paul and All, > Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > would you like to help review? > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Friday, January 11, 2019 10:25:27 AM > To: JC Beyler > Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > Hi Jc, > Thanks a lot. it is not a necessary change, I forget to omit it:) > > BRs, > Lin > ________________________________ > ???: JC Beyler > ????: 2019?1?11? 0:58:22 > ???: ?? > ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Small nit: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > needs a copyright update, > Jc > > > On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > Dear All, > I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > Would you like to help review? Thanks! > > BRs, > Lin > From: ?? > Sent: Wednesday, January 9, 2019 11:00 AM > To: 'JC Beyler' > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > Dear JC, > Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > Cheers, > Lin > > From: JC Beyler > > Sent: Wednesday, January 9, 2019 10:51 AM > To: ?? > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Inlined as well :-) > > On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > Dear JC, > Thanks for your comments, I inlined my comments here: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > --- (Lin) I will do that in next webrev. > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > > No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > Thanks! > Jc > > > All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > Cheers, > Lin > > > From: JC Beyler > > Sent: Wednesday, January 9, 2019 1:42 AM > To: ?? > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > I have a few nits: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > You could fix the spaces arount the for loop you changed: > > + for (int i=0; i<4; i++) { > to > > + for (int i = 0; i < 4; i++) { > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > + filename = opt.substring(5); > + if (filename != null) { > -> I don't see how filename can be null here > -> same filename could just be declared in the if > > > > + } else if (subopt.startsWith("file=")) { > + filename = parseFileName(subopt); > > -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > Thanks, > Jc > > On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > Hi Paul, > I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > Hi All, > May I also ask your help for reviewing this webrev? > webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > Thanks! > Lin > > ________________________________ > ???: serviceability-dev > ?? ?? > > ????: 2019?1?3? 10:21 > ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > > Dear Paul, > > Thanks a lot for your review! I am trying to remend the patch > > One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > be more reasonable than the ?if else? ? > > Thanks > > > > BRs, > > Lin > > > > > > > > From: Hohensee, Paul > > Sent: Saturday, December 29, 2018 3:54 AM > To: ?? >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Update the copyright dates to 2019 please, since this won?t get pushed until then. > > > > In JMap.java, I?d emulate dump() and use > > > > String filename = null; > > String subopts[] = options.split(","); > > > > for (String subopt : subopts){ > > if (subopt.isEmpty() || subopt.equals("all")) { > > // pass > > } else if (subopt.equals("live")) { > > liveopt = "-live"; > > } else if (subopt.startsWith("file=")) { > > // file= - check that is specified > > if (subopt.length() > 5) { > > filename = subopt.substring(5); > > } > > } else { > > usage(1); > > } > > } > > > > // get the canonical path - important to avoid just passing > > // a "heap.bin" and having the dump created in the target VM > > // working directory rather than the directory where jmap > > // is executed. > > filename = new File(filename).getCanonicalPath(); > > // inspectHeap is not the same as jcmd GC.class_histogram > > executeCommandForPid(pid, "inspectheap", filename, liveopt); > > > > I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > > > The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > > > Thanks, > > > > Paul > > > > From: serviceability-dev > on behalf of ?? > > Date: Thursday, December 20, 2018 at 11:03 PM > To: "serviceability-dev at openjdk.java.net" > > Subject: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi All, > > May I ask your help to review this patch for enhance jmap ?histo. > > It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > > Thanks. > > > > BRs, > > Lin > > > > > > > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc > > > > > > From aph at redhat.com Tue Feb 5 17:14:52 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Feb 2019 17:14:52 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: Message-ID: On 2/1/19 9:22 AM, Nick Gasson (Arm Technology China) wrote: > On AArch64, if you use "jhsdb clhsdb --pid=..." to attach a debugger to > a Java process, and then run "jstack -v" while any thread is executing a > native method, you will get a NullPointerException like this: This does not happen for me. I have a test case which runs a native method; the native method does not return. I then run jstack -v and get a clean stack trace, regardless of whether it's interpreted or compiled: "main" #1 prio=5 tid=0x0000ffff7001a000 nid=0x596c runnable [0x0000ffff7624e000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native - Spinner.main(java.lang.String[]) @bci=0, line=9, pc=0x0000ffff6d6954d8, Method*=0x0000ffff2321e380 (Compiled frame; information may be imprecise) Locked ownable synchronizers: - None I tries various combinations of Xcomp and tiered compilation. What did you do? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- A non-text attachment was scrubbed... Name: Spinner.c Type: text/x-csrc Size: 212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Spinner.h Type: text/x-chdr Size: 357 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Spinner.java Type: text/x-java Size: 181 bytes Desc: not available URL: From serguei.spitsyn at oracle.com Tue Feb 5 17:22:48 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Feb 2019 09:22:48 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> Message-ID: <54bc1360-00f6-07d1-d2a3-a285563c6621@oracle.com> An HTML attachment was scrubbed... URL: From aph at redhat.com Tue Feb 5 17:26:41 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Feb 2019 17:26:41 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: Message-ID: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> On 2/1/19 9:22 AM, Nick Gasson (Arm Technology China) wrote: > On AArch64, if you use "jhsdb clhsdb --pid=..." to attach a debugger to > a Java process, and then run "jstack -v" while any thread is executing a > native method, you will get a NullPointerException like this: This does not happen for me. I have a test case which runs a native method; the native method does not return. I then run jstack -v and get a clean stack trace, regardless of whether it's interpreted or compiled: "main" #1 prio=5 tid=0x0000ffff7001a000 nid=0x596c runnable [0x0000ffff7624e000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native - Spinner.main(java.lang.String[]) @bci=0, line=9, pc=0x0000ffff6d6954d8, Method*=0x0000ffff2321e380 (Compiled frame; information may be imprecise) Locked ownable synchronizers: - None I tried various combinations of Xcomp and tiered compilation, release and debug builds. What did you do? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- A non-text attachment was scrubbed... Name: Spinner.c Type: text/x-csrc Size: 213 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Spinner.h Type: text/x-chdr Size: 358 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Spinner.java Type: text/x-java Size: 182 bytes Desc: not available URL: From Nick.Gasson at arm.com Tue Feb 5 17:55:10 2019 From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China)) Date: Tue, 5 Feb 2019 17:55:10 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> References: , <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> Message-ID: Hi Andrew, I followed the same steps as the serviceabilty/sa/ClhsdbJstack.java test. You can see this failing in Linaro's results here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/builds/release/2019/028/JTwork-hotspot/serviceability/sa/ClhsdbJstack.jtr The stack trace you sent below is incomplete, it's missing the frame for Spinner.run (i.e. the AARCH64Frame object corresponding to the native wrapper frame). Did you try on x86 or with the patch I posted? I'm not able to test at the moment but I think you will get one exra frame in the output. I don't know why you don't get the NPE, I guess it depends on what's in that stack slot. Nick ________________________________ From: Andrew Haley Sent: 06 February 2019 01:26:41 To: Nick Gasson (Arm Technology China); serviceability-dev at openjdk.java.net Cc: nd; aarch64-port-dev at openjdk.java.net Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command On 2/1/19 9:22 AM, Nick Gasson (Arm Technology China) wrote: > On AArch64, if you use "jhsdb clhsdb --pid=..." to attach a debugger to > a Java process, and then run "jstack -v" while any thread is executing a > native method, you will get a NullPointerException like this: This does not happen for me. I have a test case which runs a native method; the native method does not return. I then run jstack -v and get a clean stack trace, regardless of whether it's interpreted or compiled: "main" #1 prio=5 tid=0x0000ffff7001a000 nid=0x596c runnable [0x0000ffff7624e000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_in_native - Spinner.main(java.lang.String[]) @bci=0, line=9, pc=0x0000ffff6d6954d8, Method*=0x0000ffff2321e380 (Compiled frame; information may be imprecise) Locked ownable synchronizers: - None I tried various combinations of Xcomp and tiered compilation, release and debug builds. What did you do? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Tue Feb 5 17:57:07 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 Feb 2019 17:57:07 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> Message-ID: <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> On 2/5/19 5:55 PM, Nick Gasson (Arm Technology China) wrote: > The stack trace you sent below is incomplete, it's missing the frame for Spinner.run (i.e. the AARCH64Frame object corresponding to the native wrapper frame). Did you try on x86 or with the patch I posted? I'm not able to test at the moment but I think you will get one exra frame in the output. I don't know why you don't get the NPE, I guess it depends on what's in that stack slot. Never mind, found it. A more complex test is needed. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- A non-text attachment was scrubbed... Name: Spinner.c Type: text/x-csrc Size: 212 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Spinner.java Type: text/x-java Size: 181 bytes Desc: not available URL: From david.holmes at oracle.com Tue Feb 5 20:55:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Feb 2019 06:55:01 +1000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <7BBB102D-C993-422F-B333-C02414B37D2A@amazon.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <58343A66-F855-4FF3-8390-6B1C3A82E14E@amazon.com> <1a0ec6fc-9677-2ec1-9a7c-5d5ebd750fbf@oracle.com> <7BBB102D-C993-422F-B333-C02414B37D2A@amazon.com> Message-ID: On 6/02/2019 12:01 am, Hohensee, Paul wrote: > Lin's OOTO (Chinese New Year) but pinged me to say that his company's OCA name is "Beijing Wodong Tianjun Information Technology Co. Ltd. - OpenJDK", which is on the list. Felix Yang (typo in the name, sorry) is a co-worker. Thanks for the info Paul - would never have figured that out by myself :) I see Serguei has offered to review the CSR. Any engineer can review a CSR request - it's just a confirmation that the proposed spec change is complete and as intended and the compatibility aspects have been characterised correctly. Thankss, David > Paul > > ?On 2/5/19, 3:57 AM, "David Holmes" wrote: > > On 5/02/2019 9:17 pm, Hohensee, Paul wrote: > > Hmm. Lin's posting webrevs via xiaofeya (Felix Wang), so technically Felix is publishing the code and so it's ok? > > Lin is being listed as Contributor so there needs to be an OCA signed. > > And what is Felix's status? I don't see him listed and don't know who he > works for. > > David > > > Paul > > > > On 2/5/19, 1:29 AM, "David Holmes" wrote: > > > > Hi Paul, > > > > On 5/02/2019 6:38 pm, Hohensee, Paul wrote: > > > Lin works for JDPower, which afaik has signed the OCA. > > > > I don't see them listed at: > > > > https://www.oracle.com/technetwork/community/oca-486395.html > > > > Thanks, > > David > > > > > On 2/4/19, 12:42 AM, "David Holmes" wrote: > > > > > > Hi Lin, > > > > > > Sorry but can I just confirm that you have signed the OCA [1]? I don't > > > see you listed individually and I can't tell what company you work for > > > or whether your are contributing on their behalf. > > > > > > Thanks, > > > David > > > > > > [1] http://www.oracle.com/technetwork/oca-405177.pdf > > > > > > On 31/01/2019 4:42 pm, ?? wrote: > > > > Hi David, Paul, > > > > I have uploaded the refined webrev at > > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > > > > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > > > > May I ask your help to review? > > > > Thanks! > > > > > > > > BRs, > > > > Lin > > > > ________________________________________ > > > > From: David Holmes > > > > Sent: Thursday, January 31, 2019 9:19:31 AM > > > > To: Hohensee, Paul; ??; JC Beyler > > > > Cc: serviceability-dev at openjdk.java.net > > > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > > > > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > > > >> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > > > > > Yes. Changes to command-line flags need a CSR. > > > > > > > > Thanks, > > > > David > > > > > > > >> Thanks, > > > >> > > > >> Paul > > > >> > > > >> On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > > >> > > > >> A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > > >> > > > >> vm.heapHisto("", "-live") > > > >> > > > >> Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > > >> > > > >> * 'vm.heapHisto("", "-live")' will request a full GC > > > >> > > > >> In attachListener.cpp, the line > > > >> > > > >> out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > > >> > > > >> should be > > > >> > > > >> out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > > >> > > > >> Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > > >> > > > >> Paul > > > >> > > > >> On 1/30/19, 12:18 AM, "??" wrote: > > > >> > > > >> Dear All, > > > >> This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > > > >> I have identified the root cause of the issue. it is caused by 2 problems. > > > >> 1. The path processing in heap_inspection() at attachListener.cpp. > > > >> The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > > > >> I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > > >> > > > >> 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > > >> > > > >> I have upload a webrev05: > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > > >> > > > >> May I ask your help for review? > > > >> > > > >> Thanks, > > > >> Lin > > > >> ________________________________________ > > > >> From: ?? > > > >> Sent: Monday, January 28, 2019 5:49:42 PM > > > >> To: Hohensee, Paul; JC Beyler > > > >> Cc: serviceability-dev at openjdk.java.net > > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Dear all, > > > >> I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > > > >> Thanks! > > > >> > > > >> BRs, > > > >> Lin > > > >> ________________________________________ > > > >> From: ?? > > > >> Sent: Friday, January 25, 2019 9:00:19 AM > > > >> To: Hohensee, Paul; JC Beyler > > > >> Cc: serviceability-dev at openjdk.java.net > > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Dear All, > > > >> May I get more review about this webrev? > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > > >> > > > >> Thanks! > > > >> BRs, > > > >> Lin > > > >> ________________________________________ > > > >> From: ?? > > > >> Sent: Tuesday, January 22, 2019 2:18:06 PM > > > >> To: Hohensee, Paul; JC Beyler > > > >> Cc: serviceability-dev at openjdk.java.net > > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Hi Paul, > > > >> Thanks a lot for your review. I have refined it based on your comments. > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > > >> Would you like to help review it again? Thanks > > > >> > > > >> BRs, > > > >> Lin > > > >> ________________________________________ > > > >> From: Hohensee, Paul > > > >> Sent: Friday, January 18, 2019 6:11:14 AM > > > >> To: ??; JC Beyler > > > >> Cc: serviceability-dev at openjdk.java.net > > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Just a few small things. > > > >> > > > >> In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > > >> > > > >> In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > > >> > > > >> In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > > >> > > > >> Thanks, > > > >> > > > >> Paul > > > >> > > > >> On 1/11/19, 1:39 AM, "??" wrote: > > > >> > > > >> Hi Jc, Paul and All, > > > >> Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > > > >> would you like to help review? > > > >> > > > >> Thanks, > > > >> Lin > > > >> ________________________________________ > > > >> From: ?? > > > >> Sent: Friday, January 11, 2019 10:25:27 AM > > > >> To: JC Beyler > > > >> Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > > > >> Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Hi Jc, > > > >> Thanks a lot. it is not a necessary change, I forget to omit it:) > > > >> > > > >> BRs, > > > >> Lin > > > >> ________________________________ > > > >> ???: JC Beyler > > > >> ????: 2019?1?11? 0:58:22 > > > >> ???: ?? > > > >> ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > > > >> ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Hi Lin, > > > >> > > > >> Small nit: > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > > >> > > > >> needs a copyright update, > > > >> Jc > > > >> > > > >> > > > >> On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > > > >> Dear All, > > > >> I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > > > >> Would you like to help review? Thanks! > > > >> > > > >> BRs, > > > >> Lin > > > >> From: ?? > > > >> Sent: Wednesday, January 9, 2019 11:00 AM > > > >> To: 'JC Beyler' > > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > > >> Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Dear JC, > > > >> Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > > >> > > > >> Cheers, > > > >> Lin > > > >> > > > >> From: JC Beyler > > > > >> Sent: Wednesday, January 9, 2019 10:51 AM > > > >> To: ?? > > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Hi Lin, > > > >> > > > >> Inlined as well :-) > > > >> > > > >> On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > > > >> Dear JC, > > > >> Thanks for your comments, I inlined my comments here: > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > > >> --- (Lin) I will do that in next webrev. > > > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > > >> --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > > >> > > > >> > > > >> No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > > >> > > > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > > >> ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > > >> > > > >> I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > > >> > > > >> Thanks! > > > >> Jc > > > >> > > > >> > > > >> All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > > >> > > > >> Cheers, > > > >> Lin > > > >> > > > >> > > > >> From: JC Beyler > > > > >> Sent: Wednesday, January 9, 2019 1:42 AM > > > >> To: ?? > > > > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> Hi Lin, > > > >> > > > >> I have a few nits: > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > > >> > > > >> You could fix the spaces arount the for loop you changed: > > > >> > > > >> + for (int i=0; i<4; i++) { > > > >> to > > > >> > > > >> + for (int i = 0; i < 4; i++) { > > > >> > > > >> > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > > >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > > >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > > >> > > > >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > > > >> + filename = opt.substring(5); > > > >> + if (filename != null) { > > > >> -> I don't see how filename can be null here > > > >> -> same filename could just be declared in the if > > > >> > > > >> > > > >> > > > >> + } else if (subopt.startsWith("file=")) { > > > >> + filename = parseFileName(subopt); > > > >> > > > >> -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > > >> > > > >> -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > > >> > > > >> > > > >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > > >> > > > >> Thanks, > > > >> Jc > > > >> > > > >> On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > > >> > > > >> Hi Paul, > > > >> I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > > > >> And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > > >> > > > >> Hi All, > > > >> May I also ask your help for reviewing this webrev? > > > >> webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > >> > > > >> Thanks! > > > >> Lin > > > >> > > > >> ________________________________ > > > >> ???: serviceability-dev > ?? ?? > > > > >> ????: 2019?1?3? 10:21 > > > >> ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > > > >> ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> > > > >> Dear Paul, > > > >> > > > >> Thanks a lot for your review! I am trying to remend the patch > > > >> > > > >> One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > > >> > > > >> so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > > >> > > > >> be more reasonable than the ?if else? ? > > > >> > > > >> Thanks > > > >> > > > >> > > > >> > > > >> BRs, > > > >> > > > >> Lin > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> From: Hohensee, Paul > > > > >> Sent: Saturday, December 29, 2018 3:54 AM > > > >> To: ?? >; serviceability-dev at openjdk.java.net > > > >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> > > > >> > > > >> Update the copyright dates to 2019 please, since this won?t get pushed until then. > > > >> > > > >> > > > >> > > > >> In JMap.java, I?d emulate dump() and use > > > >> > > > >> > > > >> > > > >> String filename = null; > > > >> > > > >> String subopts[] = options.split(","); > > > >> > > > >> > > > >> > > > >> for (String subopt : subopts){ > > > >> > > > >> if (subopt.isEmpty() || subopt.equals("all")) { > > > >> > > > >> // pass > > > >> > > > >> } else if (subopt.equals("live")) { > > > >> > > > >> liveopt = "-live"; > > > >> > > > >> } else if (subopt.startsWith("file=")) { > > > >> > > > >> // file= - check that is specified > > > >> > > > >> if (subopt.length() > 5) { > > > >> > > > >> filename = subopt.substring(5); > > > >> > > > >> } > > > >> > > > >> } else { > > > >> > > > >> usage(1); > > > >> > > > >> } > > > >> > > > >> } > > > >> > > > >> > > > >> > > > >> // get the canonical path - important to avoid just passing > > > >> > > > >> // a "heap.bin" and having the dump created in the target VM > > > >> > > > >> // working directory rather than the directory where jmap > > > >> > > > >> // is executed. > > > >> > > > >> filename = new File(filename).getCanonicalPath(); > > > >> > > > >> // inspectHeap is not the same as jcmd GC.class_histogram > > > >> > > > >> executeCommandForPid(pid, "inspectheap", filename, liveopt); > > > >> > > > >> > > > >> > > > >> I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > > >> > > > >> > > > >> > > > >> The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > > >> > > > >> > > > >> > > > >> Thanks, > > > >> > > > >> > > > >> > > > >> Paul > > > >> > > > >> > > > >> > > > >> From: serviceability-dev > on behalf of ?? > > > > >> Date: Thursday, December 20, 2018 at 11:03 PM > > > >> To: "serviceability-dev at openjdk.java.net" > > > > >> Subject: [RFR]8215622: Add dump to file support for jmap histo > > > >> > > > >> > > > >> > > > >> Hi All, > > > >> > > > >> May I ask your help to review this patch for enhance jmap ?histo. > > > >> > > > >> It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > > >> > > > >> This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > > >> > > > >> > > > >> > > > >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > > >> > > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > >> > > > >> > > > >> > > > >> Thanks. > > > >> > > > >> > > > >> > > > >> BRs, > > > >> > > > >> Lin > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> -- > > > >> > > > >> Thanks, > > > >> Jc > > > >> > > > >> > > > >> -- > > > >> > > > >> Thanks, > > > >> Jc > > > >> > > > >> > > > >> -- > > > >> > > > >> Thanks, > > > >> Jc > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > From david.holmes at oracle.com Tue Feb 5 21:59:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Feb 2019 07:59:15 +1000 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <5C597ED6.3090006@oracle.com> References: <5C5845B2.40004@oracle.com> <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> <5C597ED6.3090006@oracle.com> Message-ID: <2c8f9efb-a207-19a3-4c39-92c8d0980d8e@oracle.com> On 5/02/2019 10:17 pm, Gary Adams wrote: > On 2/4/19, 8:04 PM, David Holmes wrote: >> Hi Gary, >> >> On 5/02/2019 12:01 am, Gary Adams wrote: >>> Two of the redefine classes tests (021, 023) have been on the >>> ProblemList since they >>> were first brought into the open repos. Both tests made an incorrect >>> assumption >>> about the access modifiers in class files. There is a single bit in >>> the binary class file that >>> defines if an interface is public or not public (See JVMS Table 4.1-B >>> ACC_PUBLIC). >>> When the test classes are compiled for use in the redefine operation, >>> if a source >>> used public or protected the ACC_PUBLIC bit was set. >>> >>> Several modifiers are used in these tests to confirm >>> UnsupportedOperationException >>> is thrown or not thrown. This proposed change simply corrects the >>> expected results >>> according to the JVM Specification. >>> >>> ?? Webrev: >>> http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html >> >> test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java >> >> >> 62? * Test cases 3 (private) and 4 (static) map to not public, so will >> >> "static" is not related to access modifiers so the ACC_PUBLIC bit is >> not relevant. "static" can only be applied to (nested) member types >> and is represented by the ACC_STATIC bit as per JVMS "Table 4.7.6-A. >> Nested class access and property flags". >> >> What this testcase does is add "static" to a nested interface and >> expects JVM TI to check if the class modifier has changed. But the >> "static" is not encoded in the class "access flags", but in the inner >> class attribute (inner_class_access_flags). To me this testcase should >> throw UOE, but JVM TI is not checking the right flags. >> >> David > I think the test is demonstrating that static does not change the > ACC_PUBLIC bit. And what is that a demonstration of? static has nothing to do with access control so if it did change the ACC_PUBLIC bit we'd have a serious issue. > > This changeset does not change the handling of that testcase. The test is adding a new class modifier "static" which it originally expected to trigger a UOE but it doesn't because JVM TI is not checking for that kind of change correctly. You modified the test to no longer expect UOE so that it passes but: a) that's wrong as it shouldn't pass; and b) it's now documented as passing because it doesn't change the public-ness of the class but that's completely irrelevant. So your change to the static testcase is not correct and should not be applied. David ----- From serguei.spitsyn at oracle.com Tue Feb 5 22:44:43 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 5 Feb 2019 14:44:43 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <4c797f80a87748c5bb260ea5715be75e@jd.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> Message-ID: <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> Hi Lin, Thank you for the fix! It looks good in general. Should it come with a unit test for new flags? http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.frames.html 154 // get the canonical path - important to avoid just 155 // passing a "heap.bin" and having the dump created 156 // in the target VM working directory rather than the 157 // directory where jmap is executed. ? Minor: Comment need to start with a capital letter: // Get the ... Thanks, Serguei On 1/30/19 10:42 PM, ?? wrote: > Hi David, Paul, > I have uploaded the refined webrev at > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > May I ask your help to review? > Thanks! > > BRs, > Lin > ________________________________________ > From: David Holmes > Sent: Thursday, January 31, 2019 9:19:31 AM > To: Hohensee, Paul; ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: >> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > Yes. Changes to command-line flags need a CSR. > > Thanks, > David > >> Thanks, >> >> Paul >> >> ?On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: >> >> A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. >> >> vm.heapHisto("", "-live") >> >> Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to >> >> * 'vm.heapHisto("", "-live")' will request a full GC >> >> In attachListener.cpp, the line >> >> out->print_cr("Invalid argument to dumpheap operation: %s", arg1); >> >> should be >> >> out->print_cr("Invalid argument to inspectheap operation: %s", arg1); >> >> Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. >> >> Paul >> >> On 1/30/19, 12:18 AM, "??" wrote: >> >> Dear All, >> This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. >> I have identified the root cause of the issue. it is caused by 2 problems. >> 1. The path processing in heap_inspection() at attachListener.cpp. >> The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. >> I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. >> >> 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. >> >> I have upload a webrev05: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ >> >> May I ask your help for review? >> >> Thanks, >> Lin >> ________________________________________ >> From: ?? >> Sent: Monday, January 28, 2019 5:49:42 PM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear all, >> I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. >> Thanks! >> >> BRs, >> Lin >> ________________________________________ >> From: ?? >> Sent: Friday, January 25, 2019 9:00:19 AM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear All, >> May I get more review about this webrev? >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ >> >> Thanks! >> BRs, >> Lin >> ________________________________________ >> From: ?? >> Sent: Tuesday, January 22, 2019 2:18:06 PM >> To: Hohensee, Paul; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Paul, >> Thanks a lot for your review. I have refined it based on your comments. >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ >> Would you like to help review it again? Thanks >> >> BRs, >> Lin >> ________________________________________ >> From: Hohensee, Paul >> Sent: Friday, January 18, 2019 6:11:14 AM >> To: ??; JC Beyler >> Cc: serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Just a few small things. >> >> In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. >> >> In attachListener.cpp, line 275, change "Fail to" to "Failed to". >> >> In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. >> >> Thanks, >> >> Paul >> >> On 1/11/19, 1:39 AM, "??" wrote: >> >> Hi Jc, Paul and All, >> Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ >> would you like to help review? >> >> Thanks, >> Lin >> ________________________________________ >> From: ?? >> Sent: Friday, January 11, 2019 10:25:27 AM >> To: JC Beyler >> Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net >> Subject: ??: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Jc, >> Thanks a lot. it is not a necessary change, I forget to omit it:) >> >> BRs, >> Lin >> ________________________________ >> ???: JC Beyler >> ????: 2019?1?11? 0:58:22 >> ???: ?? >> ??: Hohensee, Paul; serviceability-dev at openjdk.java.net >> ??: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> Small nit: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html >> >> needs a copyright update, >> Jc >> >> >> On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: >> Dear All, >> I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ >> Would you like to help review? Thanks! >> >> BRs, >> Lin >> From: ?? >> Sent: Wednesday, January 9, 2019 11:00 AM >> To: 'JC Beyler' > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: RE: [RFR]8215622: Add dump to file support for jmap histo >> >> Dear JC, >> Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. >> >> Cheers, >> Lin >> >> From: JC Beyler > >> Sent: Wednesday, January 9, 2019 10:51 AM >> To: ?? > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> Inlined as well :-) >> >> On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: >> Dear JC, >> Thanks for your comments, I inlined my comments here: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? >> --- (Lin) I will do that in next webrev. >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) >> --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? >> >> >> No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? >> >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". >> ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. >> >> I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. >> >> Thanks! >> Jc >> >> >> All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. >> >> Cheers, >> Lin >> >> >> From: JC Beyler > >> Sent: Wednesday, January 9, 2019 1:42 AM >> To: ?? > >> Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> Hi Lin, >> >> I have a few nits: >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html >> >> You could fix the spaces arount the for loop you changed: >> >> + for (int i=0; i<4; i++) { >> to >> >> + for (int i = 0; i < 4; i++) { >> >> >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html >> - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? >> - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) >> >> http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html >> + filename = opt.substring(5); >> + if (filename != null) { >> -> I don't see how filename can be null here >> -> same filename could just be declared in the if >> >> >> >> + } else if (subopt.startsWith("file=")) { >> + filename = parseFileName(subopt); >> >> -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? >> >> -> in the option string printouts, you don't specify that all is an option as well, is that normal? >> >> >> The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". >> >> Thanks, >> Jc >> >> On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: >> >> Hi Paul, >> I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. >> And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ >> >> Hi All, >> May I also ask your help for reviewing this webrev? >> webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 >> >> Thanks! >> Lin >> >> ________________________________ >> ???: serviceability-dev > ?? ?? > >> ????: 2019?1?3? 10:21 >> ???: Hohensee, Paul; serviceability-dev at openjdk.java.net >> ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo >> >> >> Dear Paul, >> >> Thanks a lot for your review! I am trying to remend the patch >> >> One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. >> >> so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would >> >> be more reasonable than the ?if else? ? >> >> Thanks >> >> >> >> BRs, >> >> Lin >> >> >> >> >> >> >> >> From: Hohensee, Paul > >> Sent: Saturday, December 29, 2018 3:54 AM >> To: ?? >; serviceability-dev at openjdk.java.net >> Subject: Re: [RFR]8215622: Add dump to file support for jmap histo >> >> >> >> Update the copyright dates to 2019 please, since this won?t get pushed until then. >> >> >> >> In JMap.java, I?d emulate dump() and use >> >> >> >> String filename = null; >> >> String subopts[] = options.split(","); >> >> >> >> for (String subopt : subopts){ >> >> if (subopt.isEmpty() || subopt.equals("all")) { >> >> // pass >> >> } else if (subopt.equals("live")) { >> >> liveopt = "-live"; >> >> } else if (subopt.startsWith("file=")) { >> >> // file= - check that is specified >> >> if (subopt.length() > 5) { >> >> filename = subopt.substring(5); >> >> } >> >> } else { >> >> usage(1); >> >> } >> >> } >> >> >> >> // get the canonical path - important to avoid just passing >> >> // a "heap.bin" and having the dump created in the target VM >> >> // working directory rather than the directory where jmap >> >> // is executed. >> >> filename = new File(filename).getCanonicalPath(); >> >> // inspectHeap is not the same as jcmd GC.class_histogram >> >> executeCommandForPid(pid, "inspectheap", filename, liveopt); >> >> >> >> I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). >> >> >> >> The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. >> >> >> >> Thanks, >> >> >> >> Paul >> >> >> >> From: serviceability-dev > on behalf of ?? > >> Date: Thursday, December 20, 2018 at 11:03 PM >> To: "serviceability-dev at openjdk.java.net" > >> Subject: [RFR]8215622: Add dump to file support for jmap histo >> >> >> >> Hi All, >> >> May I ask your help to review this patch for enhance jmap ?histo. >> >> It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. >> >> This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. >> >> >> >> Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 >> >> >> >> Thanks. >> >> >> >> BRs, >> >> Lin >> >> >> >> >> >> >> >> >> -- >> >> Thanks, >> Jc >> >> >> -- >> >> Thanks, >> Jc >> >> >> -- >> >> Thanks, >> Jc >> >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Wed Feb 6 02:34:49 2019 From: jini.george at oracle.com (Jini George) Date: Wed, 6 Feb 2019 08:04:49 +0530 Subject: Is RegisterMap updated? In-Reply-To: References: <21e8d6ff-41fa-10d6-813b-4d079196d34b@redhat.com> Message-ID: Hi David, Thank you for the explanation. From Java 9, there is the 'jhsdb' tool provided with the JDK, with which you can use the SA features. So, in this case, you can run it thus to see if you can reproduce the problem: jhsdb jstack --core --exe Thanks, Jini. On 2/2/2019 2:59 PM, David Griffiths wrote: > Hi Jini, for that particular case, it just provides a simple way to > reproduce more general problems in SA: first I run a program under gdb > and with the option "-XX:CompileCommand=print,...", then I put a > breakpoint at a particular place that I suspect the stack walker code > has problems with. When the breakpoint hits, I do gcore in gdb and > then have a core file to reproduce the problem with jstack or jdb > using SACoreAttachingConnector etc. In this particular case I just > enter the jdb "locals" command. > > The more general thing that I'm doing with the SA code (not sure what > is defined as SA and what is SA-JDI but I think the classes I use are > still there in Java 9, just harder to access) and that I mentioned to > Andrew once and who probably thinks I'm nuts is to use it to > effectively debug a java application under gdb. So it's a bit like the > attaching to a live process situation using the pid (or a core file > for that matter). The nature of our application means that we can't > attach to the normal JDWP agent inside the JVM - we have to use gdb > and cannot modify the state of the running JVM. I know the code I'm > using is a bit fuzzy and imprecise - AMD64CurrentFrameGuess is a prime > example that I've had to improve - but fuzzy is actually enough most > of the time. > > Cheers, > > David > > > On Sat, 2 Feb 2019 at 02:51, Jini George wrote: >> >> Hi David, >> >> This got removed in JDK-9 as a part of SA-JDI removal. >> (https://bugs.openjdk.java.net/browse/JDK-8158050). Could you let us >> know as to why are you using SA-JDI ? >> >> Thanks, >> Jini. >> >> On 2/1/2019 9:56 PM, David Griffiths wrote: >>> Had a nice simple little reproduction test, went to try it on Java 9 >>> and... oh no, sun.jvm.hotspot.jdi.SACoreAttachingConnector has >>> disappeared! Has it gone for good? >>> >>> Cheers, >>> >>> David >>> >>> On Wed, 30 Jan 2019 at 10:38, Andrew Haley wrote: >>>> >>>> On 1/30/19 10:00 AM, David Griffiths wrote: >>>>> I'm not sure this works though for the frame at the top of the stack. >>>>> The pushing of the registers that you mention appears to take place in >>>>> the updateRegisterMap method which is called when getting the sender. >>>>> At the top of the stack the register will be live and not saved >>>>> anywhere? >>>> >>>> No the pushing of the register happens in generated code. >>>> >>>>> Whatever, I'm seeing a NPE caused by a location that has >>>>> WHERE_IN_REGISTER and a register number of 16 that doesn't have >>>>> locationValid set in the map. If I modify createStackValue to check >>>>> valueAddr being null then it avoids the NPE and getLocals then returns >>>>> all the locals except for the one held in a register (the other ones >>>>> are on the stack). Not sure what a register number of 16 equates to on >>>>> x86, is that supposed to correspond to "not set" or something? >>>> >>>> You're not helping. Are you sure you've got an up-to-date HotSpot >>>> checkout? You're not falling over bug 8217407? >>>> >>>> -- >>>> Andrew Haley >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From hohensee at amazon.com Wed Feb 6 09:23:38 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 6 Feb 2019 09:23:38 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <54bc1360-00f6-07d1-d2a3-a285563c6621@oracle.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <54bc1360-00f6-07d1-d2a3-a285563c6621@oracle.com> Message-ID: <1367B230-032B-4272-954C-5284AC4FE4EF@amazon.com> Thanks, Serguei (and David)!. I?ve put the CSR into finalized state. Paul From: serviceability-dev on behalf of "serguei.spitsyn at oracle.com" Date: Tuesday, February 5, 2019 at 9:23 AM To: "serviceability-dev at openjdk.java.net" Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Paul, I'll review the CSR. Thanks, Serguei On 2/5/19 06:02, Hohensee, Paul wrote: Looks good to me. David, who should review the CSR? Is there someone who "owns" jmap or perhaps the serviceability group lead if there is such a person? Thanks, Paul On 1/30/19, 10:43 PM, "??" wrote: Hi David, Paul, I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 May I ask your help to review? Thanks! BRs, Lin ________________________________________ From: David Holmes Sent: Thursday, January 31, 2019 9:19:31 AM To: Hohensee, Paul; ??; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo On 31/01/2019 10:41 am, Hohensee, Paul wrote: > Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? Yes. Changes to command-line flags need a CSR. Thanks, David > Thanks, > > Paul > > On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > vm.heapHisto("", "-live") > > Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > * 'vm.heapHisto("", "-live")' will request a full GC > > In attachListener.cpp, the line > > out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > should be > > out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > Paul > > On 1/30/19, 12:18 AM, "??" wrote: > > Dear All, > This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > I have identified the root cause of the issue. it is caused by 2 problems. > 1. The path processing in heap_inspection() at attachListener.cpp. > The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > I have upload a webrev05: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > May I ask your help for review? > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Monday, January 28, 2019 5:49:42 PM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Dear all, > I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > Thanks! > > BRs, > Lin > ________________________________________ > From: ?? > Sent: Friday, January 25, 2019 9:00:19 AM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Dear All, > May I get more review about this webrev? > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > Thanks! > BRs, > Lin > ________________________________________ > From: ?? > Sent: Tuesday, January 22, 2019 2:18:06 PM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Paul, > Thanks a lot for your review. I have refined it based on your comments. > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > Would you like to help review it again? Thanks > > BRs, > Lin > ________________________________________ > From: Hohensee, Paul > Sent: Friday, January 18, 2019 6:11:14 AM > To: ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Just a few small things. > > In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > Thanks, > > Paul > > On 1/11/19, 1:39 AM, "??" wrote: > > Hi Jc, Paul and All, > Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > would you like to help review? > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Friday, January 11, 2019 10:25:27 AM > To: JC Beyler > Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > Hi Jc, > Thanks a lot. it is not a necessary change, I forget to omit it:) > > BRs, > Lin > ________________________________ > ???: JC Beyler > ????: 2019?1?11? 0:58:22 > ???: ?? > ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Small nit: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > needs a copyright update, > Jc > > > On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > Dear All, > I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > Would you like to help review? Thanks! > > BRs, > Lin > From: ?? > Sent: Wednesday, January 9, 2019 11:00 AM > To: 'JC Beyler' > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > Dear JC, > Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > Cheers, > Lin > > From: JC Beyler > > Sent: Wednesday, January 9, 2019 10:51 AM > To: ?? > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Inlined as well :-) > > On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > Dear JC, > Thanks for your comments, I inlined my comments here: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > --- (Lin) I will do that in next webrev. > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > > No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > Thanks! > Jc > > > All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > Cheers, > Lin > > > From: JC Beyler > > Sent: Wednesday, January 9, 2019 1:42 AM > To: ?? > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > I have a few nits: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > You could fix the spaces arount the for loop you changed: > > + for (int i=0; i<4; i++) { > to > > + for (int i = 0; i < 4; i++) { > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > + filename = opt.substring(5); > + if (filename != null) { > -> I don't see how filename can be null here > -> same filename could just be declared in the if > > > > + } else if (subopt.startsWith("file=")) { > + filename = parseFileName(subopt); > > -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > Thanks, > Jc > > On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > Hi Paul, > I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > Hi All, > May I also ask your help for reviewing this webrev? > webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > Thanks! > Lin > > ________________________________ > ???: serviceability-dev > ?? ?? > > ????: 2019?1?3? 10:21 > ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > > Dear Paul, > > Thanks a lot for your review! I am trying to remend the patch > > One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > be more reasonable than the ?if else? ? > > Thanks > > > > BRs, > > Lin > > > > > > > > From: Hohensee, Paul > > Sent: Saturday, December 29, 2018 3:54 AM > To: ?? >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Update the copyright dates to 2019 please, since this won?t get pushed until then. > > > > In JMap.java, I?d emulate dump() and use > > > > String filename = null; > > String subopts[] = options.split(","); > > > > for (String subopt : subopts){ > > if (subopt.isEmpty() || subopt.equals("all")) { > > // pass > > } else if (subopt.equals("live")) { > > liveopt = "-live"; > > } else if (subopt.startsWith("file=")) { > > // file= - check that is specified > > if (subopt.length() > 5) { > > filename = subopt.substring(5); > > } > > } else { > > usage(1); > > } > > } > > > > // get the canonical path - important to avoid just passing > > // a "heap.bin" and having the dump created in the target VM > > // working directory rather than the directory where jmap > > // is executed. > > filename = new File(filename).getCanonicalPath(); > > // inspectHeap is not the same as jcmd GC.class_histogram > > executeCommandForPid(pid, "inspectheap", filename, liveopt); > > > > I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > > > The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > > > Thanks, > > > > Paul > > > > From: serviceability-dev > on behalf of ?? > > Date: Thursday, December 20, 2018 at 11:03 PM > To: "serviceability-dev at openjdk.java.net" > > Subject: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi All, > > May I ask your help to review this patch for enhance jmap ?histo. > > It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > > Thanks. > > > > BRs, > > Lin > > > > > > > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Wed Feb 6 10:00:16 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Feb 2019 10:00:16 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> Message-ID: On 2/5/19 5:57 PM, Andrew Haley wrote: > On 2/5/19 5:55 PM, Nick Gasson (Arm Technology China) wrote: >> The stack trace you sent below is incomplete, it's missing the frame for Spinner.run (i.e. the AARCH64Frame object corresponding to the native wrapper frame). Did you try on x86 or with the patch I posted? I'm not able to test at the moment but I think you will get one exra frame in the output. I don't know why you don't get the NPE, I guess it depends on what's in that stack slot. > > Never mind, found it. A more complex test is needed. Here's the test that reveals the problem: it seems that you need an entry frame which calls compiled Java code. [aph at merino ~]$ cat Spinner.c #include #include /* * Class: Spinner * Method: run * Signature: ()V */ JNIEXPORT void JNICALL Java_Spinner_run(JNIEnv *env, jclass cls) { jmethodID mid = (*env)->GetStaticMethodID(env, cls, "test", "()V"); (*env)->CallStaticVoidMethod(env, cls, mid); // printf("Spinning...\n"); // for(;;); } [aph at merino ~]$ cat Spinner.java public class Spinner { static native void run(); static { System.loadLibrary("Spinner"); } static volatile int nn; public static void test() { System.out.println("Spinning"); for(int i = 1; i !=0; i = (i + 1) | 1) nn = (int)Math.log(i); } public static void main(String[] args) { run(); } } -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Nick.Gasson at arm.com Wed Feb 6 10:54:38 2019 From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China)) Date: Wed, 6 Feb 2019 10:54:38 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com>, Message-ID: Hi Andrew > Here's the test that reveals the problem: it seems that you need an entry frame which calls compiled Java code. This seems slightly different to the original problem, although maybe related. Because here the top-most frame is a compiled Java frame we'll take the vm.isJavaPCDbg and !vm.isClientCompiler branches of AARCH64CurrentFrameGuess::run which as far as I can tell always gets the PC from the thread context. The original crash I was looking at happened when the top frame was native (else branch on line 183) where the PC is set to null which causes the two-argument AARCH64Frame constructor to be used. Unfortunately I'm on holiday until next Thursday so can't test anything. Did you try Thread.sleep? That's what LingeredApp that the jtreg tests is trying to get a stack trace of calls. Thanks, Nick ________________________________ From: Andrew Haley Sent: 06 February 2019 18:00:16 To: Nick Gasson (Arm Technology China); serviceability-dev at openjdk.java.net Cc: nd; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command On 2/5/19 5:57 PM, Andrew Haley wrote: > On 2/5/19 5:55 PM, Nick Gasson (Arm Technology China) wrote: >> The stack trace you sent below is incomplete, it's missing the frame for Spinner.run (i.e. the AARCH64Frame object corresponding to the native wrapper frame). Did you try on x86 or with the patch I posted? I'm not able to test at the moment but I think you will get one exra frame in the output. I don't know why you don't get the NPE, I guess it depends on what's in that stack slot. > > Never mind, found it. A more complex test is needed. Here's the test that reveals the problem: it seems that you need an entry frame which calls compiled Java code. [aph at merino ~]$ cat Spinner.c #include #include /* * Class: Spinner * Method: run * Signature: ()V */ JNIEXPORT void JNICALL Java_Spinner_run(JNIEnv *env, jclass cls) { jmethodID mid = (*env)->GetStaticMethodID(env, cls, "test", "()V"); (*env)->CallStaticVoidMethod(env, cls, mid); // printf("Spinning...\n"); // for(;;); } [aph at merino ~]$ cat Spinner.java public class Spinner { static native void run(); static { System.loadLibrary("Spinner"); } static volatile int nn; public static void test() { System.out.println("Spinning"); for(int i = 1; i !=0; i = (i + 1) | 1) nn = (int)Math.log(i); } public static void main(String[] args) { run(); } } -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Wed Feb 6 13:14:11 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 06 Feb 2019 08:14:11 -0500 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> References: <5C548928.5010304@oracle.com> <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> Message-ID: <5C5ADDA3.5070309@oracle.com> Just a quick update on the failure on shutdown ... I've come across a couple of other tests with a similar failure mode. I'm attempting to get some additional diagnostic information from these tests with "-jdi.trace=all", but the diagnostic output may be interfering with the timing. My current investigation is around a possible race condition in the Debgugee.quit() processing. - the "quit" string is sent to the deuggee via the IOpipe - the vm.dispose() is handled from the JDWP communication If the context switching is not quick enough, the debugee may not have read and processed the "quit" command before tear down is handled. From earlier comments in the bug report the debuggee was observed still at the breakpoint, so the resume and the disabling of the breakpoint had not been processed, yet. It might be worth having an "ack" returned when the "quit" is processed in the debugee. ... On 2/1/19, 2:15 PM, serguei.spitsyn at oracle.com wrote: > Hi Gary, > > The debugee.quit() is to complete the session. > It makes this call: sendSignal(SGNL_QUIT); > > A call to the debugee.quit() is at the end of execTest() method: > > display(""); > } > > display(""); > display("============="); > display("TEST FINISHES\n"); > > brkpReq.disable(); > debugee.resume(); > debugee.quit(); > } > > Thanks, > Serguei > > > On 2/1/19 10:00, Gary Adams wrote: >> When the remove_l005 runs to completion, it never signals the debuggee >> that all iterations have completed. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 >> >> 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 >> @@ -163,7 +163,6 @@ >> vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >> 8066993 generic-all >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >> 8065773 generic-all >> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >> 8065773 generic-all >> -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java >> 8068225 generic-all >> >> vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >> generic-all >> vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >> generic-all >> >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >> >> --- >> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >> +++ >> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -134,6 +134,7 @@ >> } >> display(""); >> } >> + debugee.sendSignal(SGNL_QUIT); >> >> display(""); >> display("============="); > From shade at redhat.com Wed Feb 6 14:23:53 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Feb 2019 15:23:53 +0100 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549230180.31327.172.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> Message-ID: <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> On 2/3/19 10:43 PM, zgu at redhat.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ Looks fine code-wise. *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why this whole thing is removed? I would expect "just" the rename of slow_refill_waste() to refill_waste() and removing fast_refill_waste() here, leaving everything else untouched. 105 // statistics 106 107 int number_of_refills() const { return _number_of_refills; } 108 int fast_refill_waste() const { return _fast_refill_waste; } 109 int slow_refill_waste() const { return _slow_refill_waste; } 110 int gc_waste() const { return _gc_waste; } 111 int slow_allocations() const { return _slow_allocations; } 112 Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Wed Feb 6 14:34:11 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 06 Feb 2019 09:34:11 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> Message-ID: <1549463651.31327.188.camel@redhat.com> Thanks, Aleksey. On Wed, 2019-02-06 at 15:23 +0100, Aleksey Shipilev wrote: > On 2/3/19 10:43 PM, zgu at redhat.com wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212127 > > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.00/ > > Looks fine code-wise. > > *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why > this whole thing is removed? I > would expect "just" the rename of slow_refill_waste() to > refill_waste() and removing > fast_refill_waste() here, leaving everything else untouched. > > 105 // statistics > 106 > 107 int number_of_refills() const { return _number_of_refills; } > 108 int fast_refill_waste() const { return _fast_refill_waste; } > 109 int slow_refill_waste() const { return _slow_refill_waste; } > 110 int gc_waste() const { return _gc_waste; } > 111 int slow_allocations() const { return _slow_allocations; } > 112 They are dead code. Do they worth for another cleanup RFE for the trivial cleanup? -Zhengyu > > > Thanks, > -Aleksey > From shade at redhat.com Wed Feb 6 14:48:27 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 Feb 2019 15:48:27 +0100 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549463651.31327.188.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> Message-ID: <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> On 2/6/19 3:34 PM, zgu at redhat.com wrote: >> *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why >> this whole thing is removed? I >> would expect "just" the rename of slow_refill_waste() to >> refill_waste() and removing >> fast_refill_waste() here, leaving everything else untouched. >> >> 105 // statistics >> 106 >> 107 int number_of_refills() const { return _number_of_refills; } >> 108 int fast_refill_waste() const { return _fast_refill_waste; } >> 109 int slow_refill_waste() const { return _slow_refill_waste; } >> 110 int gc_waste() const { return _gc_waste; } >> 111 int slow_allocations() const { return _slow_allocations; } >> 112 > > They are dead code. Do they worth for another cleanup RFE for the > trivial cleanup? Okay. I thought the patch was about fast refills only. But indeed, we can clean these unused definitions in the same patch. On one hand, removing trivial unused getters would require us to add them back when they are needed. On the other hand, it seems that TLAB does every statistic internally, and we should instead force callers to use higher-level TLAB methods to access and interpret them. Code looks good! I think we still need Serviceability to acknowledge this is okay to do. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From zgu at redhat.com Wed Feb 6 15:01:52 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 06 Feb 2019 10:01:52 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> Message-ID: <1549465312.31327.196.camel@redhat.com> On Wed, 2019-02-06 at 15:48 +0100, Aleksey Shipilev wrote: > On 2/6/19 3:34 PM, zgu at redhat.com wrote: > > > *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why > > > this whole thing is removed? I > > > would expect "just" the rename of slow_refill_waste() to > > > refill_waste() and removing > > > fast_refill_waste() here, leaving everything else untouched. > > > > > > 105 // statistics > > > 106 > > > 107 int number_of_refills() const { return _number_of_refills; > > > } > > > 108 int fast_refill_waste() const { return _fast_refill_waste; > > > } > > > 109 int slow_refill_waste() const { return _slow_refill_waste; > > > } > > > 110 int gc_waste() const { return _gc_waste; } > > > 111 int slow_allocations() const { return _slow_allocations; > > > } > > > 112 > > > > They are dead code. Do they worth for another cleanup RFE for the > > trivial cleanup? > > Okay. I thought the patch was about fast refills only. But indeed, we > can clean these unused > definitions in the same patch. On one hand, removing trivial unused > getters would require us to add > them back when they are needed. On the other hand, it seems that TLAB > does every statistic > internally, and we should instead force callers to use higher-level > TLAB methods to access and > interpret them. > > Code looks good! I think we still need Serviceability to acknowledge > this is okay to do. Serguei okayed. Serguei, does it still okay with you? Thanks, -Zhengyu > > -Aleksey > > > > > > > From gary.adams at oracle.com Wed Feb 6 16:04:43 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 06 Feb 2019 11:04:43 -0500 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: <5C5ADDA3.5070309@oracle.com> References: <5C548928.5010304@oracle.com> <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> <5C5ADDA3.5070309@oracle.com> Message-ID: <5C5B059B.20906@oracle.com> Testing an alternate fix that will wait for the debugee process to terminate after processing the "quit" command before doing the vm tear down. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -557,6 +557,7 @@ * exit status code. */ public int endDebugee() { + int status = waitFor(); if (vm != null) { try { vm.dispose(); @@ -564,7 +565,7 @@ } vm = null; } - return waitFor(); + return status; } On 2/6/19, 8:14 AM, Gary Adams wrote: > Just a quick update on the failure on shutdown ... > I've come across a couple of other tests with a similar failure mode. > > I'm attempting to get some additional diagnostic information from these > tests with "-jdi.trace=all", but the diagnostic output may be interfering > with the timing. > > My current investigation is around a possible race condition > in the Debgugee.quit() processing. > - the "quit" string is sent to the deuggee via the IOpipe > - the vm.dispose() is handled from the JDWP communication > > If the context switching is not quick enough, the debugee > may not have read and processed the "quit" command before > tear down is handled. > > From earlier comments in the bug report the debuggee was observed > still at the breakpoint, so the resume and the disabling of the > breakpoint > had not been processed, yet. > > It might be worth having an "ack" returned when the "quit" is > processed in the debugee. > > ... > > On 2/1/19, 2:15 PM, serguei.spitsyn at oracle.com wrote: >> Hi Gary, >> >> The debugee.quit() is to complete the session. >> It makes this call: sendSignal(SGNL_QUIT); >> >> A call to the debugee.quit() is at the end of execTest() method: >> >> display(""); >> } >> >> display(""); >> display("============="); >> display("TEST FINISHES\n"); >> >> brkpReq.disable(); >> debugee.resume(); >> debugee.quit(); >> } >> >> Thanks, >> Serguei >> >> >> On 2/1/19 10:00, Gary Adams wrote: >>> When the remove_l005 runs to completion, it never signals the debuggee >>> that all iterations have completed. >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 >>> >>> 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 >>> @@ -163,7 +163,6 @@ >>> vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >>> 8066993 generic-all >>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>> 8065773 generic-all >>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>> 8065773 generic-all >>> -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java >>> 8068225 generic-all >>> >>> vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >>> generic-all >>> vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >>> generic-all >>> >>> >>> diff --git >>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>> >>> --- >>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>> +++ >>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>> @@ -1,5 +1,5 @@ >>> /* >>> - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >>> rights reserved. >>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> * >>> * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -134,6 +134,7 @@ >>> } >>> display(""); >>> } >>> + debugee.sendSignal(SGNL_QUIT); >>> >>> display(""); >>> display("============="); >> > From chris.plummer at oracle.com Wed Feb 6 17:15:08 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Feb 2019 09:15:08 -0800 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: <5C5B059B.20906@oracle.com> References: <5C548928.5010304@oracle.com> <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> <5C5ADDA3.5070309@oracle.com> <5C5B059B.20906@oracle.com> Message-ID: <38b11652-fc40-0178-06ef-ff361236a1d7@oracle.com> What happens if endDebugee() is called when the caller is not expecting a clean exit of the debugeee? Won't waitFor() wait forever in that case? I think by having the vm.dispose() first, you avoid that issue. Chris On 2/6/19 8:04 AM, Gary Adams wrote: > Testing an alternate fix that will wait for the debugee process to > terminate after processing the "quit" > command before doing the vm tear down. > > > diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java > b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java > --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java > +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -557,6 +557,7 @@ > ????? * exit status code. > ????? */ > ???? public int endDebugee() { > +??????? int status = waitFor(); > ???????? if (vm != null) { > ???????????? try { > ???????????????? vm.dispose(); > @@ -564,7 +565,7 @@ > ???????????? } > ???????????? vm = null; > ???????? } > -??????? return waitFor(); > +??????? return status; > ???? } > > > On 2/6/19, 8:14 AM, Gary Adams wrote: >> Just a quick update on the failure on shutdown ... >> I've come across a couple of other tests with a similar failure mode. >> >> I'm attempting to get some additional diagnostic information from these >> tests with "-jdi.trace=all", but the diagnostic output may be >> interfering >> with the timing. >> >> My current investigation is around a possible race condition >> in the Debgugee.quit() processing. >> ?? - the "quit" string is sent to the deuggee via the IOpipe >> ?? - the vm.dispose() is handled from the JDWP communication >> >> If the context switching is not quick enough, the debugee >> may not have read and processed the "quit" command before >> tear down is handled. >> >> From earlier comments in the bug report the debuggee was observed >> still at the breakpoint, so the resume and the disabling of the >> breakpoint >> had not been processed, yet. >> >> It might be worth having an "ack" returned when the "quit" is >> processed in the debugee. >> >> ... >> >> On 2/1/19, 2:15 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Gary, >>> >>> The debugee.quit() is to complete the session. >>> It makes this call: sendSignal(SGNL_QUIT); >>> >>> A call to the debugee.quit() is at the end of execTest() method: >>> >>> ??????????? display(""); >>> ??????? } >>> >>> ??????? display(""); >>> ??????? display("============="); >>> ??????? display("TEST FINISHES\n"); >>> >>> ??????? brkpReq.disable(); >>> ??????? debugee.resume(); >>> ??????? debugee.quit(); >>> ??? } >>> >>> Thanks, >>> Serguei >>> >>> >>> On 2/1/19 10:00, Gary Adams wrote: >>>> When the remove_l005 runs to completion, it never signals the debuggee >>>> that all iterations have completed. >>>> >>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 >>>> >>>> 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 >>>> @@ -163,7 +163,6 @@ >>>> ?vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >>>> 8066993 generic-all >>>> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>>> 8065773 generic-all >>>> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>>> 8065773 generic-all >>>> -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java >>>> 8068225 generic-all >>>> >>>> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >>>> generic-all >>>> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >>>> generic-all >>>> >>>> >>>> diff --git >>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>> >>>> --- >>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>> +++ >>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>> @@ -1,5 +1,5 @@ >>>> ?/* >>>> - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >>>> rights reserved. >>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> ? * >>>> ? * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -134,6 +134,7 @@ >>>> ???????????? } >>>> ???????????? display(""); >>>> ???????? } >>>> +??????? debugee.sendSignal(SGNL_QUIT); >>>> >>>> ???????? display(""); >>>> ???????? display("============="); >>> >> > From gary.adams at oracle.com Wed Feb 6 18:01:43 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 06 Feb 2019 13:01:43 -0500 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: <38b11652-fc40-0178-06ef-ff361236a1d7@oracle.com> References: <5C548928.5010304@oracle.com> <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> <5C5ADDA3.5070309@oracle.com> <5C5B059B.20906@oracle.com> <38b11652-fc40-0178-06ef-ff361236a1d7@oracle.com> Message-ID: <5C5B2107.5020905@oracle.com> So far the only test that has an issue with the change in waitFor order is nsk/jdi/VirtualMachine/canBeModified, which does not appear to synchronize with the debuggee. On 2/6/19, 12:15 PM, Chris Plummer wrote: > What happens if endDebugee() is called when the caller is not > expecting a clean exit of the debugeee? Won't waitFor() wait forever > in that case? I think by having the vm.dispose() first, you avoid that > issue. > > Chris > > On 2/6/19 8:04 AM, Gary Adams wrote: >> Testing an alternate fix that will wait for the debugee process to >> terminate after processing the "quit" >> command before doing the vm tear down. >> >> >> diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -557,6 +557,7 @@ >> * exit status code. >> */ >> public int endDebugee() { >> + int status = waitFor(); >> if (vm != null) { >> try { >> vm.dispose(); >> @@ -564,7 +565,7 @@ >> } >> vm = null; >> } >> - return waitFor(); >> + return status; >> } >> >> >> On 2/6/19, 8:14 AM, Gary Adams wrote: >>> Just a quick update on the failure on shutdown ... >>> I've come across a couple of other tests with a similar failure mode. >>> >>> I'm attempting to get some additional diagnostic information from these >>> tests with "-jdi.trace=all", but the diagnostic output may be >>> interfering >>> with the timing. >>> >>> My current investigation is around a possible race condition >>> in the Debgugee.quit() processing. >>> - the "quit" string is sent to the deuggee via the IOpipe >>> - the vm.dispose() is handled from the JDWP communication >>> >>> If the context switching is not quick enough, the debugee >>> may not have read and processed the "quit" command before >>> tear down is handled. >>> >>> From earlier comments in the bug report the debuggee was observed >>> still at the breakpoint, so the resume and the disabling of the >>> breakpoint >>> had not been processed, yet. >>> >>> It might be worth having an "ack" returned when the "quit" is >>> processed in the debugee. >>> >>> ... >>> >>> On 2/1/19, 2:15 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Gary, >>>> >>>> The debugee.quit() is to complete the session. >>>> It makes this call: sendSignal(SGNL_QUIT); >>>> >>>> A call to the debugee.quit() is at the end of execTest() method: >>>> >>>> display(""); >>>> } >>>> >>>> display(""); >>>> display("============="); >>>> display("TEST FINISHES\n"); >>>> >>>> brkpReq.disable(); >>>> debugee.resume(); >>>> debugee.quit(); >>>> } >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 2/1/19 10:00, Gary Adams wrote: >>>>> When the remove_l005 runs to completion, it never signals the >>>>> debuggee >>>>> that all iterations have completed. >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 >>>>> >>>>> 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 >>>>> @@ -163,7 +163,6 @@ >>>>> vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >>>>> 8066993 generic-all >>>>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>>>> 8065773 generic-all >>>>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>>>> 8065773 generic-all >>>>> -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java >>>>> 8068225 generic-all >>>>> >>>>> vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >>>>> generic-all >>>>> vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >>>>> generic-all >>>>> >>>>> >>>>> diff --git >>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>> >>>>> --- >>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>> +++ >>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>> @@ -1,5 +1,5 @@ >>>>> /* >>>>> - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> * >>>>> * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> @@ -134,6 +134,7 @@ >>>>> } >>>>> display(""); >>>>> } >>>>> + debugee.sendSignal(SGNL_QUIT); >>>>> >>>>> display(""); >>>>> display("============="); >>>> >>> >> > > From chris.plummer at oracle.com Wed Feb 6 18:16:24 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Feb 2019 10:16:24 -0800 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: <5C5B2107.5020905@oracle.com> References: <5C548928.5010304@oracle.com> <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> <5C5ADDA3.5070309@oracle.com> <5C5B059B.20906@oracle.com> <38b11652-fc40-0178-06ef-ff361236a1d7@oracle.com> <5C5B2107.5020905@oracle.com> Message-ID: Does it timeout in waitFor()? Chris On 2/6/19 10:01 AM, Gary Adams wrote: > So far the only test that has an issue with the change in waitFor > order is > nsk/jdi/VirtualMachine/canBeModified, which does not appear to > synchronize > with the debuggee. > > On 2/6/19, 12:15 PM, Chris Plummer wrote: >> What happens if endDebugee() is called when the caller is not >> expecting a clean exit of the debugeee? Won't waitFor() wait forever >> in that case? I think by having the vm.dispose() first, you avoid >> that issue. >> >> Chris >> >> On 2/6/19 8:04 AM, Gary Adams wrote: >>> Testing an alternate fix that will wait for the debugee process to >>> terminate after processing the "quit" >>> command before doing the vm tear down. >>> >>> >>> diff --git >>> a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>> @@ -1,5 +1,5 @@ >>> ?/* >>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All >>> rights reserved. >>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> ? * >>> ? * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -557,6 +557,7 @@ >>> ????? * exit status code. >>> ????? */ >>> ???? public int endDebugee() { >>> +??????? int status = waitFor(); >>> ???????? if (vm != null) { >>> ???????????? try { >>> ???????????????? vm.dispose(); >>> @@ -564,7 +565,7 @@ >>> ???????????? } >>> ???????????? vm = null; >>> ???????? } >>> -??????? return waitFor(); >>> +??????? return status; >>> ???? } >>> >>> >>> On 2/6/19, 8:14 AM, Gary Adams wrote: >>>> Just a quick update on the failure on shutdown ... >>>> I've come across a couple of other tests with a similar failure mode. >>>> >>>> I'm attempting to get some additional diagnostic information from >>>> these >>>> tests with "-jdi.trace=all", but the diagnostic output may be >>>> interfering >>>> with the timing. >>>> >>>> My current investigation is around a possible race condition >>>> in the Debgugee.quit() processing. >>>> ?? - the "quit" string is sent to the deuggee via the IOpipe >>>> ?? - the vm.dispose() is handled from the JDWP communication >>>> >>>> If the context switching is not quick enough, the debugee >>>> may not have read and processed the "quit" command before >>>> tear down is handled. >>>> >>>> From earlier comments in the bug report the debuggee was observed >>>> still at the breakpoint, so the resume and the disabling of the >>>> breakpoint >>>> had not been processed, yet. >>>> >>>> It might be worth having an "ack" returned when the "quit" is >>>> processed in the debugee. >>>> >>>> ... >>>> >>>> On 2/1/19, 2:15 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Gary, >>>>> >>>>> The debugee.quit() is to complete the session. >>>>> It makes this call: sendSignal(SGNL_QUIT); >>>>> >>>>> A call to the debugee.quit() is at the end of execTest() method: >>>>> >>>>> ??????????? display(""); >>>>> ??????? } >>>>> >>>>> ??????? display(""); >>>>> ??????? display("============="); >>>>> ??????? display("TEST FINISHES\n"); >>>>> >>>>> ??????? brkpReq.disable(); >>>>> ??????? debugee.resume(); >>>>> ??????? debugee.quit(); >>>>> ??? } >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 2/1/19 10:00, Gary Adams wrote: >>>>>> When the remove_l005 runs to completion, it never signals the >>>>>> debuggee >>>>>> that all iterations have completed. >>>>>> >>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 >>>>>> >>>>>> 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 >>>>>> @@ -163,7 +163,6 @@ >>>>>> ?vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >>>>>> 8066993 generic-all >>>>>> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>>>>> 8065773 generic-all >>>>>> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>>>>> 8065773 generic-all >>>>>> -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java >>>>>> 8068225 generic-all >>>>>> >>>>>> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 >>>>>> generic-all >>>>>> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 >>>>>> generic-all >>>>>> >>>>>> >>>>>> diff --git >>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>> >>>>>> --- >>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>> +++ >>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>> @@ -1,5 +1,5 @@ >>>>>> ?/* >>>>>> - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All >>>>>> rights reserved. >>>>>> + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >>>>>> rights reserved. >>>>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>> ? * >>>>>> ? * This code is free software; you can redistribute it and/or >>>>>> modify it >>>>>> @@ -134,6 +134,7 @@ >>>>>> ???????????? } >>>>>> ???????????? display(""); >>>>>> ???????? } >>>>>> +??????? debugee.sendSignal(SGNL_QUIT); >>>>>> >>>>>> ???????? display(""); >>>>>> ???????? display("============="); >>>>> >>>> >>> >> >> > From aph at redhat.com Wed Feb 6 18:42:29 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 Feb 2019 18:42:29 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> Message-ID: On 2/6/19 10:54 AM, Nick Gasson (Arm Technology China) wrote: > Hi Andrew > >> Here's the test that reveals the problem: it seems that you need an entry frame which calls compiled Java code. > > This seems slightly different to the original problem, although > maybe related. Because here the top-most frame is a compiled Java > frame we'll take the vm.isJavaPCDbg and !vm.isClientCompiler > branches of AARCH64CurrentFrameGuess::run which as far as I can tell > always gets the PC from the thread context. The original crash I was > looking at happened when the top frame was native (else branch on > line 183) where the PC is set to null which causes the two-argument > AARCH64Frame constructor to be used. OK. > Unfortunately I'm on holiday until next Thursday so can't test > anything. Did you try Thread.sleep? That's what LingeredApp that the > jtreg tests is trying to get a stack trace of calls. Well, that was fun. When generally assume that we can find a saved PC in a fixed place in the frame, and this is always the word above the FP. However, when we're in JNI native code, as you've noticed the C[++] compiler isn't helpful enough to lave the caller PC in a well-known place. When the frame is created by our AArch64 assembly- langage code we'll be fine because we always do the right thing. The problem is that when we save the Java frame state in the Thread, we're doing it for the sake of the runtime, not for debuggers, so we don't always save all the information that a debugger might need. This patch should work for compiled native methods, but I'm not at all sure about all of the other places where we call out from runtime stubs to the VM. We perhaps check that the PC returned by raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()) is in the code cache before we use it. Anyway, try this: it should fix your immediate bug. diff -r 3954d70e1c50 src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp --- a/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp Wed Feb 06 08:31:27 2019 +0100 +++ b/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp Wed Feb 06 18:22:09 2019 +0000 @@ -1916,10 +1916,20 @@ default: ShouldNotReachHere(); } + + // Leave a breadcrumb for + // sun.jvm.hotspot.runtime.aarch64.AARCH64Frame(sp, fp) + Label retaddr; + __ adr(rscratch2, retaddr); + __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); + rt_call(masm, native_func, int_args + 2, // AArch64 passes up to 8 args in int registers float_args, // and up to 8 float args return_type); + + __ bind(retaddr); + __ add(sp, sp, 2 * wordSize); } // Unpack native results. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gary.adams at oracle.com Wed Feb 6 19:02:51 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 06 Feb 2019 14:02:51 -0500 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: References: <5C548928.5010304@oracle.com> <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> <5C5ADDA3.5070309@oracle.com> <5C5B059B.20906@oracle.com> <38b11652-fc40-0178-06ef-ff361236a1d7@oracle.com> <5C5B2107.5020905@oracle.com> Message-ID: <5C5B2F5B.2000304@oracle.com> Yes, the test was hung in waitFor. The debugger process made some calls after the VMStart event was observed, but never resumed the debuggee. Here's a simple change that makes test run to completion cleanly. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -78,6 +78,7 @@ exitStatus = Consts.TEST_FAILED; e.printStackTrace(); } finally { + debugee.resume(); debugee.endDebugee(); } display("Test finished. exitStatus = " + exitStatus); On 2/6/19, 1:16 PM, Chris Plummer wrote: > Does it timeout in waitFor()? > > Chris > > On 2/6/19 10:01 AM, Gary Adams wrote: >> So far the only test that has an issue with the change in waitFor >> order is >> nsk/jdi/VirtualMachine/canBeModified, which does not appear to >> synchronize >> with the debuggee. >> >> On 2/6/19, 12:15 PM, Chris Plummer wrote: >>> What happens if endDebugee() is called when the caller is not >>> expecting a clean exit of the debugeee? Won't waitFor() wait forever >>> in that case? I think by having the vm.dispose() first, you avoid >>> that issue. >>> >>> Chris >>> >>> On 2/6/19 8:04 AM, Gary Adams wrote: >>>> Testing an alternate fix that will wait for the debugee process to >>>> terminate after processing the "quit" >>>> command before doing the vm tear down. >>>> >>>> >>>> diff --git >>>> a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -557,6 +557,7 @@ >>>> * exit status code. >>>> */ >>>> public int endDebugee() { >>>> + int status = waitFor(); >>>> if (vm != null) { >>>> try { >>>> vm.dispose(); >>>> @@ -564,7 +565,7 @@ >>>> } >>>> vm = null; >>>> } >>>> - return waitFor(); >>>> + return status; >>>> } >>>> >>>> >>>> On 2/6/19, 8:14 AM, Gary Adams wrote: >>>>> Just a quick update on the failure on shutdown ... >>>>> I've come across a couple of other tests with a similar failure mode. >>>>> >>>>> I'm attempting to get some additional diagnostic information from >>>>> these >>>>> tests with "-jdi.trace=all", but the diagnostic output may be >>>>> interfering >>>>> with the timing. >>>>> >>>>> My current investigation is around a possible race condition >>>>> in the Debgugee.quit() processing. >>>>> - the "quit" string is sent to the deuggee via the IOpipe >>>>> - the vm.dispose() is handled from the JDWP communication >>>>> >>>>> If the context switching is not quick enough, the debugee >>>>> may not have read and processed the "quit" command before >>>>> tear down is handled. >>>>> >>>>> From earlier comments in the bug report the debuggee was observed >>>>> still at the breakpoint, so the resume and the disabling of the >>>>> breakpoint >>>>> had not been processed, yet. >>>>> >>>>> It might be worth having an "ack" returned when the "quit" is >>>>> processed in the debugee. >>>>> >>>>> ... >>>>> >>>>> On 2/1/19, 2:15 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Gary, >>>>>> >>>>>> The debugee.quit() is to complete the session. >>>>>> It makes this call: sendSignal(SGNL_QUIT); >>>>>> >>>>>> A call to the debugee.quit() is at the end of execTest() method: >>>>>> >>>>>> display(""); >>>>>> } >>>>>> >>>>>> display(""); >>>>>> display("============="); >>>>>> display("TEST FINISHES\n"); >>>>>> >>>>>> brkpReq.disable(); >>>>>> debugee.resume(); >>>>>> debugee.quit(); >>>>>> } >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 2/1/19 10:00, Gary Adams wrote: >>>>>>> When the remove_l005 runs to completion, it never signals the >>>>>>> debuggee >>>>>>> that all iterations have completed. >>>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 >>>>>>> >>>>>>> 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 >>>>>>> @@ -163,7 +163,6 @@ >>>>>>> vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >>>>>>> 8066993 generic-all >>>>>>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>>>>>> 8065773 generic-all >>>>>>> vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>>>>>> 8065773 generic-all >>>>>>> -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java >>>>>>> 8068225 generic-all >>>>>>> >>>>>>> vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java >>>>>>> 8208250 generic-all >>>>>>> vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java >>>>>>> 8208250 generic-all >>>>>>> >>>>>>> >>>>>>> diff --git >>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>>> >>>>>>> --- >>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>>> +++ >>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> /* >>>>>>> - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All >>>>>>> rights reserved. >>>>>>> + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >>>>>>> rights reserved. >>>>>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>> * >>>>>>> * This code is free software; you can redistribute it and/or >>>>>>> modify it >>>>>>> @@ -134,6 +134,7 @@ >>>>>>> } >>>>>>> display(""); >>>>>>> } >>>>>>> + debugee.sendSignal(SGNL_QUIT); >>>>>>> >>>>>>> display(""); >>>>>>> display("============="); >>>>>> >>>>> >>>> >>> >>> >> > > From chris.plummer at oracle.com Wed Feb 6 19:19:10 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 6 Feb 2019 11:19:10 -0800 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: <5C5B2F5B.2000304@oracle.com> References: <5C548928.5010304@oracle.com> <9ee41f1e-9dc6-75a1-0c2b-f486986654fb@oracle.com> <5C5ADDA3.5070309@oracle.com> <5C5B059B.20906@oracle.com> <38b11652-fc40-0178-06ef-ff361236a1d7@oracle.com> <5C5B2107.5020905@oracle.com> <5C5B2F5B.2000304@oracle.com> Message-ID: <2fd7565b-3e7a-b757-566d-ca8002be721a@oracle.com> Ok. I think the fix is fine then if this is the only test that was problematic. Chris On 2/6/19 11:02 AM, Gary Adams wrote: > Yes, the test was hung in waitFor. > > The debugger process made some calls after the VMStart event > was observed, but never resumed the debuggee. > > Here's a simple change that makes test run to completion cleanly. > > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java > b/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java > > --- > a/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java > +++ > b/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -78,6 +78,7 @@ > ???????????? exitStatus = Consts.TEST_FAILED; > ???????????? e.printStackTrace(); > ???????? } finally { > +??????????? debugee.resume(); > ???????????? debugee.endDebugee(); > ???????? } > ???????? display("Test finished. exitStatus = " + exitStatus); > > On 2/6/19, 1:16 PM, Chris Plummer wrote: >> Does it timeout in waitFor()? >> >> Chris >> >> On 2/6/19 10:01 AM, Gary Adams wrote: >>> So far the only test that has an issue with the change in waitFor >>> order is >>> nsk/jdi/VirtualMachine/canBeModified, which does not appear to >>> synchronize >>> with the debuggee. >>> >>> On 2/6/19, 12:15 PM, Chris Plummer wrote: >>>> What happens if endDebugee() is called when the caller is not >>>> expecting a clean exit of the debugeee? Won't waitFor() wait >>>> forever in that case? I think by having the vm.dispose() first, you >>>> avoid that issue. >>>> >>>> Chris >>>> >>>> On 2/6/19 8:04 AM, Gary Adams wrote: >>>>> Testing an alternate fix that will wait for the debugee process to >>>>> terminate after processing the "quit" >>>>> command before doing the vm tear down. >>>>> >>>>> >>>>> diff --git >>>>> a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>>>> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>>>> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java >>>>> @@ -1,5 +1,5 @@ >>>>> ?/* >>>>> - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> ? * >>>>> ? * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> @@ -557,6 +557,7 @@ >>>>> ????? * exit status code. >>>>> ????? */ >>>>> ???? public int endDebugee() { >>>>> +??????? int status = waitFor(); >>>>> ???????? if (vm != null) { >>>>> ???????????? try { >>>>> ???????????????? vm.dispose(); >>>>> @@ -564,7 +565,7 @@ >>>>> ???????????? } >>>>> ???????????? vm = null; >>>>> ???????? } >>>>> -??????? return waitFor(); >>>>> +??????? return status; >>>>> ???? } >>>>> >>>>> >>>>> On 2/6/19, 8:14 AM, Gary Adams wrote: >>>>>> Just a quick update on the failure on shutdown ... >>>>>> I've come across a couple of other tests with a similar failure >>>>>> mode. >>>>>> >>>>>> I'm attempting to get some additional diagnostic information from >>>>>> these >>>>>> tests with "-jdi.trace=all", but the diagnostic output may be >>>>>> interfering >>>>>> with the timing. >>>>>> >>>>>> My current investigation is around a possible race condition >>>>>> in the Debgugee.quit() processing. >>>>>> ?? - the "quit" string is sent to the deuggee via the IOpipe >>>>>> ?? - the vm.dispose() is handled from the JDWP communication >>>>>> >>>>>> If the context switching is not quick enough, the debugee >>>>>> may not have read and processed the "quit" command before >>>>>> tear down is handled. >>>>>> >>>>>> From earlier comments in the bug report the debuggee was observed >>>>>> still at the breakpoint, so the resume and the disabling of the >>>>>> breakpoint >>>>>> had not been processed, yet. >>>>>> >>>>>> It might be worth having an "ack" returned when the "quit" is >>>>>> processed in the debugee. >>>>>> >>>>>> ... >>>>>> >>>>>> On 2/1/19, 2:15 PM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> The debugee.quit() is to complete the session. >>>>>>> It makes this call: sendSignal(SGNL_QUIT); >>>>>>> >>>>>>> A call to the debugee.quit() is at the end of execTest() method: >>>>>>> >>>>>>> ??????????? display(""); >>>>>>> ??????? } >>>>>>> >>>>>>> ??????? display(""); >>>>>>> ??????? display("============="); >>>>>>> ??????? display("TEST FINISHES\n"); >>>>>>> >>>>>>> ??????? brkpReq.disable(); >>>>>>> ??????? debugee.resume(); >>>>>>> ??????? debugee.quit(); >>>>>>> ??? } >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 2/1/19 10:00, Gary Adams wrote: >>>>>>>> When the remove_l005 runs to completion, it never signals the >>>>>>>> debuggee >>>>>>>> that all iterations have completed. >>>>>>>> >>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 >>>>>>>> >>>>>>>> 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 >>>>>>>> @@ -163,7 +163,6 @@ >>>>>>>> ?vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >>>>>>>> 8066993 generic-all >>>>>>>> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >>>>>>>> 8065773 generic-all >>>>>>>> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >>>>>>>> 8065773 generic-all >>>>>>>> -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java >>>>>>>> 8068225 generic-all >>>>>>>> >>>>>>>> ?vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java >>>>>>>> 8208250 generic-all >>>>>>>> ?vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java >>>>>>>> 8208250 generic-all >>>>>>>> >>>>>>>> >>>>>>>> diff --git >>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>>>> >>>>>>>> --- >>>>>>>> a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>>>> +++ >>>>>>>> b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java >>>>>>>> @@ -1,5 +1,5 @@ >>>>>>>> ?/* >>>>>>>> - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All >>>>>>>> rights reserved. >>>>>>>> + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >>>>>>>> rights reserved. >>>>>>>> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>>> ? * >>>>>>>> ? * This code is free software; you can redistribute it and/or >>>>>>>> modify it >>>>>>>> @@ -134,6 +134,7 @@ >>>>>>>> ???????????? } >>>>>>>> ???????????? display(""); >>>>>>>> ???????? } >>>>>>>> +??????? debugee.sendSignal(SGNL_QUIT); >>>>>>>> >>>>>>>> ???????? display(""); >>>>>>>> ???????? display("============="); >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From per.liden at oracle.com Thu Feb 7 09:20:02 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 7 Feb 2019 10:20:02 +0100 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> Message-ID: <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> Hi, On 2/6/19 3:48 PM, Aleksey Shipilev wrote: > On 2/6/19 3:34 PM, zgu at redhat.com wrote: >>> *) In src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp, why >>> this whole thing is removed? I >>> would expect "just" the rename of slow_refill_waste() to >>> refill_waste() and removing >>> fast_refill_waste() here, leaving everything else untouched. >>> >>> 105 // statistics >>> 106 >>> 107 int number_of_refills() const { return _number_of_refills; } >>> 108 int fast_refill_waste() const { return _fast_refill_waste; } >>> 109 int slow_refill_waste() const { return _slow_refill_waste; } >>> 110 int gc_waste() const { return _gc_waste; } >>> 111 int slow_allocations() const { return _slow_allocations; } >>> 112 >> >> They are dead code. Do they worth for another cleanup RFE for the >> trivial cleanup? > > Okay. I thought the patch was about fast refills only. But indeed, we can clean these unused > definitions in the same patch. On one hand, removing trivial unused getters would require us to add > them back when they are needed. On the other hand, it seems that TLAB does every statistic > internally, and we should instead force callers to use higher-level TLAB methods to access and > interpret them. > > Code looks good! I think we still need Serviceability to acknowledge this is okay to do. Thanks for cleaning this up. GC changes look good. Just one minor thing, please align the assignment here: @@ -147,8 +145,7 @@ void ThreadLocalAllocBuffer::reset_statistics() { _number_of_refills = 0; - _fast_refill_waste = 0; - _slow_refill_waste = 0; + _refill_waste = 0; _gc_waste = 0; _slow_allocations = 0; _allocated_size = 0; I agree that Serviceability should ack the jstat change. cheers, Per From aph at redhat.com Thu Feb 7 13:03:29 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Feb 2019 13:03:29 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> Message-ID: <1fd9aa7f-c5f5-80ef-dd47-73756a318d31@redhat.com> On 2/6/19 6:42 PM, Andrew Haley wrote: > On 2/6/19 10:54 AM, Nick Gasson (Arm Technology China) wrote: >> Hi Andrew >> >>> Here's the test that reveals the problem: it seems that you need an entry frame which calls compiled Java code. >> >> This seems slightly different to the original problem, although >> maybe related. Because here the top-most frame is a compiled Java >> frame we'll take the vm.isJavaPCDbg and !vm.isClientCompiler >> branches of AARCH64CurrentFrameGuess::run which as far as I can tell >> always gets the PC from the thread context. The original crash I was >> looking at happened when the top frame was native (else branch on >> line 183) where the PC is set to null which causes the two-argument >> AARCH64Frame constructor to be used. > > OK. > >> Unfortunately I'm on holiday until next Thursday so can't test >> anything. Did you try Thread.sleep? That's what LingeredApp that the >> jtreg tests is trying to get a stack trace of calls. > > Well, that was fun. When generally assume that we can find a saved PC > in a fixed place in the frame, and this is always the word above the > FP. However, when we're in JNI native code, as you've noticed the > C[++] compiler isn't helpful enough to lave the caller PC in a > well-known place. When the frame is created by our AArch64 assembly- > langage code we'll be fine because we always do the right thing. > > The problem is that when we save the Java frame state in the Thread, > we're doing it for the sake of the runtime, not for debuggers, so we > don't always save all the information that a debugger might need. > > This patch should work for compiled native methods, but I'm not at all > sure about all of the other places where we call out from runtime > stubs to the VM. We perhaps check that the PC returned by > raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()) is in the code > cache before we use it. > > Anyway, try this: it should fix your immediate bug. I had a much better idea. We usually save the PC in the frame anchor, so we should use it if we can. Add a little sanity checking, and we should be good to go, and we won't need to grovel about in the stack. I looked in all the places where we save information in the frame anchor, and we almost always set the PC appropriately. I tried this patch with a few basic smoke tests, and it seems to be considerably better than what we have right now. The only place it fails is when we're executing some C++-compiled code which is called directly from the interpreter or from compiled code. We could apply some magic in those cases, but it would incur some overhead and I'm not sure it's worthwhile. Please try this instead and let me know how you get on. Thanks. diff -r 3954d70e1c50 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64CurrentFrameGuess.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64CurrentFrameGuess.java Wed Feb 06 08:31:27 2019 +0100 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64CurrentFrameGuess.java Thu Feb 07 12:45:29 2019 +0000 @@ -223,8 +223,13 @@ } } - setValues(sp, fp, null); - + // We found a PC in the frame anchor. Check that it's plausible, and + // if it is, use it. + if (vm.isJavaPCDbg(pc)) { + setValues(sp, fp, pc); + } else { + setValues(sp, fp, null); + } return true; } } -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zgu at redhat.com Thu Feb 7 14:03:25 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 07 Feb 2019 09:03:25 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> Message-ID: <1549548205.31327.224.camel@redhat.com> Thanks, Per. > Thanks for cleaning this up. GC changes look good. Just one minor > thing, > please align the assignment here: > > @@ -147,8 +145,7 @@ > > void ThreadLocalAllocBuffer::reset_statistics() { > _number_of_refills = 0; > - _fast_refill_waste = 0; > - _slow_refill_waste = 0; > + _refill_waste = 0; > _gc_waste = 0; > _slow_allocations = 0; > _allocated_size = 0; > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.01/ -Zhengyu > > I agree that Serviceability should ack the jstat change. > > cheers, > Per From per.liden at oracle.com Thu Feb 7 14:05:52 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 7 Feb 2019 15:05:52 +0100 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549548205.31327.224.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> <1549548205.31327.224.camel@redhat.com> Message-ID: <60470a03-e95b-38f5-8d89-1ede02f1df27@oracle.com> On 2019-02-07 15:03, zgu at redhat.com wrote: > Thanks, Per. >> Thanks for cleaning this up. GC changes look good. Just one minor >> thing, >> please align the assignment here: >> >> @@ -147,8 +145,7 @@ >> >> void ThreadLocalAllocBuffer::reset_statistics() { >> _number_of_refills = 0; >> - _fast_refill_waste = 0; >> - _slow_refill_waste = 0; >> + _refill_waste = 0; >> _gc_waste = 0; >> _slow_allocations = 0; >> _allocated_size = 0; >> >> > Updated: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.01/ Thanks, looks good. /Per > > -Zhengyu > >> >> I agree that Serviceability should ack the jstat change. >> >> cheers, >> Per From Nick.Gasson at arm.com Thu Feb 7 14:36:05 2019 From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China)) Date: Thu, 7 Feb 2019 14:36:05 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <1fd9aa7f-c5f5-80ef-dd47-73756a318d31@redhat.com> References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> , <1fd9aa7f-c5f5-80ef-dd47-73756a318d31@redhat.com> Message-ID: Hi Andrew, Yeah I tried this method too (see the end of my first email). It works fine except the PC is off by a few instructions. That can be fixed quite easily though if required, and it always points into the right method. I ended up doing the stack scanning thing because as far as I can tell that constructor is only used when we need to find the return PC from a native frame (I might have been wrong about this), so I couldn't see how it would ever get the right value. If we check vm.isJavaPCDbg() before we use the SP[-1] value that will make the remaining callers a bit safer (and set this.pc to null otherwise). Nick ________________________________ From: Andrew Haley Sent: 07 February 2019 21:03:29 To: Nick Gasson (Arm Technology China); serviceability-dev at openjdk.java.net Cc: nd; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command On 2/6/19 6:42 PM, Andrew Haley wrote: > On 2/6/19 10:54 AM, Nick Gasson (Arm Technology China) wrote: >> Hi Andrew >> >>> Here's the test that reveals the problem: it seems that you need an entry frame which calls compiled Java code. >> >> This seems slightly different to the original problem, although >> maybe related. Because here the top-most frame is a compiled Java >> frame we'll take the vm.isJavaPCDbg and !vm.isClientCompiler >> branches of AARCH64CurrentFrameGuess::run which as far as I can tell >> always gets the PC from the thread context. The original crash I was >> looking at happened when the top frame was native (else branch on >> line 183) where the PC is set to null which causes the two-argument >> AARCH64Frame constructor to be used. > > OK. > >> Unfortunately I'm on holiday until next Thursday so can't test >> anything. Did you try Thread.sleep? That's what LingeredApp that the >> jtreg tests is trying to get a stack trace of calls. > > Well, that was fun. When generally assume that we can find a saved PC > in a fixed place in the frame, and this is always the word above the > FP. However, when we're in JNI native code, as you've noticed the > C[++] compiler isn't helpful enough to lave the caller PC in a > well-known place. When the frame is created by our AArch64 assembly- > langage code we'll be fine because we always do the right thing. > > The problem is that when we save the Java frame state in the Thread, > we're doing it for the sake of the runtime, not for debuggers, so we > don't always save all the information that a debugger might need. > > This patch should work for compiled native methods, but I'm not at all > sure about all of the other places where we call out from runtime > stubs to the VM. We perhaps check that the PC returned by > raw_sp.getAddressAt(-1 * VM.getVM().getAddressSize()) is in the code > cache before we use it. > > Anyway, try this: it should fix your immediate bug. I had a much better idea. We usually save the PC in the frame anchor, so we should use it if we can. Add a little sanity checking, and we should be good to go, and we won't need to grovel about in the stack. I looked in all the places where we save information in the frame anchor, and we almost always set the PC appropriately. I tried this patch with a few basic smoke tests, and it seems to be considerably better than what we have right now. The only place it fails is when we're executing some C++-compiled code which is called directly from the interpreter or from compiled code. We could apply some magic in those cases, but it would incur some overhead and I'm not sure it's worthwhile. Please try this instead and let me know how you get on. Thanks. diff -r 3954d70e1c50 src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64CurrentFrameGuess.java --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64CurrentFrameGuess.java Wed Feb 06 08:31:27 2019 +0100 +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64CurrentFrameGuess.java Thu Feb 07 12:45:29 2019 +0000 @@ -223,8 +223,13 @@ } } - setValues(sp, fp, null); - + // We found a PC in the frame anchor. Check that it's plausible, and + // if it is, use it. + if (vm.isJavaPCDbg(pc)) { + setValues(sp, fp, pc); + } else { + setValues(sp, fp, null); + } return true; } } -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Feb 7 15:39:46 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 Feb 2019 15:39:46 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> <1fd9aa7f-c5f5-80ef-dd47-73756a318d31@redhat.com> Message-ID: <068399ec-fbb8-b881-7ea2-1b684a42652a@redhat.com> On 2/7/19 2:36 PM, Nick Gasson (Arm Technology China) wrote: > > Yeah I tried this method too (see the end of my first email). It > works fine except the PC is off by a few instructions. That can be > fixed quite easily though if required, and it always points into the > right method. We should fix those few cases. > I ended up doing the stack scanning thing because as far as I can > tell that constructor is only used when we need to find the return > PC from a native frame I don't think that ever happens. In the code I modified we know that we have a good PC in the frame anchor. In the cases where we have a native frame on the stack and nothing in the frame anchor we give up. At least, I can see no counter-cases. > (I might have been wrong about this), so I couldn't see how it would > ever get the right value. If we check vm.isJavaPCDbg() before we use > the SP[-1] value that will make the remaining callers a bit safer > (and set this.pc to null otherwise). That would be safe, for sure. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniil.x.titov at oracle.com Thu Feb 7 17:52:10 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 07 Feb 2019 09:52:10 -0800 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: <56cdb16d-f761-7212-cc27-c0f68e882169@oracle.com> References: <8550b971-eede-c9ce-6eb9-4ec1671dbce3@oracle.com> <3C6EC1EF-672D-4577-9EEF-2CF73BDED256@oracle.com> <2a75f4de-6a77-615e-1648-0fcca59c6ea2@oracle.com> <0B661A5C-E59D-481C-BC3B-0951621F1F51@oracle.com> <5e9c223c-71c5-980e-03b9-679e69942f23@oracle.com> <0194722E-CFE1-4E3A-A521-14910D88B378@oracle.com> <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> <2599EF95-2EC5-4CE7-8036-33D9863631CB@oracle.com> <56cdb16d-f761-7212-cc27-c0f68e882169@oracle.com> Message-ID: Hi Serguei and David, Please review a new version of the fix that adds a new test test/jdk/sun/tools/jcmd/TestProcessHelper.java that starts Java processes using different command line options and verifies that sun.tools.ProcessHelper.getMainClass(pid) method returns a correct main class. Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.05/ Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 Thanks! -Daniil ?On 2/4/19, 2:26 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, Thank you for the update! It looks good in general. I think, it can be a good idea to add a simple tests for this command-line processing. It should save us from any surprises. Thanks, Serguei On 2/4/19 13:24, Daniil Titov wrote: > Hi Serguei, > > Thank you for reviewing this fix. > > Please review a new version of the fix that includes all changes you suggested but one about lines 88-91 and 97-101. > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > 89 i++; > 90 continue; > 91 } > ... > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > 99 i++; > 100 continue; > 101 } > 102 // Skip all other Java options > 103 if (parts[i].startsWith("-")) { > 104 continue; > 105 } > > You are right, these statements are needed to filter out the parts which have nothing to do with the mainClass. But we cannot remove these lines and just return the latest part[i] that was not filtered out as the mainClass since it will not work in the case when the command line includes arguments specified after the main class. In the approach we use the main class is the *first* part[i] (with i > 0) that is not a Java option ( part[i] that doesn't start with '-' and is not classpath, module path, jar file path or module name). This condition that the mainClass is not null is checked on line 89 inside for loop. > > 89 for (int i = 1; i < parts.length && mainClass == null; i++) { > > To simplify the code in the new version of the patch the lines 88-91 and 97-101 are combined in the one "if" block. > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.04 > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > Thanks. > --Daniil > > From: "serguei.spitsyn at oracle.com" > Date: Thursday, January 31, 2019 at 1:23 PM > To: David Holmes , Daniil Titov , serviceability-dev > Subject: Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out > > Hi Daniil, > > > I have some secondary comment on new file: > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java.html > > 70 for (int i = 0; i < parts.length && mainClass == null; i++) { > 71 // Check the executable > 72 if (i == 0) { > 73 String[] executablePath = parts[i].split("/"); > 74 if (executablePath.length > 0) { > 75 String binaryName = executablePath[executablePath.length - 1]; > 76 if (!"java".equals(binaryName)) { > 77 // Skip the process if it is not started with java launcher > 78 return null; > 79 } > 80 } > 81 continue; > 82 } > > It is better execute the logic in lines 73-80 before the loop. > It will simplify the code a little bit. > String[] executablePath = parts[i].split("/"); > if (executablePath.length > 0) { > String binaryName = executablePath[executablePath.length - 1]; > if (!binaryName.equals("java") { > return null; // Skip the process if it is not started with java launcher > > } > } > for (int i = 1; i < parts.length && mainClass == null; i++) { > > In the fragment below: > > 83 // Check if the module is executed with explicitly specified main class > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > 85 mainClass = getMainClassFromModuleArg(parts[i + 1]); > 86 break; > 87 } > > would it better to just return the main class instead of having a break statement? : > 85 return getMainClassFromModuleArg(parts[i + 1]); > > > The lines: > 108 if (jarFile != null) { > 109 return getMainClassFromJar(jarFile, pid); > 110 } > > is better to execute inside the loop the same as it is done for getMainClassFromModuleArg(). > > // Check if the main class needs to be read from the manifest.mf in a JAR file > if (parts[i].equals("-jar") && i < parts.length - 1) { > return getMainClassFromJar(jarFile, pid); > } > > In the if statements: > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > ... > 93 if (parts[i].equals("-jar") && i < parts.length - 1) { > > the last condition (i < parts.length - 1) is better to make the first (pre-condition). > They even can be combined together like below: > if (i < parts.length - 1) { > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > return getMainClassFromModuleArg(parts[i + 1]); > } > // Check if the main class needs to be read from the manifest.mf in a JAR file > if (parts[i].equals("-jar") ) { > return getMainClassFromJar(jarFile, pid); > } > } > > The biggest concern are the fragments: > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > 89 i++; > 90 continue; > 91 } > ... > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > 99 i++; > 100 continue; > 101 } > 102 // Skip all other Java options > 103 if (parts[i].startsWith("-")) { > 104 continue; > 105 } > If I understand it correctly, these statements are needed to filter out > the parts which have nothing to do with the mainClass. > The latest part[i] that was not filtered out is returned as the mainClass. > > I'm thinking about more general approach here. Probably, we just need to remove > the fragments 88-91 and 97-101 as they are covered by the fragment 102-105. > It will also simplify the code. > > With all the suggestion above it should converge to something like this: > String[] parts = cmdLine.split(" "); > String mainClass = null; > > String[] executablePath = parts[i].split("/"); > if (executablePath.length > 0) { > String binaryName = executablePath[executablePath.length - 1]; > if (!binaryName.equals("java") { > return null; // Skip the process if it is not started with java launcher > > } > } > for (int 1 = 0; i < parts.length && mainClass == null; i++) { > if (i < parts.length - 1) { > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > return getMainClassFromModuleArg(parts[i + 1]); > } > // Check if the main class needs to be read from the manifest.mf in a JAR file > if (parts[i].equals("-jar") ) { > return getMainClassFromJar(parts[i + 1], pid); > } > } > // Skip all other Java options > if (parts[i].startsWith("-")) { > continue; > } > mainClass = parts[i]; > } > return mainClass; > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java.html > > 49 if (cmd.equals("quit")) { > 50 log("'quit' received"); > 51 > 52 } else { > > The empty line 51 can be removed. > > Looking at this command-line processing I kind of understand the David's concern. > > Thanks, > Serguei > > > On 1/20/19 21:18, David Holmes wrote: > Thanks for the update Daniil. I still remain concerned about the robustness of the command-line parsing - this seems like a feature that needs its own set of tests. > > I'll leave it up to Serguei and others as to how to proceed. > > David > ----- > > On 19/01/2019 9:08 am, Daniil Titov wrote: > > Hi David and Serguei, > > Please review a new version of the fix that now covers the case when Java executes a module with the main class name explicitly specified in the command line. > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.03 > Bug: : https://bugs.openjdk.java.net/browse/JDK-8205654 > > Thanks! > --Daniil > > ?On 1/8/19, 6:05 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > Hi Daniil, > Sorry this slipped through the Xmas break cracks :) > On 22/12/2018 12:04 pm, Daniil Titov wrote: > > Hi David and Serguei, > > > > Please review a new version of the fix that for Linux platform uses the proc filesystem to retrieve the main class name for the running Java process. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > It's more complex than I had envisaged but seems to be doing the job. > I'm not sure how robust the command-line parsing is, in particular it > doesn't handle these forms: > or java [options] -m [/] [args...] > java [options] --module [/] [args...] > (to execute the main class in a module) > I can't really comment on all the details. > Thanks, > David > ----- > > Thanks, > > Daniil > > > > ?On 11/29/18, 4:52 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > Hi Daniil, > > > > On 30/11/2018 7:30 am, Daniil Titov wrote: > > > Thank you, David! > > > > > > The proposed fix didn't help. It still hangs at some occasions. Additional tracing showed that when jcmd is invoked with the main class name it iterates over all running Java processes and temporary attaches to them to retrieve the main class name. It hangs while trying to attach to one of the running Java processes. There are numerous Java processes running at the host machine some associated with the test framework itself and another with the tests running in parallel. It is not clear what exact is this particular process since the jcmd hangs before retrieving the process' main class name, but after all tests terminated the process with this id is no longer running. I have to revoke this review since more investigation is required. > > > > That sounds like an unsolvable problem for the test. You can't control > > other Java processes on the machine, and searching by name requires > > asking each of them in turn. > > > > How do we get the list of Java processes in the first place? Perhaps we > > need to do some /proc//cmdline peeking? > > > > Cheers, > > David > > > > > > > > Best regards, > > > Daniil > > > > > > > > > > > > ?On 11/11/18, 1:35 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > Hi Daniil, > > > > > > I took a quick look at this one ... two minor comments > > > > > > The static class names could just be "Process" as they will acquire the > > > enclosing class name as part of their own name anyway. As it is this > > > gets repeated eg: > > > > > > HelpTest$HelpTestProcess > > > InvalidCommandTest$InvalidCommandTestProcess > > > > > > TestJavaProcess.java: > > > > > > 39 public static void main(String argv[]) { > > > > > > Nit: Should be "String[] argv" in Java style > > > > > > Thanks, > > > David > > > > > > On 10/11/2018 3:18 PM, Daniil Titov wrote: > > > > Please review the change that fixes serviceability/dcmd/framework/* tests from a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with each other and there are no multiple tests running simultaneously since all they do share the common main class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks like the tests from other directories still might run in parallel with these tests and they also have com.sun.javatest.regtest.agent.MainWrapper as a main class. > > > > > > > > The fix ensures that each serviceability/dcmd/framework/* test uses a Java process with a unique main class name when connecting to this process with jcmd and the main class name. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/ > > > > > > > > Best regards, > > > > Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > > > From serguei.spitsyn at oracle.com Thu Feb 7 19:46:34 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Feb 2019 11:46:34 -0800 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: References: <8550b971-eede-c9ce-6eb9-4ec1671dbce3@oracle.com> <3C6EC1EF-672D-4577-9EEF-2CF73BDED256@oracle.com> <2a75f4de-6a77-615e-1648-0fcca59c6ea2@oracle.com> <0B661A5C-E59D-481C-BC3B-0951621F1F51@oracle.com> <5e9c223c-71c5-980e-03b9-679e69942f23@oracle.com> <0194722E-CFE1-4E3A-A521-14910D88B378@oracle.com> <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> <2599EF95-2EC5-4CE7-8036-33D9863631CB@oracle.com> <56cdb16d-f761-7212-cc27-c0f68e882169@oracle.com> Message-ID: Hi Daniil, It looks good to me. Thank you for the update! Thanks, Serguei On 2/7/19 09:52, Daniil Titov wrote: > Hi Serguei and David, > > Please review a new version of the fix that adds a new test test/jdk/sun/tools/jcmd/TestProcessHelper.java that starts Java processes using different command line options and verifies that sun.tools.ProcessHelper.getMainClass(pid) method returns a correct main class. > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.05/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > Thanks! > -Daniil > > > > ?On 2/4/19, 2:26 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > Thank you for the update! > > It looks good in general. > > I think, it can be a good idea to add a simple tests for this > command-line processing. > It should save us from any surprises. > > Thanks, > Serguei > > > On 2/4/19 13:24, Daniil Titov wrote: > > Hi Serguei, > > > > Thank you for reviewing this fix. > > > > Please review a new version of the fix that includes all changes you suggested but one about lines 88-91 and 97-101. > > > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > > 89 i++; > > 90 continue; > > 91 } > > ... > > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > > 99 i++; > > 100 continue; > > 101 } > > 102 // Skip all other Java options > > 103 if (parts[i].startsWith("-")) { > > 104 continue; > > 105 } > > > > You are right, these statements are needed to filter out the parts which have nothing to do with the mainClass. But we cannot remove these lines and just return the latest part[i] that was not filtered out as the mainClass since it will not work in the case when the command line includes arguments specified after the main class. In the approach we use the main class is the *first* part[i] (with i > 0) that is not a Java option ( part[i] that doesn't start with '-' and is not classpath, module path, jar file path or module name). This condition that the mainClass is not null is checked on line 89 inside for loop. > > > > 89 for (int i = 1; i < parts.length && mainClass == null; i++) { > > > > To simplify the code in the new version of the patch the lines 88-91 and 97-101 are combined in the one "if" block. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.04 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > Thanks. > > --Daniil > > > > From: "serguei.spitsyn at oracle.com" > > Date: Thursday, January 31, 2019 at 1:23 PM > > To: David Holmes , Daniil Titov , serviceability-dev > > Subject: Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out > > > > Hi Daniil, > > > > > > I have some secondary comment on new file: > > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java.html > > > > 70 for (int i = 0; i < parts.length && mainClass == null; i++) { > > 71 // Check the executable > > 72 if (i == 0) { > > 73 String[] executablePath = parts[i].split("/"); > > 74 if (executablePath.length > 0) { > > 75 String binaryName = executablePath[executablePath.length - 1]; > > 76 if (!"java".equals(binaryName)) { > > 77 // Skip the process if it is not started with java launcher > > 78 return null; > > 79 } > > 80 } > > 81 continue; > > 82 } > > > > It is better execute the logic in lines 73-80 before the loop. > > It will simplify the code a little bit. > > String[] executablePath = parts[i].split("/"); > > if (executablePath.length > 0) { > > String binaryName = executablePath[executablePath.length - 1]; > > if (!binaryName.equals("java") { > > return null; // Skip the process if it is not started with java launcher > > > > } > > } > > for (int i = 1; i < parts.length && mainClass == null; i++) { > > > > In the fragment below: > > > > 83 // Check if the module is executed with explicitly specified main class > > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > > 85 mainClass = getMainClassFromModuleArg(parts[i + 1]); > > 86 break; > > 87 } > > > > would it better to just return the main class instead of having a break statement? : > > 85 return getMainClassFromModuleArg(parts[i + 1]); > > > > > > The lines: > > 108 if (jarFile != null) { > > 109 return getMainClassFromJar(jarFile, pid); > > 110 } > > > > is better to execute inside the loop the same as it is done for getMainClassFromModuleArg(). > > > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") && i < parts.length - 1) { > > return getMainClassFromJar(jarFile, pid); > > } > > > > In the if statements: > > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > > ... > > 93 if (parts[i].equals("-jar") && i < parts.length - 1) { > > > > the last condition (i < parts.length - 1) is better to make the first (pre-condition). > > They even can be combined together like below: > > if (i < parts.length - 1) { > > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > > return getMainClassFromModuleArg(parts[i + 1]); > > } > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") ) { > > return getMainClassFromJar(jarFile, pid); > > } > > } > > > > The biggest concern are the fragments: > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > > 89 i++; > > 90 continue; > > 91 } > > ... > > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > > 99 i++; > > 100 continue; > > 101 } > > 102 // Skip all other Java options > > 103 if (parts[i].startsWith("-")) { > > 104 continue; > > 105 } > > If I understand it correctly, these statements are needed to filter out > > the parts which have nothing to do with the mainClass. > > The latest part[i] that was not filtered out is returned as the mainClass. > > > > I'm thinking about more general approach here. Probably, we just need to remove > > the fragments 88-91 and 97-101 as they are covered by the fragment 102-105. > > It will also simplify the code. > > > > With all the suggestion above it should converge to something like this: > > String[] parts = cmdLine.split(" "); > > String mainClass = null; > > > > String[] executablePath = parts[i].split("/"); > > if (executablePath.length > 0) { > > String binaryName = executablePath[executablePath.length - 1]; > > if (!binaryName.equals("java") { > > return null; // Skip the process if it is not started with java launcher > > > > } > > } > > for (int 1 = 0; i < parts.length && mainClass == null; i++) { > > if (i < parts.length - 1) { > > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > > return getMainClassFromModuleArg(parts[i + 1]); > > } > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") ) { > > return getMainClassFromJar(parts[i + 1], pid); > > } > > } > > // Skip all other Java options > > if (parts[i].startsWith("-")) { > > continue; > > } > > mainClass = parts[i]; > > } > > return mainClass; > > > > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java.html > > > > 49 if (cmd.equals("quit")) { > > 50 log("'quit' received"); > > 51 > > 52 } else { > > > > The empty line 51 can be removed. > > > > Looking at this command-line processing I kind of understand the David's concern. > > > > Thanks, > > Serguei > > > > > > On 1/20/19 21:18, David Holmes wrote: > > Thanks for the update Daniil. I still remain concerned about the robustness of the command-line parsing - this seems like a feature that needs its own set of tests. > > > > I'll leave it up to Serguei and others as to how to proceed. > > > > David > > ----- > > > > On 19/01/2019 9:08 am, Daniil Titov wrote: > > > > Hi David and Serguei, > > > > Please review a new version of the fix that now covers the case when Java executes a module with the main class name explicitly specified in the command line. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.03 > > Bug: : https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > Thanks! > > --Daniil > > > > ?On 1/8/19, 6:05 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > Hi Daniil, > > Sorry this slipped through the Xmas break cracks :) > > On 22/12/2018 12:04 pm, Daniil Titov wrote: > > > Hi David and Serguei, > > > > > > Please review a new version of the fix that for Linux platform uses the proc filesystem to retrieve the main class name for the running Java process. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > It's more complex than I had envisaged but seems to be doing the job. > > I'm not sure how robust the command-line parsing is, in particular it > > doesn't handle these forms: > > or java [options] -m [/] [args...] > > java [options] --module [/] [args...] > > (to execute the main class in a module) > > I can't really comment on all the details. > > Thanks, > > David > > ----- > > > Thanks, > > > Daniil > > > > > > ?On 11/29/18, 4:52 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > Hi Daniil, > > > > > > On 30/11/2018 7:30 am, Daniil Titov wrote: > > > > Thank you, David! > > > > > > > > The proposed fix didn't help. It still hangs at some occasions. Additional tracing showed that when jcmd is invoked with the main class name it iterates over all running Java processes and temporary attaches to them to retrieve the main class name. It hangs while trying to attach to one of the running Java processes. There are numerous Java processes running at the host machine some associated with the test framework itself and another with the tests running in parallel. It is not clear what exact is this particular process since the jcmd hangs before retrieving the process' main class name, but after all tests terminated the process with this id is no longer running. I have to revoke this review since more investigation is required. > > > > > > That sounds like an unsolvable problem for the test. You can't control > > > other Java processes on the machine, and searching by name requires > > > asking each of them in turn. > > > > > > How do we get the list of Java processes in the first place? Perhaps we > > > need to do some /proc//cmdline peeking? > > > > > > Cheers, > > > David > > > > > > > > > > > Best regards, > > > > Daniil > > > > > > > > > > > > > > > > ?On 11/11/18, 1:35 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > > > Hi Daniil, > > > > > > > > I took a quick look at this one ... two minor comments > > > > > > > > The static class names could just be "Process" as they will acquire the > > > > enclosing class name as part of their own name anyway. As it is this > > > > gets repeated eg: > > > > > > > > HelpTest$HelpTestProcess > > > > InvalidCommandTest$InvalidCommandTestProcess > > > > > > > > TestJavaProcess.java: > > > > > > > > 39 public static void main(String argv[]) { > > > > > > > > Nit: Should be "String[] argv" in Java style > > > > > > > > Thanks, > > > > David > > > > > > > > On 10/11/2018 3:18 PM, Daniil Titov wrote: > > > > > Please review the change that fixes serviceability/dcmd/framework/* tests from a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with each other and there are no multiple tests running simultaneously since all they do share the common main class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks like the tests from other directories still might run in parallel with these tests and they also have com.sun.javatest.regtest.agent.MainWrapper as a main class. > > > > > > > > > > The fix ensures that each serviceability/dcmd/framework/* test uses a Java process with a unique main class name when connecting to this process with jcmd and the main class name. > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/ > > > > > > > > > > Best regards, > > > > > Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From david.holmes at oracle.com Thu Feb 7 23:08:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Feb 2019 09:08:55 +1000 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: References: <8550b971-eede-c9ce-6eb9-4ec1671dbce3@oracle.com> <3C6EC1EF-672D-4577-9EEF-2CF73BDED256@oracle.com> <2a75f4de-6a77-615e-1648-0fcca59c6ea2@oracle.com> <0B661A5C-E59D-481C-BC3B-0951621F1F51@oracle.com> <5e9c223c-71c5-980e-03b9-679e69942f23@oracle.com> <0194722E-CFE1-4E3A-A521-14910D88B378@oracle.com> <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> <2599EF95-2EC5-4CE7-8036-33D9863631CB@oracle.com> <56cdb16d-f761-7212-cc27-c0f68e882169@oracle.com> Message-ID: <8964269f-9412-b818-8ef0-c9e8b4a22c94@oracle.com> Hi Daniil, Thanks for the additional testing. On 8/02/2019 3:52 am, Daniil Titov wrote: > Hi Serguei and David, > > Please review a new version of the fix that adds a new test test/jdk/sun/tools/jcmd/TestProcessHelper.java that starts Java processes using different command line options and verifies that sun.tools.ProcessHelper.getMainClass(pid) method returns a correct main class. > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.05/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 Why linux only? Also wondering how long this will take to run? We need to be mindful of impact on tier testing. AFAICS this will run in tier3, tier4-graal and tier8-Xcomp - and it's the last one we may need to watch for time. Thanks, David > Thanks! > -Daniil > > > > ?On 2/4/19, 2:26 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > Thank you for the update! > > It looks good in general. > > I think, it can be a good idea to add a simple tests for this > command-line processing. > It should save us from any surprises. > > Thanks, > Serguei > > > On 2/4/19 13:24, Daniil Titov wrote: > > Hi Serguei, > > > > Thank you for reviewing this fix. > > > > Please review a new version of the fix that includes all changes you suggested but one about lines 88-91 and 97-101. > > > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > > 89 i++; > > 90 continue; > > 91 } > > ... > > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > > 99 i++; > > 100 continue; > > 101 } > > 102 // Skip all other Java options > > 103 if (parts[i].startsWith("-")) { > > 104 continue; > > 105 } > > > > You are right, these statements are needed to filter out the parts which have nothing to do with the mainClass. But we cannot remove these lines and just return the latest part[i] that was not filtered out as the mainClass since it will not work in the case when the command line includes arguments specified after the main class. In the approach we use the main class is the *first* part[i] (with i > 0) that is not a Java option ( part[i] that doesn't start with '-' and is not classpath, module path, jar file path or module name). This condition that the mainClass is not null is checked on line 89 inside for loop. > > > > 89 for (int i = 1; i < parts.length && mainClass == null; i++) { > > > > To simplify the code in the new version of the patch the lines 88-91 and 97-101 are combined in the one "if" block. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.04 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > Thanks. > > --Daniil > > > > From: "serguei.spitsyn at oracle.com" > > Date: Thursday, January 31, 2019 at 1:23 PM > > To: David Holmes , Daniil Titov , serviceability-dev > > Subject: Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out > > > > Hi Daniil, > > > > > > I have some secondary comment on new file: > > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java.html > > > > 70 for (int i = 0; i < parts.length && mainClass == null; i++) { > > 71 // Check the executable > > 72 if (i == 0) { > > 73 String[] executablePath = parts[i].split("/"); > > 74 if (executablePath.length > 0) { > > 75 String binaryName = executablePath[executablePath.length - 1]; > > 76 if (!"java".equals(binaryName)) { > > 77 // Skip the process if it is not started with java launcher > > 78 return null; > > 79 } > > 80 } > > 81 continue; > > 82 } > > > > It is better execute the logic in lines 73-80 before the loop. > > It will simplify the code a little bit. > > String[] executablePath = parts[i].split("/"); > > if (executablePath.length > 0) { > > String binaryName = executablePath[executablePath.length - 1]; > > if (!binaryName.equals("java") { > > return null; // Skip the process if it is not started with java launcher > > > > } > > } > > for (int i = 1; i < parts.length && mainClass == null; i++) { > > > > In the fragment below: > > > > 83 // Check if the module is executed with explicitly specified main class > > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > > 85 mainClass = getMainClassFromModuleArg(parts[i + 1]); > > 86 break; > > 87 } > > > > would it better to just return the main class instead of having a break statement? : > > 85 return getMainClassFromModuleArg(parts[i + 1]); > > > > > > The lines: > > 108 if (jarFile != null) { > > 109 return getMainClassFromJar(jarFile, pid); > > 110 } > > > > is better to execute inside the loop the same as it is done for getMainClassFromModuleArg(). > > > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") && i < parts.length - 1) { > > return getMainClassFromJar(jarFile, pid); > > } > > > > In the if statements: > > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > > ... > > 93 if (parts[i].equals("-jar") && i < parts.length - 1) { > > > > the last condition (i < parts.length - 1) is better to make the first (pre-condition). > > They even can be combined together like below: > > if (i < parts.length - 1) { > > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > > return getMainClassFromModuleArg(parts[i + 1]); > > } > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") ) { > > return getMainClassFromJar(jarFile, pid); > > } > > } > > > > The biggest concern are the fragments: > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > > 89 i++; > > 90 continue; > > 91 } > > ... > > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > > 99 i++; > > 100 continue; > > 101 } > > 102 // Skip all other Java options > > 103 if (parts[i].startsWith("-")) { > > 104 continue; > > 105 } > > If I understand it correctly, these statements are needed to filter out > > the parts which have nothing to do with the mainClass. > > The latest part[i] that was not filtered out is returned as the mainClass. > > > > I'm thinking about more general approach here. Probably, we just need to remove > > the fragments 88-91 and 97-101 as they are covered by the fragment 102-105. > > It will also simplify the code. > > > > With all the suggestion above it should converge to something like this: > > String[] parts = cmdLine.split(" "); > > String mainClass = null; > > > > String[] executablePath = parts[i].split("/"); > > if (executablePath.length > 0) { > > String binaryName = executablePath[executablePath.length - 1]; > > if (!binaryName.equals("java") { > > return null; // Skip the process if it is not started with java launcher > > > > } > > } > > for (int 1 = 0; i < parts.length && mainClass == null; i++) { > > if (i < parts.length - 1) { > > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > > return getMainClassFromModuleArg(parts[i + 1]); > > } > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") ) { > > return getMainClassFromJar(parts[i + 1], pid); > > } > > } > > // Skip all other Java options > > if (parts[i].startsWith("-")) { > > continue; > > } > > mainClass = parts[i]; > > } > > return mainClass; > > > > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java.html > > > > 49 if (cmd.equals("quit")) { > > 50 log("'quit' received"); > > 51 > > 52 } else { > > > > The empty line 51 can be removed. > > > > Looking at this command-line processing I kind of understand the David's concern. > > > > Thanks, > > Serguei > > > > > > On 1/20/19 21:18, David Holmes wrote: > > Thanks for the update Daniil. I still remain concerned about the robustness of the command-line parsing - this seems like a feature that needs its own set of tests. > > > > I'll leave it up to Serguei and others as to how to proceed. > > > > David > > ----- > > > > On 19/01/2019 9:08 am, Daniil Titov wrote: > > > > Hi David and Serguei, > > > > Please review a new version of the fix that now covers the case when Java executes a module with the main class name explicitly specified in the command line. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.03 > > Bug: : https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > Thanks! > > --Daniil > > > > ?On 1/8/19, 6:05 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > Hi Daniil, > > Sorry this slipped through the Xmas break cracks :) > > On 22/12/2018 12:04 pm, Daniil Titov wrote: > > > Hi David and Serguei, > > > > > > Please review a new version of the fix that for Linux platform uses the proc filesystem to retrieve the main class name for the running Java process. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > It's more complex than I had envisaged but seems to be doing the job. > > I'm not sure how robust the command-line parsing is, in particular it > > doesn't handle these forms: > > or java [options] -m [/] [args...] > > java [options] --module [/] [args...] > > (to execute the main class in a module) > > I can't really comment on all the details. > > Thanks, > > David > > ----- > > > Thanks, > > > Daniil > > > > > > ?On 11/29/18, 4:52 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > Hi Daniil, > > > > > > On 30/11/2018 7:30 am, Daniil Titov wrote: > > > > Thank you, David! > > > > > > > > The proposed fix didn't help. It still hangs at some occasions. Additional tracing showed that when jcmd is invoked with the main class name it iterates over all running Java processes and temporary attaches to them to retrieve the main class name. It hangs while trying to attach to one of the running Java processes. There are numerous Java processes running at the host machine some associated with the test framework itself and another with the tests running in parallel. It is not clear what exact is this particular process since the jcmd hangs before retrieving the process' main class name, but after all tests terminated the process with this id is no longer running. I have to revoke this review since more investigation is required. > > > > > > That sounds like an unsolvable problem for the test. You can't control > > > other Java processes on the machine, and searching by name requires > > > asking each of them in turn. > > > > > > How do we get the list of Java processes in the first place? Perhaps we > > > need to do some /proc//cmdline peeking? > > > > > > Cheers, > > > David > > > > > > > > > > > Best regards, > > > > Daniil > > > > > > > > > > > > > > > > ?On 11/11/18, 1:35 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > > > Hi Daniil, > > > > > > > > I took a quick look at this one ... two minor comments > > > > > > > > The static class names could just be "Process" as they will acquire the > > > > enclosing class name as part of their own name anyway. As it is this > > > > gets repeated eg: > > > > > > > > HelpTest$HelpTestProcess > > > > InvalidCommandTest$InvalidCommandTestProcess > > > > > > > > TestJavaProcess.java: > > > > > > > > 39 public static void main(String argv[]) { > > > > > > > > Nit: Should be "String[] argv" in Java style > > > > > > > > Thanks, > > > > David > > > > > > > > On 10/11/2018 3:18 PM, Daniil Titov wrote: > > > > > Please review the change that fixes serviceability/dcmd/framework/* tests from a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with each other and there are no multiple tests running simultaneously since all they do share the common main class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks like the tests from other directories still might run in parallel with these tests and they also have com.sun.javatest.regtest.agent.MainWrapper as a main class. > > > > > > > > > > The fix ensures that each serviceability/dcmd/framework/* test uses a Java process with a unique main class name when connecting to this process with jcmd and the main class name. > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/ > > > > > > > > > > Best regards, > > > > > Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From daniil.x.titov at oracle.com Fri Feb 8 00:53:05 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 07 Feb 2019 16:53:05 -0800 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: <8964269f-9412-b818-8ef0-c9e8b4a22c94@oracle.com> References: <8550b971-eede-c9ce-6eb9-4ec1671dbce3@oracle.com> <3C6EC1EF-672D-4577-9EEF-2CF73BDED256@oracle.com> <2a75f4de-6a77-615e-1648-0fcca59c6ea2@oracle.com> <0B661A5C-E59D-481C-BC3B-0951621F1F51@oracle.com> <5e9c223c-71c5-980e-03b9-679e69942f23@oracle.com> <0194722E-CFE1-4E3A-A521-14910D88B378@oracle.com> <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> <2599EF95-2EC5-4CE7-8036-33D9863631CB@oracle.com> <56cdb16d-f761-7212-cc27-c0f68e882169@oracle.com> <8964269f-9412-b818-8ef0-c9e8b4a22c94@oracle.com> Message-ID: Hi David, Currently sun.tools.ProcessHelper is implemented for Linux platform only since it uses the proc filesystem that is limited to Linux platform. As a result the test is limited to Linux platform as well. All recorded timeouts that this change is fixing were reported for Linux platform only. In future we could consider providing the similar functionality for other platforms but it will need to use some different mechanisms. Please find below the statistics for running this newly added test test/jdk/sun/tools/jcmd/TestProcessHelper.java with linux-x64-debug build in Mach5: 1. With Graal ("-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal") - 6s 2. With Xcomp ("-Xcomp") - 20 s 3. With Graal and Xcomp ("-Xcomp -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal") - 1m 21s Best regards, Daniil ?On 2/7/19, 3:08 PM, "David Holmes" wrote: Hi Daniil, Thanks for the additional testing. On 8/02/2019 3:52 am, Daniil Titov wrote: > Hi Serguei and David, > > Please review a new version of the fix that adds a new test test/jdk/sun/tools/jcmd/TestProcessHelper.java that starts Java processes using different command line options and verifies that sun.tools.ProcessHelper.getMainClass(pid) method returns a correct main class. > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.05/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 Why linux only? Also wondering how long this will take to run? We need to be mindful of impact on tier testing. AFAICS this will run in tier3, tier4-graal and tier8-Xcomp - and it's the last one we may need to watch for time. Thanks, David > Thanks! > -Daniil > > > > ?On 2/4/19, 2:26 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > Thank you for the update! > > It looks good in general. > > I think, it can be a good idea to add a simple tests for this > command-line processing. > It should save us from any surprises. > > Thanks, > Serguei > > > On 2/4/19 13:24, Daniil Titov wrote: > > Hi Serguei, > > > > Thank you for reviewing this fix. > > > > Please review a new version of the fix that includes all changes you suggested but one about lines 88-91 and 97-101. > > > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > > 89 i++; > > 90 continue; > > 91 } > > ... > > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > > 99 i++; > > 100 continue; > > 101 } > > 102 // Skip all other Java options > > 103 if (parts[i].startsWith("-")) { > > 104 continue; > > 105 } > > > > You are right, these statements are needed to filter out the parts which have nothing to do with the mainClass. But we cannot remove these lines and just return the latest part[i] that was not filtered out as the mainClass since it will not work in the case when the command line includes arguments specified after the main class. In the approach we use the main class is the *first* part[i] (with i > 0) that is not a Java option ( part[i] that doesn't start with '-' and is not classpath, module path, jar file path or module name). This condition that the mainClass is not null is checked on line 89 inside for loop. > > > > 89 for (int i = 1; i < parts.length && mainClass == null; i++) { > > > > To simplify the code in the new version of the patch the lines 88-91 and 97-101 are combined in the one "if" block. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.04 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > Thanks. > > --Daniil > > > > From: "serguei.spitsyn at oracle.com" > > Date: Thursday, January 31, 2019 at 1:23 PM > > To: David Holmes , Daniil Titov , serviceability-dev > > Subject: Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out > > > > Hi Daniil, > > > > > > I have some secondary comment on new file: > > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java.html > > > > 70 for (int i = 0; i < parts.length && mainClass == null; i++) { > > 71 // Check the executable > > 72 if (i == 0) { > > 73 String[] executablePath = parts[i].split("/"); > > 74 if (executablePath.length > 0) { > > 75 String binaryName = executablePath[executablePath.length - 1]; > > 76 if (!"java".equals(binaryName)) { > > 77 // Skip the process if it is not started with java launcher > > 78 return null; > > 79 } > > 80 } > > 81 continue; > > 82 } > > > > It is better execute the logic in lines 73-80 before the loop. > > It will simplify the code a little bit. > > String[] executablePath = parts[i].split("/"); > > if (executablePath.length > 0) { > > String binaryName = executablePath[executablePath.length - 1]; > > if (!binaryName.equals("java") { > > return null; // Skip the process if it is not started with java launcher > > > > } > > } > > for (int i = 1; i < parts.length && mainClass == null; i++) { > > > > In the fragment below: > > > > 83 // Check if the module is executed with explicitly specified main class > > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > > 85 mainClass = getMainClassFromModuleArg(parts[i + 1]); > > 86 break; > > 87 } > > > > would it better to just return the main class instead of having a break statement? : > > 85 return getMainClassFromModuleArg(parts[i + 1]); > > > > > > The lines: > > 108 if (jarFile != null) { > > 109 return getMainClassFromJar(jarFile, pid); > > 110 } > > > > is better to execute inside the loop the same as it is done for getMainClassFromModuleArg(). > > > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") && i < parts.length - 1) { > > return getMainClassFromJar(jarFile, pid); > > } > > > > In the if statements: > > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > > ... > > 93 if (parts[i].equals("-jar") && i < parts.length - 1) { > > > > the last condition (i < parts.length - 1) is better to make the first (pre-condition). > > They even can be combined together like below: > > if (i < parts.length - 1) { > > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > > return getMainClassFromModuleArg(parts[i + 1]); > > } > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") ) { > > return getMainClassFromJar(jarFile, pid); > > } > > } > > > > The biggest concern are the fragments: > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > > 89 i++; > > 90 continue; > > 91 } > > ... > > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > > 99 i++; > > 100 continue; > > 101 } > > 102 // Skip all other Java options > > 103 if (parts[i].startsWith("-")) { > > 104 continue; > > 105 } > > If I understand it correctly, these statements are needed to filter out > > the parts which have nothing to do with the mainClass. > > The latest part[i] that was not filtered out is returned as the mainClass. > > > > I'm thinking about more general approach here. Probably, we just need to remove > > the fragments 88-91 and 97-101 as they are covered by the fragment 102-105. > > It will also simplify the code. > > > > With all the suggestion above it should converge to something like this: > > String[] parts = cmdLine.split(" "); > > String mainClass = null; > > > > String[] executablePath = parts[i].split("/"); > > if (executablePath.length > 0) { > > String binaryName = executablePath[executablePath.length - 1]; > > if (!binaryName.equals("java") { > > return null; // Skip the process if it is not started with java launcher > > > > } > > } > > for (int 1 = 0; i < parts.length && mainClass == null; i++) { > > if (i < parts.length - 1) { > > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > > return getMainClassFromModuleArg(parts[i + 1]); > > } > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > if (parts[i].equals("-jar") ) { > > return getMainClassFromJar(parts[i + 1], pid); > > } > > } > > // Skip all other Java options > > if (parts[i].startsWith("-")) { > > continue; > > } > > mainClass = parts[i]; > > } > > return mainClass; > > > > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java.html > > > > 49 if (cmd.equals("quit")) { > > 50 log("'quit' received"); > > 51 > > 52 } else { > > > > The empty line 51 can be removed. > > > > Looking at this command-line processing I kind of understand the David's concern. > > > > Thanks, > > Serguei > > > > > > On 1/20/19 21:18, David Holmes wrote: > > Thanks for the update Daniil. I still remain concerned about the robustness of the command-line parsing - this seems like a feature that needs its own set of tests. > > > > I'll leave it up to Serguei and others as to how to proceed. > > > > David > > ----- > > > > On 19/01/2019 9:08 am, Daniil Titov wrote: > > > > Hi David and Serguei, > > > > Please review a new version of the fix that now covers the case when Java executes a module with the main class name explicitly specified in the command line. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.03 > > Bug: : https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > Thanks! > > --Daniil > > > > ?On 1/8/19, 6:05 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > Hi Daniil, > > Sorry this slipped through the Xmas break cracks :) > > On 22/12/2018 12:04 pm, Daniil Titov wrote: > > > Hi David and Serguei, > > > > > > Please review a new version of the fix that for Linux platform uses the proc filesystem to retrieve the main class name for the running Java process. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > It's more complex than I had envisaged but seems to be doing the job. > > I'm not sure how robust the command-line parsing is, in particular it > > doesn't handle these forms: > > or java [options] -m [/] [args...] > > java [options] --module [/] [args...] > > (to execute the main class in a module) > > I can't really comment on all the details. > > Thanks, > > David > > ----- > > > Thanks, > > > Daniil > > > > > > ?On 11/29/18, 4:52 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > Hi Daniil, > > > > > > On 30/11/2018 7:30 am, Daniil Titov wrote: > > > > Thank you, David! > > > > > > > > The proposed fix didn't help. It still hangs at some occasions. Additional tracing showed that when jcmd is invoked with the main class name it iterates over all running Java processes and temporary attaches to them to retrieve the main class name. It hangs while trying to attach to one of the running Java processes. There are numerous Java processes running at the host machine some associated with the test framework itself and another with the tests running in parallel. It is not clear what exact is this particular process since the jcmd hangs before retrieving the process' main class name, but after all tests terminated the process with this id is no longer running. I have to revoke this review since more investigation is required. > > > > > > That sounds like an unsolvable problem for the test. You can't control > > > other Java processes on the machine, and searching by name requires > > > asking each of them in turn. > > > > > > How do we get the list of Java processes in the first place? Perhaps we > > > need to do some /proc//cmdline peeking? > > > > > > Cheers, > > > David > > > > > > > > > > > Best regards, > > > > Daniil > > > > > > > > > > > > > > > > ?On 11/11/18, 1:35 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > > > Hi Daniil, > > > > > > > > I took a quick look at this one ... two minor comments > > > > > > > > The static class names could just be "Process" as they will acquire the > > > > enclosing class name as part of their own name anyway. As it is this > > > > gets repeated eg: > > > > > > > > HelpTest$HelpTestProcess > > > > InvalidCommandTest$InvalidCommandTestProcess > > > > > > > > TestJavaProcess.java: > > > > > > > > 39 public static void main(String argv[]) { > > > > > > > > Nit: Should be "String[] argv" in Java style > > > > > > > > Thanks, > > > > David > > > > > > > > On 10/11/2018 3:18 PM, Daniil Titov wrote: > > > > > Please review the change that fixes serviceability/dcmd/framework/* tests from a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with each other and there are no multiple tests running simultaneously since all they do share the common main class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks like the tests from other directories still might run in parallel with these tests and they also have com.sun.javatest.regtest.agent.MainWrapper as a main class. > > > > > > > > > > The fix ensures that each serviceability/dcmd/framework/* test uses a Java process with a unique main class name when connecting to this process with jcmd and the main class name. > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/ > > > > > > > > > > Best regards, > > > > > Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From david.holmes at oracle.com Fri Feb 8 00:57:46 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Feb 2019 10:57:46 +1000 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: References: <8550b971-eede-c9ce-6eb9-4ec1671dbce3@oracle.com> <3C6EC1EF-672D-4577-9EEF-2CF73BDED256@oracle.com> <2a75f4de-6a77-615e-1648-0fcca59c6ea2@oracle.com> <0B661A5C-E59D-481C-BC3B-0951621F1F51@oracle.com> <5e9c223c-71c5-980e-03b9-679e69942f23@oracle.com> <0194722E-CFE1-4E3A-A521-14910D88B378@oracle.com> <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> <2599EF95-2EC5-4CE7-8036-33D9863631CB@oracle.com> <56cdb16d-f761-7212-cc27-c0f68e882169@oracle.com> <8964269f-9412-b818-8ef0-c9e8b4a22c94@oracle.com> Message-ID: On 8/02/2019 10:53 am, Daniil Titov wrote: > Hi David, > > Currently sun.tools.ProcessHelper is implemented for Linux platform only since it uses the proc filesystem that is limited to Linux platform. As a result the test is limited to Linux platform as well. All recorded timeouts that this change is fixing were reported for Linux platform only. In future we could consider providing the similar functionality for other platforms but it will need to use some different mechanisms. Yep sorry I forgot :) > Please find below the statistics for running this newly added test test/jdk/sun/tools/jcmd/TestProcessHelper.java with linux-x64-debug build in Mach5: > > 1. With Graal ("-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal") - 6s > 2. With Xcomp ("-Xcomp") - 20 s > 3. With Graal and Xcomp ("-Xcomp -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal") - 1m 21s Thanks for that info - that all seems fine. David > Best regards, > Daniil > > ?On 2/7/19, 3:08 PM, "David Holmes" wrote: > > Hi Daniil, > > Thanks for the additional testing. > > On 8/02/2019 3:52 am, Daniil Titov wrote: > > Hi Serguei and David, > > > > Please review a new version of the fix that adds a new test test/jdk/sun/tools/jcmd/TestProcessHelper.java that starts Java processes using different command line options and verifies that sun.tools.ProcessHelper.getMainClass(pid) method returns a correct main class. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.05/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > Why linux only? > > Also wondering how long this will take to run? We need to be mindful of > impact on tier testing. AFAICS this will run in tier3, tier4-graal and > tier8-Xcomp - and it's the last one we may need to watch for time. > > Thanks, > David > > > Thanks! > > -Daniil > > > > > > > > ?On 2/4/19, 2:26 PM, "serguei.spitsyn at oracle.com" wrote: > > > > Hi Daniil, > > > > Thank you for the update! > > > > It looks good in general. > > > > I think, it can be a good idea to add a simple tests for this > > command-line processing. > > It should save us from any surprises. > > > > Thanks, > > Serguei > > > > > > On 2/4/19 13:24, Daniil Titov wrote: > > > Hi Serguei, > > > > > > Thank you for reviewing this fix. > > > > > > Please review a new version of the fix that includes all changes you suggested but one about lines 88-91 and 97-101. > > > > > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > > > 89 i++; > > > 90 continue; > > > 91 } > > > ... > > > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > > > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > > > 99 i++; > > > 100 continue; > > > 101 } > > > 102 // Skip all other Java options > > > 103 if (parts[i].startsWith("-")) { > > > 104 continue; > > > 105 } > > > > > > You are right, these statements are needed to filter out the parts which have nothing to do with the mainClass. But we cannot remove these lines and just return the latest part[i] that was not filtered out as the mainClass since it will not work in the case when the command line includes arguments specified after the main class. In the approach we use the main class is the *first* part[i] (with i > 0) that is not a Java option ( part[i] that doesn't start with '-' and is not classpath, module path, jar file path or module name). This condition that the mainClass is not null is checked on line 89 inside for loop. > > > > > > 89 for (int i = 1; i < parts.length && mainClass == null; i++) { > > > > > > To simplify the code in the new version of the patch the lines 88-91 and 97-101 are combined in the one "if" block. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.04 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > Thanks. > > > --Daniil > > > > > > From: "serguei.spitsyn at oracle.com" > > > Date: Thursday, January 31, 2019 at 1:23 PM > > > To: David Holmes , Daniil Titov , serviceability-dev > > > Subject: Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out > > > > > > Hi Daniil, > > > > > > > > > I have some secondary comment on new file: > > > > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java.html > > > > > > 70 for (int i = 0; i < parts.length && mainClass == null; i++) { > > > 71 // Check the executable > > > 72 if (i == 0) { > > > 73 String[] executablePath = parts[i].split("/"); > > > 74 if (executablePath.length > 0) { > > > 75 String binaryName = executablePath[executablePath.length - 1]; > > > 76 if (!"java".equals(binaryName)) { > > > 77 // Skip the process if it is not started with java launcher > > > 78 return null; > > > 79 } > > > 80 } > > > 81 continue; > > > 82 } > > > > > > It is better execute the logic in lines 73-80 before the loop. > > > It will simplify the code a little bit. > > > String[] executablePath = parts[i].split("/"); > > > if (executablePath.length > 0) { > > > String binaryName = executablePath[executablePath.length - 1]; > > > if (!binaryName.equals("java") { > > > return null; // Skip the process if it is not started with java launcher > > > > > > } > > > } > > > for (int i = 1; i < parts.length && mainClass == null; i++) { > > > > > > In the fragment below: > > > > > > 83 // Check if the module is executed with explicitly specified main class > > > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > > > 85 mainClass = getMainClassFromModuleArg(parts[i + 1]); > > > 86 break; > > > 87 } > > > > > > would it better to just return the main class instead of having a break statement? : > > > 85 return getMainClassFromModuleArg(parts[i + 1]); > > > > > > > > > The lines: > > > 108 if (jarFile != null) { > > > 109 return getMainClassFromJar(jarFile, pid); > > > 110 } > > > > > > is better to execute inside the loop the same as it is done for getMainClassFromModuleArg(). > > > > > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > > if (parts[i].equals("-jar") && i < parts.length - 1) { > > > return getMainClassFromJar(jarFile, pid); > > > } > > > > > > In the if statements: > > > 84 if ((parts[i].equals("-m") || parts[i].equals("--module")) && i < parts.length - 1) { > > > ... > > > 93 if (parts[i].equals("-jar") && i < parts.length - 1) { > > > > > > the last condition (i < parts.length - 1) is better to make the first (pre-condition). > > > They even can be combined together like below: > > > if (i < parts.length - 1) { > > > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > > > return getMainClassFromModuleArg(parts[i + 1]); > > > } > > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > > if (parts[i].equals("-jar") ) { > > > return getMainClassFromJar(jarFile, pid); > > > } > > > } > > > > > > The biggest concern are the fragments: > > > 88 if (parts[i].equals("-p") || parts[i].equals("--module-path")) { > > > 89 i++; > > > 90 continue; > > > 91 } > > > ... > > > 97 // If this is a classpath option then skip the next part as well ( the classpath itself) > > > 98 if (parts[i].equals("-cp") || parts[i].equals("-classpath")) { > > > 99 i++; > > > 100 continue; > > > 101 } > > > 102 // Skip all other Java options > > > 103 if (parts[i].startsWith("-")) { > > > 104 continue; > > > 105 } > > > If I understand it correctly, these statements are needed to filter out > > > the parts which have nothing to do with the mainClass. > > > The latest part[i] that was not filtered out is returned as the mainClass. > > > > > > I'm thinking about more general approach here. Probably, we just need to remove > > > the fragments 88-91 and 97-101 as they are covered by the fragment 102-105. > > > It will also simplify the code. > > > > > > With all the suggestion above it should converge to something like this: > > > String[] parts = cmdLine.split(" "); > > > String mainClass = null; > > > > > > String[] executablePath = parts[i].split("/"); > > > if (executablePath.length > 0) { > > > String binaryName = executablePath[executablePath.length - 1]; > > > if (!binaryName.equals("java") { > > > return null; // Skip the process if it is not started with java launcher > > > > > > } > > > } > > > for (int 1 = 0; i < parts.length && mainClass == null; i++) { > > > if (i < parts.length - 1) { > > > if ((parts[i].equals("-m") || parts[i].equals("--module"))) { > > > return getMainClassFromModuleArg(parts[i + 1]); > > > } > > > // Check if the main class needs to be read from the manifest.mf in a JAR file > > > if (parts[i].equals("-jar") ) { > > > return getMainClassFromJar(parts[i + 1], pid); > > > } > > > } > > > // Skip all other Java options > > > if (parts[i].startsWith("-")) { > > > continue; > > > } > > > mainClass = parts[i]; > > > } > > > return mainClass; > > > > > > > > > http://cr.openjdk.java.net/~dtitov/8205654/webrev.03/test/hotspot/jtreg/serviceability/dcmd/framework/TestJavaProcess.java.html > > > > > > 49 if (cmd.equals("quit")) { > > > 50 log("'quit' received"); > > > 51 > > > 52 } else { > > > > > > The empty line 51 can be removed. > > > > > > Looking at this command-line processing I kind of understand the David's concern. > > > > > > Thanks, > > > Serguei > > > > > > > > > On 1/20/19 21:18, David Holmes wrote: > > > Thanks for the update Daniil. I still remain concerned about the robustness of the command-line parsing - this seems like a feature that needs its own set of tests. > > > > > > I'll leave it up to Serguei and others as to how to proceed. > > > > > > David > > > ----- > > > > > > On 19/01/2019 9:08 am, Daniil Titov wrote: > > > > > > Hi David and Serguei, > > > > > > Please review a new version of the fix that now covers the case when Java executes a module with the main class name explicitly specified in the command line. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.03 > > > Bug: : https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > Thanks! > > > --Daniil > > > > > > ?On 1/8/19, 6:05 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > Hi Daniil, > > > Sorry this slipped through the Xmas break cracks :) > > > On 22/12/2018 12:04 pm, Daniil Titov wrote: > > > > Hi David and Serguei, > > > > > > > > Please review a new version of the fix that for Linux platform uses the proc filesystem to retrieve the main class name for the running Java process. > > > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.02/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > It's more complex than I had envisaged but seems to be doing the job. > > > I'm not sure how robust the command-line parsing is, in particular it > > > doesn't handle these forms: > > > or java [options] -m [/] [args...] > > > java [options] --module [/] [args...] > > > (to execute the main class in a module) > > > I can't really comment on all the details. > > > Thanks, > > > David > > > ----- > > > > Thanks, > > > > Daniil > > > > > > > > ?On 11/29/18, 4:52 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > > > Hi Daniil, > > > > > > > > On 30/11/2018 7:30 am, Daniil Titov wrote: > > > > > Thank you, David! > > > > > > > > > > The proposed fix didn't help. It still hangs at some occasions. Additional tracing showed that when jcmd is invoked with the main class name it iterates over all running Java processes and temporary attaches to them to retrieve the main class name. It hangs while trying to attach to one of the running Java processes. There are numerous Java processes running at the host machine some associated with the test framework itself and another with the tests running in parallel. It is not clear what exact is this particular process since the jcmd hangs before retrieving the process' main class name, but after all tests terminated the process with this id is no longer running. I have to revoke this review since more investigation is required. > > > > > > > > That sounds like an unsolvable problem for the test. You can't control > > > > other Java processes on the machine, and searching by name requires > > > > asking each of them in turn. > > > > > > > > How do we get the list of Java processes in the first place? Perhaps we > > > > need to do some /proc//cmdline peeking? > > > > > > > > Cheers, > > > > David > > > > > > > > > > > > > > Best regards, > > > > > Daniil > > > > > > > > > > > > > > > > > > > > ?On 11/11/18, 1:35 PM, "David Holmes" mailto:david.holmes at oracle.com wrote: > > > > > > > > > > Hi Daniil, > > > > > > > > > > I took a quick look at this one ... two minor comments > > > > > > > > > > The static class names could just be "Process" as they will acquire the > > > > > enclosing class name as part of their own name anyway. As it is this > > > > > gets repeated eg: > > > > > > > > > > HelpTest$HelpTestProcess > > > > > InvalidCommandTest$InvalidCommandTestProcess > > > > > > > > > > TestJavaProcess.java: > > > > > > > > > > 39 public static void main(String argv[]) { > > > > > > > > > > Nit: Should be "String[] argv" in Java style > > > > > > > > > > Thanks, > > > > > David > > > > > > > > > > On 10/11/2018 3:18 PM, Daniil Titov wrote: > > > > > > Please review the change that fixes serviceability/dcmd/framework/* tests from a time out. The fix for JDK-8166642 made serviceability/dcmd/framework/* tests non-concurrent to ensure that they don't interact with each other and there are no multiple tests running simultaneously since all they do share the common main class name com.sun.javatest.regtest.agent.MainWrapper. However, it looks like the tests from other directories still might run in parallel with these tests and they also have com.sun.javatest.regtest.agent.MainWrapper as a main class. > > > > > > > > > > > > The fix ensures that each serviceability/dcmd/framework/* test uses a Java process with a unique main class name when connecting to this process with jcmd and the main class name. > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8205654 > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8205654/webrev.001/ > > > > > > > > > > > > Best regards, > > > > > > Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From gary.adams at oracle.com Fri Feb 8 13:25:01 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 08 Feb 2019 08:25:01 -0500 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out Message-ID: <5C5D832D.6030504@oracle.com> The intermittent failures for remove_l005 appears to be due to a timing issue in the shutdown handling after the test has completed. The debugger has sent a "quit" command, but the debugee has not completed processing the command and exited as expected. This proposed change modifies the Debugee.endDebugee() processing to wait for the debuggee to complete before doing the tear down processing on the debugger side of the connection. This sequencing did expose an issue in the canBeModified test, where the debugee was never resumed after the VMStart event was detected. Resuming the debugee allows it to respond as expected when the direct call to endDebugee is invoked. Testing is still in progress, but it looks like this will resolve a number of tail end intermittent failures. Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/ From gary.adams at oracle.com Fri Feb 8 13:38:33 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 08 Feb 2019 08:38:33 -0500 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <2c8f9efb-a207-19a3-4c39-92c8d0980d8e@oracle.com> References: <5C5845B2.40004@oracle.com> <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> <5C597ED6.3090006@oracle.com> <2c8f9efb-a207-19a3-4c39-92c8d0980d8e@oracle.com> Message-ID: <5C5D8659.9000109@oracle.com> On 2/5/19, 4:59 PM, David Holmes wrote: > On 5/02/2019 10:17 pm, Gary Adams wrote: >> On 2/4/19, 8:04 PM, David Holmes wrote: >>> Hi Gary, >>> >>> On 5/02/2019 12:01 am, Gary Adams wrote: >>>> Two of the redefine classes tests (021, 023) have been on the >>>> ProblemList since they >>>> were first brought into the open repos. Both tests made an >>>> incorrect assumption >>>> about the access modifiers in class files. There is a single bit in >>>> the binary class file that >>>> defines if an interface is public or not public (See JVMS Table >>>> 4.1-B ACC_PUBLIC). >>>> When the test classes are compiled for use in the redefine >>>> operation, if a source >>>> used public or protected the ACC_PUBLIC bit was set. >>>> >>>> Several modifiers are used in these tests to confirm >>>> UnsupportedOperationException >>>> is thrown or not thrown. This proposed change simply corrects the >>>> expected results >>>> according to the JVM Specification. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html >>> >>> test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java >>> >>> >>> 62 * Test cases 3 (private) and 4 (static) map to not public, so will >>> >>> "static" is not related to access modifiers so the ACC_PUBLIC bit is >>> not relevant. "static" can only be applied to (nested) member types >>> and is represented by the ACC_STATIC bit as per JVMS "Table 4.7.6-A. >>> Nested class access and property flags". >>> >>> What this testcase does is add "static" to a nested interface and >>> expects JVM TI to check if the class modifier has changed. But the >>> "static" is not encoded in the class "access flags", but in the >>> inner class attribute (inner_class_access_flags). To me this >>> testcase should throw UOE, but JVM TI is not checking the right flags. >>> >>> David >> I think the test is demonstrating that static does not change the >> ACC_PUBLIC bit. > > And what is that a demonstration of? static has nothing to do with > access control so if it did change the ACC_PUBLIC bit we'd have a > serious issue. > >> >> This changeset does not change the handling of that testcase. > > The test is adding a new class modifier "static" which it originally > expected to trigger a UOE but it doesn't because JVM TI is not > checking for that kind of change correctly. > > You modified the test to no longer expect UOE so that it passes but: > a) that's wrong as it shouldn't pass; and > b) it's now documented as passing because it doesn't change the > public-ness of the class but that's completely irrelevant. > > So your change to the static testcase is not correct and should not be > applied. > > David > ----- I think you misread the webrev. The 4th test case was already being allowed to not throw UOE. The change I proposed allows the 3rd testcase to not throw UOE. e.g. redefining package to private accessibility is still not ACC_PUBLIC. From serguei.spitsyn at oracle.com Fri Feb 8 18:37:18 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 8 Feb 2019 10:37:18 -0800 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: <5C5D832D.6030504@oracle.com> References: <5C5D832D.6030504@oracle.com> Message-ID: Hi Gary, I'm Okay with the fix if the test run is good. Thanks, Serguei On 2/8/19 05:25, Gary Adams wrote: > The intermittent failures for remove_l005 appears to be due to a > timing issue > in the shutdown handling after the test has completed. The debugger > has sent > a "quit" command, but the debugee has not completed processing the > command > and exited as expected. > > This proposed change modifies the Debugee.endDebugee() processing to > wait for the debuggee to complete before doing the tear down processing > on the debugger side of the connection. This sequencing did expose > an issue in the canBeModified test, where the debugee was never resumed > after the VMStart event was detected. Resuming the debugee allows it to > respond as expected when the direct call to endDebugee is invoked. > > Testing is still in progress, but it looks like this will resolve a > number of > tail end intermittent failures. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 > ? Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/ From david.holmes at oracle.com Fri Feb 8 21:48:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Feb 2019 07:48:42 +1000 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <5C5D8659.9000109@oracle.com> References: <5C5845B2.40004@oracle.com> <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> <5C597ED6.3090006@oracle.com> <2c8f9efb-a207-19a3-4c39-92c8d0980d8e@oracle.com> <5C5D8659.9000109@oracle.com> Message-ID: On 8/02/2019 11:38 pm, Gary Adams wrote: > On 2/5/19, 4:59 PM, David Holmes wrote: >> On 5/02/2019 10:17 pm, Gary Adams wrote: >>> On 2/4/19, 8:04 PM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> On 5/02/2019 12:01 am, Gary Adams wrote: >>>>> Two of the redefine classes tests (021, 023) have been on the >>>>> ProblemList since they >>>>> were first brought into the open repos. Both tests made an >>>>> incorrect assumption >>>>> about the access modifiers in class files. There is a single bit in >>>>> the binary class file that >>>>> defines if an interface is public or not public (See JVMS Table >>>>> 4.1-B ACC_PUBLIC). >>>>> When the test classes are compiled for use in the redefine >>>>> operation, if a source >>>>> used public or protected the ACC_PUBLIC bit was set. >>>>> >>>>> Several modifiers are used in these tests to confirm >>>>> UnsupportedOperationException >>>>> is thrown or not thrown. This proposed change simply corrects the >>>>> expected results >>>>> according to the JVM Specification. >>>>> >>>>> ?? Webrev: >>>>> http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html >>>> >>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java >>>> >>>> >>>> 62? * Test cases 3 (private) and 4 (static) map to not public, so will >>>> >>>> "static" is not related to access modifiers so the ACC_PUBLIC bit is >>>> not relevant. "static" can only be applied to (nested) member types >>>> and is represented by the ACC_STATIC bit as per JVMS "Table 4.7.6-A. >>>> Nested class access and property flags". >>>> >>>> What this testcase does is add "static" to a nested interface and >>>> expects JVM TI to check if the class modifier has changed. But the >>>> "static" is not encoded in the class "access flags", but in the >>>> inner class attribute (inner_class_access_flags). To me this >>>> testcase should throw UOE, but JVM TI is not checking the right flags. >>>> >>>> David >>> I think the test is demonstrating that static does not change the >>> ACC_PUBLIC bit. >> >> And what is that a demonstration of? static has nothing to do with >> access control so if it did change the ACC_PUBLIC bit we'd have a >> serious issue. >> >>> >>> This changeset does not change the handling of that testcase. >> >> The test is adding a new class modifier "static" which it originally >> expected to trigger a UOE but it doesn't because JVM TI is not >> checking for that kind of change correctly. >> >> You modified the test to no longer expect UOE so that it passes but: >> a) that's wrong as it shouldn't pass; and >> b) it's now documented as passing because it doesn't change the >> public-ness of the class but that's completely irrelevant. >> >> So your change to the static testcase is not correct and should not be >> applied. >> >> David >> ----- > I think you misread the webrev. > The 4th test case was already being allowed to not throw UOE. > > The change I proposed allows the 3rd testcase to not throw UOE. > e.g. redefining package to private accessibility is still not ACC_PUBLIC. Okay in regards to your changeset this comment is misleading for the static case (public/not-public is not the issue as we aren't changing an access modified - changing the static modifier simply leaves the class modifiers unchanged): 62 * Test cases 3 (private) and 4 (static) map to not public, so will 63 * not throw UnsupportedOperationException during the redefine 64 * class operation. but the whole test is wrong for the "static" case and JVM TI is broken for the static case so I'll file a new bug to get JVM TI and the test fixed. David From jcbeyler at google.com Fri Feb 8 22:26:06 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 8 Feb 2019 14:26:06 -0800 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: References: <5C5D832D.6030504@oracle.com> Message-ID: Hi Gary, Looks good to me too :) Thanks, Jc On Fri, Feb 8, 2019 at 10:40 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Gary, > > I'm Okay with the fix if the test run is good. > > Thanks, > Serguei > > > On 2/8/19 05:25, Gary Adams wrote: > > The intermittent failures for remove_l005 appears to be due to a > > timing issue > > in the shutdown handling after the test has completed. The debugger > > has sent > > a "quit" command, but the debugee has not completed processing the > > command > > and exited as expected. > > > > This proposed change modifies the Debugee.endDebugee() processing to > > wait for the debuggee to complete before doing the tear down processing > > on the debugger side of the connection. This sequencing did expose > > an issue in the canBeModified test, where the debugee was never resumed > > after the VMStart event was detected. Resuming the debugee allows it to > > respond as expected when the direct call to endDebugee is invoked. > > > > Testing is still in progress, but it looks like this will resolve a > > number of > > tail end intermittent failures. > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 > > Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/ > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat Feb 9 02:24:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Feb 2019 12:24:41 +1000 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: References: <5C5845B2.40004@oracle.com> <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> <5C597ED6.3090006@oracle.com> <2c8f9efb-a207-19a3-4c39-92c8d0980d8e@oracle.com> <5C5D8659.9000109@oracle.com> Message-ID: <02d23de0-c143-1f6d-0a41-d21ac85948c6@oracle.com> Gary, I have filed https://bugs.openjdk.java.net/browse/JDK-8218703 against JVM TI. But in doing so I realized these current test changes are actually still incorrect. The problem is that these tests are changing the modifiers on nested types and in that case it is the inner_class_access_flags that JVM TI should be examining (which can encode all four access levels), not the top-level access flag (which only handles public or not-public). This is all rather a mess. David ----- On 9/02/2019 7:48 am, David Holmes wrote: > On 8/02/2019 11:38 pm, Gary Adams wrote: >> On 2/5/19, 4:59 PM, David Holmes wrote: >>> On 5/02/2019 10:17 pm, Gary Adams wrote: >>>> On 2/4/19, 8:04 PM, David Holmes wrote: >>>>> Hi Gary, >>>>> >>>>> On 5/02/2019 12:01 am, Gary Adams wrote: >>>>>> Two of the redefine classes tests (021, 023) have been on the >>>>>> ProblemList since they >>>>>> were first brought into the open repos. Both tests made an >>>>>> incorrect assumption >>>>>> about the access modifiers in class files. There is a single bit >>>>>> in the binary class file that >>>>>> defines if an interface is public or not public (See JVMS Table >>>>>> 4.1-B ACC_PUBLIC). >>>>>> When the test classes are compiled for use in the redefine >>>>>> operation, if a source >>>>>> used public or protected the ACC_PUBLIC bit was set. >>>>>> >>>>>> Several modifiers are used in these tests to confirm >>>>>> UnsupportedOperationException >>>>>> is thrown or not thrown. This proposed change simply corrects the >>>>>> expected results >>>>>> according to the JVM Specification. >>>>>> >>>>>> ?? Webrev: >>>>>> http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html >>>>> >>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java >>>>> >>>>> >>>>> 62? * Test cases 3 (private) and 4 (static) map to not public, so will >>>>> >>>>> "static" is not related to access modifiers so the ACC_PUBLIC bit >>>>> is not relevant. "static" can only be applied to (nested) member >>>>> types and is represented by the ACC_STATIC bit as per JVMS "Table >>>>> 4.7.6-A. Nested class access and property flags". >>>>> >>>>> What this testcase does is add "static" to a nested interface and >>>>> expects JVM TI to check if the class modifier has changed. But the >>>>> "static" is not encoded in the class "access flags", but in the >>>>> inner class attribute (inner_class_access_flags). To me this >>>>> testcase should throw UOE, but JVM TI is not checking the right flags. >>>>> >>>>> David >>>> I think the test is demonstrating that static does not change the >>>> ACC_PUBLIC bit. >>> >>> And what is that a demonstration of? static has nothing to do with >>> access control so if it did change the ACC_PUBLIC bit we'd have a >>> serious issue. >>> >>>> >>>> This changeset does not change the handling of that testcase. >>> >>> The test is adding a new class modifier "static" which it originally >>> expected to trigger a UOE but it doesn't because JVM TI is not >>> checking for that kind of change correctly. >>> >>> You modified the test to no longer expect UOE so that it passes but: >>> a) that's wrong as it shouldn't pass; and >>> b) it's now documented as passing because it doesn't change the >>> public-ness of the class but that's completely irrelevant. >>> >>> So your change to the static testcase is not correct and should not >>> be applied. >>> >>> David >>> ----- >> I think you misread the webrev. >> The 4th test case was already being allowed to not throw UOE. >> >> The change I proposed allows the 3rd testcase to not throw UOE. >> e.g. redefining package to private accessibility is still not ACC_PUBLIC. > > Okay in regards to your changeset this comment is misleading for the > static case (public/not-public is not the issue as we aren't changing an > access modified - changing the static modifier simply leaves the class > modifiers unchanged): > > 62? * Test cases 3 (private) and 4 (static) map to not public, so will > ? 63? * not throw UnsupportedOperationException during the > redefine > ? 64? * class operation. > > but the whole test is wrong for the "static" case and JVM TI is broken > for the static case so I'll file a new bug to get JVM TI and the test > fixed. > > David From daniil.x.titov at oracle.com Sat Feb 9 05:37:39 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 08 Feb 2019 21:37:39 -0800 Subject: RFR 8218705: Test sun/tools/jcmd/TestJcmdDefaults.java fails on Linux Message-ID: Please review the change that fix the test failure. The problem here is that the code in sun.tools.common.ProcessArgumentMatcher.check() method was supposed to fallback to the default mechanism for retrieving the main class name if sun.tools.common.ProcessHelper (recently introduced in JDK-8205654) failed to detect it, but it does not. The change fixes that problem. Webrev: http://cr.openjdk.java.net/~dtitov/8218705/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8218705 Thanks! --Daniil From zanglin5 at jd.com Sat Feb 9 10:52:56 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Sat, 9 Feb 2019 10:52:56 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com>, <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> Message-ID: Thanks All for reviewing the change and CSR, I am still OOTO now and I will update the webrev later and ask your help for review again. Happy Chinese New Year! Cheers, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Wednesday, February 6, 2019 6:44:43 AM To: ??; David Holmes; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Thank you for the fix! It looks good in general. Should it come with a unit test for new flags? http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.frames.html 154 // get the canonical path - important to avoid just 155 // passing a "heap.bin" and having the dump created 156 // in the target VM working directory rather than the 157 // directory where jmap is executed. Minor: Comment need to start with a capital letter: // Get the ... Thanks, Serguei On 1/30/19 10:42 PM, ?? wrote: Hi David, Paul, I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 May I ask your help to review? Thanks! BRs, Lin ________________________________________ From: David Holmes Sent: Thursday, January 31, 2019 9:19:31 AM To: Hohensee, Paul; ??; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo On 31/01/2019 10:41 am, Hohensee, Paul wrote: Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? Yes. Changes to command-line flags need a CSR. Thanks, David Thanks, Paul ?On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. vm.heapHisto("", "-live") Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to * 'vm.heapHisto("", "-live")' will request a full GC In attachListener.cpp, the line out->print_cr("Invalid argument to dumpheap operation: %s", arg1); should be out->print_cr("Invalid argument to inspectheap operation: %s", arg1); Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. Paul On 1/30/19, 12:18 AM, "??" wrote: Dear All, This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. I have identified the root cause of the issue. it is caused by 2 problems. 1. The path processing in heap_inspection() at attachListener.cpp. The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. I have upload a webrev05: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ May I ask your help for review? Thanks, Lin ________________________________________ From: ?? Sent: Monday, January 28, 2019 5:49:42 PM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Dear all, I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. Thanks! BRs, Lin ________________________________________ From: ?? Sent: Friday, January 25, 2019 9:00:19 AM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Dear All, May I get more review about this webrev? http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ Thanks! BRs, Lin ________________________________________ From: ?? Sent: Tuesday, January 22, 2019 2:18:06 PM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Paul, Thanks a lot for your review. I have refined it based on your comments. http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ Would you like to help review it again? Thanks BRs, Lin ________________________________________ From: Hohensee, Paul Sent: Friday, January 18, 2019 6:11:14 AM To: ??; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Just a few small things. In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. In attachListener.cpp, line 275, change "Fail to" to "Failed to". In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. Thanks, Paul On 1/11/19, 1:39 AM, "??" wrote: Hi Jc, Paul and All, Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ would you like to help review? Thanks, Lin ________________________________________ From: ?? Sent: Friday, January 11, 2019 10:25:27 AM To: JC Beyler Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: ??: [RFR]8215622: Add dump to file support for jmap histo Hi Jc, Thanks a lot. it is not a necessary change, I forget to omit it:) BRs, Lin ________________________________ ???: JC Beyler ????: 2019?1?11? 0:58:22 ???: ?? ??: Hohensee, Paul; serviceability-dev at openjdk.java.net ??: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Small nit: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html needs a copyright update, Jc On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: Dear All, I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ Would you like to help review? Thanks! BRs, Lin From: ?? Sent: Wednesday, January 9, 2019 11:00 AM To: 'JC Beyler' > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215622: Add dump to file support for jmap histo Dear JC, Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. Cheers, Lin From: JC Beyler > Sent: Wednesday, January 9, 2019 10:51 AM To: ?? > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Inlined as well :-) On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: Dear JC, Thanks for your comments, I inlined my comments here: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? --- (Lin) I will do that in next webrev. - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. Thanks! Jc All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. Cheers, Lin From: JC Beyler > Sent: Wednesday, January 9, 2019 1:42 AM To: ?? > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, I have a few nits: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html You could fix the spaces arount the for loop you changed: + for (int i=0; i<4; i++) { to + for (int i = 0; i < 4; i++) { http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html + filename = opt.substring(5); + if (filename != null) { -> I don't see how filename can be null here -> same filename could just be declared in the if + } else if (subopt.startsWith("file=")) { + filename = parseFileName(subopt); -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? -> in the option string printouts, you don't specify that all is an option as well, is that normal? The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". Thanks, Jc On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: Hi Paul, I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ Hi All, May I also ask your help for reviewing this webrev? webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 Thanks! Lin ________________________________ ???: serviceability-dev > ?? ?? > ????: 2019?1?3? 10:21 ???: Hohensee, Paul; serviceability-dev at openjdk.java.net ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo Dear Paul, Thanks a lot for your review! I am trying to remend the patch One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would be more reasonable than the ?if else? ? Thanks BRs, Lin From: Hohensee, Paul > Sent: Saturday, December 29, 2018 3:54 AM To: ?? >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Update the copyright dates to 2019 please, since this won?t get pushed until then. In JMap.java, I?d emulate dump() and use String filename = null; String subopts[] = options.split(","); for (String subopt : subopts){ if (subopt.isEmpty() || subopt.equals("all")) { // pass } else if (subopt.equals("live")) { liveopt = "-live"; } else if (subopt.startsWith("file=")) { // file= - check that is specified if (subopt.length() > 5) { filename = subopt.substring(5); } } else { usage(1); } } // get the canonical path - important to avoid just passing // a "heap.bin" and having the dump created in the target VM // working directory rather than the directory where jmap // is executed. filename = new File(filename).getCanonicalPath(); // inspectHeap is not the same as jcmd GC.class_histogram executeCommandForPid(pid, "inspectheap", filename, liveopt); I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. Thanks, Paul From: serviceability-dev > on behalf of ?? > Date: Thursday, December 20, 2018 at 11:03 PM To: "serviceability-dev at openjdk.java.net" > Subject: [RFR]8215622: Add dump to file support for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -- Thanks, Jc From david.holmes at oracle.com Sat Feb 9 12:31:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 9 Feb 2019 22:31:09 +1000 Subject: RFR 8218705: Test sun/tools/jcmd/TestJcmdDefaults.java fails on Linux In-Reply-To: References: Message-ID: <8bf576da-8ebf-4e3a-b799-b508a0730c58@oracle.com> Hi Daniil, The fix seems reasonable. These tests should all have been run before pushing JDK-8205654. Thanks, David ------ On 9/02/2019 3:37 pm, Daniil Titov wrote: > Please review the change that fix the test failure. > > The problem here is that the code in sun.tools.common.ProcessArgumentMatcher.check() method was supposed to fallback to the default mechanism for retrieving the main class name if sun.tools.common.ProcessHelper (recently introduced in JDK-8205654) failed to detect it, but it does not. The change fixes that problem. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218705/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218705 > > Thanks! > --Daniil > > From gary.adams at oracle.com Sat Feb 9 13:29:48 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Sat, 9 Feb 2019 08:29:48 -0500 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <02d23de0-c143-1f6d-0a41-d21ac85948c6@oracle.com> References: <5C5845B2.40004@oracle.com> <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> <5C597ED6.3090006@oracle.com> <2c8f9efb-a207-19a3-4c39-92c8d0980d8e@oracle.com> <5C5D8659.9000109@oracle.com> <02d23de0-c143-1f6d-0a41-d21ac85948c6@oracle.com> Message-ID: <78fbfd19-b611-62d9-55e3-c8cc729cbf59@oracle.com> I'm willing to do the leg work on cleaning up the tests, but I'll need some help identifying where the redefine operations are missing the inner_class_flags checks. Is spec change or a CSR required when we change the current behavior to be more strict? On 2/8/19 9:24 PM, David Holmes wrote: > Gary, > > I have filed > > https://bugs.openjdk.java.net/browse/JDK-8218703 > > against JVM TI. But in doing so I realized these current test changes > are actually still incorrect. The problem is that these tests are > changing the modifiers on nested types and in that case it is the > inner_class_access_flags that JVM TI should be examining (which can > encode all four access levels), not the top-level access flag (which > only handles public or not-public). > > This is all rather a mess. > > David > ----- > > On 9/02/2019 7:48 am, David Holmes wrote: >> On 8/02/2019 11:38 pm, Gary Adams wrote: >>> On 2/5/19, 4:59 PM, David Holmes wrote: >>>> On 5/02/2019 10:17 pm, Gary Adams wrote: >>>>> On 2/4/19, 8:04 PM, David Holmes wrote: >>>>>> Hi Gary, >>>>>> >>>>>> On 5/02/2019 12:01 am, Gary Adams wrote: >>>>>>> Two of the redefine classes tests (021, 023) have been on the >>>>>>> ProblemList since they >>>>>>> were first brought into the open repos. Both tests made an >>>>>>> incorrect assumption >>>>>>> about the access modifiers in class files. There is a single bit >>>>>>> in the binary class file that >>>>>>> defines if an interface is public or not public (See JVMS Table >>>>>>> 4.1-B ACC_PUBLIC). >>>>>>> When the test classes are compiled for use in the redefine >>>>>>> operation, if a source >>>>>>> used public or protected the ACC_PUBLIC bit was set. >>>>>>> >>>>>>> Several modifiers are used in these tests to confirm >>>>>>> UnsupportedOperationException >>>>>>> is thrown or not thrown. This proposed change simply corrects >>>>>>> the expected results >>>>>>> according to the JVM Specification. >>>>>>> >>>>>>> ?? Webrev: >>>>>>> http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html >>>>>> >>>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java >>>>>> >>>>>> >>>>>> 62? * Test cases 3 (private) and 4 (static) map to not public, so >>>>>> will >>>>>> >>>>>> "static" is not related to access modifiers so the ACC_PUBLIC bit >>>>>> is not relevant. "static" can only be applied to (nested) member >>>>>> types and is represented by the ACC_STATIC bit as per JVMS "Table >>>>>> 4.7.6-A. Nested class access and property flags". >>>>>> >>>>>> What this testcase does is add "static" to a nested interface and >>>>>> expects JVM TI to check if the class modifier has changed. But >>>>>> the "static" is not encoded in the class "access flags", but in >>>>>> the inner class attribute (inner_class_access_flags). To me this >>>>>> testcase should throw UOE, but JVM TI is not checking the right >>>>>> flags. >>>>>> >>>>>> David >>>>> I think the test is demonstrating that static does not change the >>>>> ACC_PUBLIC bit. >>>> >>>> And what is that a demonstration of? static has nothing to do with >>>> access control so if it did change the ACC_PUBLIC bit we'd have a >>>> serious issue. >>>> >>>>> >>>>> This changeset does not change the handling of that testcase. >>>> >>>> The test is adding a new class modifier "static" which it >>>> originally expected to trigger a UOE but it doesn't because JVM TI >>>> is not checking for that kind of change correctly. >>>> >>>> You modified the test to no longer expect UOE so that it passes but: >>>> a) that's wrong as it shouldn't pass; and >>>> b) it's now documented as passing because it doesn't change the >>>> public-ness of the class but that's completely irrelevant. >>>> >>>> So your change to the static testcase is not correct and should not >>>> be applied. >>>> >>>> David >>>> ----- >>> I think you misread the webrev. >>> The 4th test case was already being allowed to not throw UOE. >>> >>> The change I proposed allows the 3rd testcase to not throw UOE. >>> e.g. redefining package to private accessibility is still not >>> ACC_PUBLIC. >> >> Okay in regards to your changeset this comment is misleading for the >> static case (public/not-public is not the issue as we aren't changing >> an access modified - changing the static modifier simply leaves the >> class modifiers unchanged): >> >> 62? * Test cases 3 (private) and 4 (static) map to not public, so will >> ?? 63? * not throw UnsupportedOperationException during >> the redefine >> ?? 64? * class operation. >> >> but the whole test is wrong for the "static" case and JVM TI is >> broken for the static case so I'll file a new bug to get JVM TI and >> the test fixed. >> >> David From daniil.x.titov at oracle.com Sat Feb 9 17:18:36 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Sat, 09 Feb 2019 09:18:36 -0800 Subject: RFR 8218705: Test sun/tools/jcmd/TestJcmdDefaults.java fails on Linux In-Reply-To: <8bf576da-8ebf-4e3a-b799-b508a0730c58@oracle.com> References: <8bf576da-8ebf-4e3a-b799-b508a0730c58@oracle.com> Message-ID: <97D17F82-4F96-4A3A-828D-784C21FFEAB5@oracle.com> Hi David, Thank you for reviewing this change. You are right, these tests should be run before pushing JDK-8218705. I apologize for that. I run the usual set (tier1,tier2,tier3 and serviceability tests) but it was not enough in this case. Best regards, Daniil ?On 2/9/19, 4:31 AM, "David Holmes" wrote: Hi Daniil, The fix seems reasonable. These tests should all have been run before pushing JDK-8205654. Thanks, David ------ On 9/02/2019 3:37 pm, Daniil Titov wrote: > Please review the change that fix the test failure. > > The problem here is that the code in sun.tools.common.ProcessArgumentMatcher.check() method was supposed to fallback to the default mechanism for retrieving the main class name if sun.tools.common.ProcessHelper (recently introduced in JDK-8205654) failed to detect it, but it does not. The change fixes that problem. > > Webrev: http://cr.openjdk.java.net/~dtitov/8218705/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8218705 > > Thanks! > --Daniil > > From david.holmes at oracle.com Sun Feb 10 01:03:43 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 10 Feb 2019 11:03:43 +1000 Subject: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier In-Reply-To: <78fbfd19-b611-62d9-55e3-c8cc729cbf59@oracle.com> References: <5C5845B2.40004@oracle.com> <6986e15c-0970-a2ea-42e8-dab2088ca8f6@oracle.com> <5C597ED6.3090006@oracle.com> <2c8f9efb-a207-19a3-4c39-92c8d0980d8e@oracle.com> <5C5D8659.9000109@oracle.com> <02d23de0-c143-1f6d-0a41-d21ac85948c6@oracle.com> <78fbfd19-b611-62d9-55e3-c8cc729cbf59@oracle.com> Message-ID: <5b6bb482-e277-8845-5bc3-6460cbe8dabf@oracle.com> On 9/02/2019 11:29 pm, gary.adams at oracle.com wrote: > I'm willing to do the leg work on cleaning up the tests, but I'll need > some help > identifying where the redefine operations are missing the > inner_class_flags checks. src/hotspot/share/prims/jvmtiRedefineClasses.cpp This code needs expanding: // Check whether class modifiers are the same. jushort old_flags = (jushort) the_class->access_flags().get_flags(); jushort new_flags = (jushort) scratch_class->access_flags().get_flags(); if (old_flags != new_flags) { return JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_MODIFIERS_CHANGED; } to check if the class being redefined is a nested class, and if so to check the inner_class_flags. I don't know how to determine if the class/interface is nested though - I find the inner-class-attribute very confusing. Note you'll have to check the tests carefully to ensure they are in fact redefining a nest class with a nested class. Depending on the mechanism used they may just be defining a top-level class with a $ in its name, and treating it as a nested class. > Is spec change or a CSR required when we change the current behavior to > be more strict? A CSR request for the expanded behaviour is probably in order. There's no spec change here - the spec says modifiers must not be changed. Thanks, David ----- > On 2/8/19 9:24 PM, David Holmes wrote: >> Gary, >> >> I have filed >> >> https://bugs.openjdk.java.net/browse/JDK-8218703 >> >> against JVM TI. But in doing so I realized these current test changes >> are actually still incorrect. The problem is that these tests are >> changing the modifiers on nested types and in that case it is the >> inner_class_access_flags that JVM TI should be examining (which can >> encode all four access levels), not the top-level access flag (which >> only handles public or not-public). >> >> This is all rather a mess. >> >> David >> ----- >> >> On 9/02/2019 7:48 am, David Holmes wrote: >>> On 8/02/2019 11:38 pm, Gary Adams wrote: >>>> On 2/5/19, 4:59 PM, David Holmes wrote: >>>>> On 5/02/2019 10:17 pm, Gary Adams wrote: >>>>>> On 2/4/19, 8:04 PM, David Holmes wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> On 5/02/2019 12:01 am, Gary Adams wrote: >>>>>>>> Two of the redefine classes tests (021, 023) have been on the >>>>>>>> ProblemList since they >>>>>>>> were first brought into the open repos. Both tests made an >>>>>>>> incorrect assumption >>>>>>>> about the access modifiers in class files. There is a single bit >>>>>>>> in the binary class file that >>>>>>>> defines if an interface is public or not public (See JVMS Table >>>>>>>> 4.1-B ACC_PUBLIC). >>>>>>>> When the test classes are compiled for use in the redefine >>>>>>>> operation, if a source >>>>>>>> used public or protected the ACC_PUBLIC bit was set. >>>>>>>> >>>>>>>> Several modifiers are used in these tests to confirm >>>>>>>> UnsupportedOperationException >>>>>>>> is thrown or not thrown. This proposed change simply corrects >>>>>>>> the expected results >>>>>>>> according to the JVM Specification. >>>>>>>> >>>>>>>> ?? Webrev: >>>>>>>> http://cr.openjdk.java.net/~gadams/8065773/webrev.00/index.html >>>>>>> >>>>>>> test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021.java >>>>>>> >>>>>>> >>>>>>> 62? * Test cases 3 (private) and 4 (static) map to not public, so >>>>>>> will >>>>>>> >>>>>>> "static" is not related to access modifiers so the ACC_PUBLIC bit >>>>>>> is not relevant. "static" can only be applied to (nested) member >>>>>>> types and is represented by the ACC_STATIC bit as per JVMS "Table >>>>>>> 4.7.6-A. Nested class access and property flags". >>>>>>> >>>>>>> What this testcase does is add "static" to a nested interface and >>>>>>> expects JVM TI to check if the class modifier has changed. But >>>>>>> the "static" is not encoded in the class "access flags", but in >>>>>>> the inner class attribute (inner_class_access_flags). To me this >>>>>>> testcase should throw UOE, but JVM TI is not checking the right >>>>>>> flags. >>>>>>> >>>>>>> David >>>>>> I think the test is demonstrating that static does not change the >>>>>> ACC_PUBLIC bit. >>>>> >>>>> And what is that a demonstration of? static has nothing to do with >>>>> access control so if it did change the ACC_PUBLIC bit we'd have a >>>>> serious issue. >>>>> >>>>>> >>>>>> This changeset does not change the handling of that testcase. >>>>> >>>>> The test is adding a new class modifier "static" which it >>>>> originally expected to trigger a UOE but it doesn't because JVM TI >>>>> is not checking for that kind of change correctly. >>>>> >>>>> You modified the test to no longer expect UOE so that it passes but: >>>>> a) that's wrong as it shouldn't pass; and >>>>> b) it's now documented as passing because it doesn't change the >>>>> public-ness of the class but that's completely irrelevant. >>>>> >>>>> So your change to the static testcase is not correct and should not >>>>> be applied. >>>>> >>>>> David >>>>> ----- >>>> I think you misread the webrev. >>>> The 4th test case was already being allowed to not throw UOE. >>>> >>>> The change I proposed allows the 3rd testcase to not throw UOE. >>>> e.g. redefining package to private accessibility is still not >>>> ACC_PUBLIC. >>> >>> Okay in regards to your changeset this comment is misleading for the >>> static case (public/not-public is not the issue as we aren't changing >>> an access modified - changing the static modifier simply leaves the >>> class modifiers unchanged): >>> >>> 62? * Test cases 3 (private) and 4 (static) map to not public, so will >>> ?? 63? * not throw UnsupportedOperationException during >>> the redefine >>> ?? 64? * class operation. >>> >>> but the whole test is wrong for the "static" case and JVM TI is >>> broken for the static case so I'll file a new bug to get JVM TI and >>> the test fixed. >>> >>> David > > From serguei.spitsyn at oracle.com Sun Feb 10 20:43:17 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sun, 10 Feb 2019 12:43:17 -0800 Subject: RFR 8218705: Test sun/tools/jcmd/TestJcmdDefaults.java fails on Linux In-Reply-To: <8bf576da-8ebf-4e3a-b799-b508a0730c58@oracle.com> References: <8bf576da-8ebf-4e3a-b799-b508a0730c58@oracle.com> Message-ID: <024ff6ac-ce59-2d29-ec73-dd58467c0d28@oracle.com> Hi Daniil, +1 Thanks, Serguei On 2/9/19 04:31, David Holmes wrote: > Hi Daniil, > > The fix seems reasonable. > > These tests should all have been run before pushing JDK-8205654. > > Thanks, > David > ------ > > On 9/02/2019 3:37 pm, Daniil Titov wrote: >> Please review the change that fix the test failure. >> >> The problem here is that the code in >> sun.tools.common.ProcessArgumentMatcher.check() method was supposed >> to fallback to the default mechanism for retrieving the main class >> name if? sun.tools.common.ProcessHelper (recently introduced in >> JDK-8205654) failed to detect it, but it does not. The change fixes >> that problem. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8218705/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218705 >> >> Thanks! >> --Daniil >> >> From chris.plummer at oracle.com Mon Feb 11 03:20:46 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 10 Feb 2019 19:20:46 -0800 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: References: <5C5D832D.6030504@oracle.com> Message-ID: <5a4ccd0d-58fe-77ce-efa7-9f59a2066faa@oracle.com> An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Mon Feb 11 07:47:32 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 08:47:32 +0100 Subject: RFR: 8218731: SA: Use concrete class the as return type of VMObjectFactory.newObject Message-ID: <5e050e49-2f05-bed8-a7da-96fd2cbcf120@oracle.com> Hi all, I propose this simple change to use the concrete class as the return type of VMObjectFactory.newObject. https://cr.openjdk.java.net/~stefank/8218731/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8218731 This allows us to specify the class only once when calling newObject. For example, now we can use: return VMObjectFactory.newObject(ZPhysicalMemoryManager.class, physicalAddr); Instead of having to write: ?????? return (ZPhysicalMemoryManager)VMObjectFactory.newObject(ZPhysicalMemoryManager.class, physicalAddr); Thanks, StefanK From stefan.karlsson at oracle.com Mon Feb 11 07:53:26 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 08:53:26 +0100 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly Message-ID: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> Hi all, Please review this small patch to resolve ZPageAllocator::_physical as a value object instead of a pointer. https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218732 This fixes the Heap Parameters view. Thanks, StefanK From stefan.karlsson at oracle.com Mon Feb 11 08:13:47 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 09:13:47 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() Message-ID: Hi all, Please review this patch to remove the broken implementation of CollectedHeap used() and capacity() and instead force all GCs to provide their own implementations. https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218733 This was found while running serviceability/sa/TestHeapDumpForLargeArray.java on an experimental implementation of heap dumping in ZGC. ZGC didn't provide a ZCollectedHeap.used() function and CollectedHeap.used() was used instead at: ????????// Check weather we should dump the heap as segments ????????useSegmentedHeapDump = vm.getUniverse().heap().used() > HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; Because of this we incorrectly did not use segmented heap dumps, and therefore overflowed later in the code Aleksey and Roman, Could you verify that the implementation for Epsilon is correct? I also haven't implemented capacity for Shenandoah, as the information isn't trivially available in the ShenandoahHeap SA class. Do you want to fix it as part of this patch, or should I create a separate RFE for Shenandoah? Thanks, StefanK From stefan.karlsson at oracle.com Mon Feb 11 08:39:54 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 09:39:54 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles Message-ID: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> Hi all, Please review this patch to fix the resolving of oops inside the (VM) OopHandles. https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218734 Before this patch the OopHandle::_obj was assumed to be located at offset 0, and the SA resolved OopHandle (Klass::_java_mirror and ClassLoaderData::_class_loader) without the required load barrier for ZGC. I've added a new class VMOopHandle (The SA already has a OopHandle), which handles the resolving (load or load + barrier). The OopHandle type is grouped under the Oops section in vmStructs.cpp. It's not an oop, so I added a newline to separate it out from the rest. Any suggestion of a better location in that file? Tested with the jtreg tests in serviceability/sa + patches to make ZGC usable with the SA's hprof dumping. Thanks, StefanK From shade at redhat.com Mon Feb 11 09:39:33 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 11 Feb 2019 10:39:33 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: References: Message-ID: <754320b6-65ac-cc9f-db0e-c45b7c068c94@redhat.com> On 2/11/19 9:13 AM, Stefan Karlsson wrote: > Please review this patch to remove the broken implementation of CollectedHeap used() and capacity() > and instead force all GCs to provide their own implementations. > > https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ Looks good. > Could you verify that the implementation for Epsilon is correct? I also haven't implemented capacity > for Shenandoah, as the information isn't trivially available in the ShenandoahHeap SA class. Do you > want to fix it as part of this patch, or should I create a separate RFE for Shenandoah? Epsilon change looks trivially correct. For Shenandoah, I think this would suffice: @Override public long capacity() { - // FIXME - return 0; + return numOfRegions() * ShenandoahHeapRegion.regionSizeBytes(); } -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From stefan.karlsson at oracle.com Mon Feb 11 09:52:06 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 10:52:06 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: <754320b6-65ac-cc9f-db0e-c45b7c068c94@redhat.com> References: <754320b6-65ac-cc9f-db0e-c45b7c068c94@redhat.com> Message-ID: <94b6a59b-4642-ba0b-6de6-1c8d1bcdf9fa@oracle.com> On 2019-02-11 10:39, Aleksey Shipilev wrote: > On 2/11/19 9:13 AM, Stefan Karlsson wrote: >> Please review this patch to remove the broken implementation of CollectedHeap used() and capacity() >> and instead force all GCs to provide their own implementations. >> >> https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ > > Looks good. Thanks! > > >> Could you verify that the implementation for Epsilon is correct? I also haven't implemented capacity >> for Shenandoah, as the information isn't trivially available in the ShenandoahHeap SA class. Do you >> want to fix it as part of this patch, or should I create a separate RFE for Shenandoah? > > Epsilon change looks trivially correct. > > For Shenandoah, I think this would suffice: > > @Override > public long capacity() { > - // FIXME > - return 0; > + return numOfRegions() * ShenandoahHeapRegion.regionSizeBytes(); > } I'll incorporate that into the patch. Thanks, StefanK > > -Aleksey > From stefan.karlsson at oracle.com Mon Feb 11 12:00:42 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 13:00:42 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: <7bfe3236-b742-7ad3-6775-323e448856c8@oracle.com> References: <7bfe3236-b742-7ad3-6775-323e448856c8@oracle.com> Message-ID: <3f1968db-1db7-d535-c397-f5c544ce1224@oracle.com> Thanks, Jini. StefanK On 2019-02-11 13:00, Jini George wrote: > Hi Stefan, > > Looks good to me. > > Thanks, > Jini. > > On 2/11/2019 1:43 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove the broken implementation of >> CollectedHeap used() and capacity() and instead force all GCs to >> provide their own implementations. >> >> https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218733 >> >> This was found while running >> serviceability/sa/TestHeapDumpForLargeArray.java on an experimental >> implementation of heap dumping in ZGC. >> >> ZGC didn't provide a ZCollectedHeap.used() function and >> CollectedHeap.used() was used instead at: >> ?????????// Check weather we should dump the heap as segments >> ?????????useSegmentedHeapDump = vm.getUniverse().heap().used() > >> HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; >> >> Because of this we incorrectly did not use segmented heap dumps, and >> therefore overflowed later in the code >> >> Aleksey and Roman, >> >> Could you verify that the implementation for Epsilon is correct? I >> also haven't implemented capacity for Shenandoah, as the information >> isn't trivially available in the ShenandoahHeap SA class. Do you want >> to fix it as part of this patch, or should I create a separate RFE for >> Shenandoah? >> >> Thanks, >> StefanK From jini.george at oracle.com Mon Feb 11 12:00:24 2019 From: jini.george at oracle.com (Jini George) Date: Mon, 11 Feb 2019 17:30:24 +0530 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: References: Message-ID: <7bfe3236-b742-7ad3-6775-323e448856c8@oracle.com> Hi Stefan, Looks good to me. Thanks, Jini. On 2/11/2019 1:43 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove the broken implementation of > CollectedHeap used() and capacity() and instead force all GCs to provide > their own implementations. > > https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218733 > > This was found while running > serviceability/sa/TestHeapDumpForLargeArray.java on an experimental > implementation of heap dumping in ZGC. > > ZGC didn't provide a ZCollectedHeap.used() function and > CollectedHeap.used() was used instead at: > ????????// Check weather we should dump the heap as segments > ????????useSegmentedHeapDump = vm.getUniverse().heap().used() > > HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; > > Because of this we incorrectly did not use segmented heap dumps, and > therefore overflowed later in the code > > Aleksey and Roman, > > Could you verify that the implementation for Epsilon is correct? I also > haven't implemented capacity for Shenandoah, as the information isn't > trivially available in the ShenandoahHeap SA class. Do you want to fix > it as part of this patch, or should I create a separate RFE for Shenandoah? > > Thanks, > StefanK From stefan.karlsson at oracle.com Mon Feb 11 12:36:57 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 13:36:57 +0100 Subject: RFR: 8218743: SA: Add support for large bitmaps Message-ID: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> Hi all, Please review this patch to add support for large bitmaps in the SA. http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218743 I've added a minimal interface (at, atPut, clear) that uses longs instead of ints, and changed MarkBits to use this interface. I've implemented a segmented bitmap that, currently, all GCs use when asked for a bitmap in MarkBits. Later ZGC will provide its own discontiguous bitmap, implementing the new interface, but that will be sent out as a separate RFE. I've tested this with a temporary patch that lowers the segment size and implements a jtreg test: http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 I ran through the all the tests in serviceability/sa with both these patches. Thanks, StefanK From zanglin5 at jd.com Mon Feb 11 12:54:01 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Mon, 11 Feb 2019 12:54:01 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com>, <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com>, Message-ID: <4d75a7134165433e8dc1ecacd1f564dd@jd.com> Dear All, Thanks your time for review. I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.07/. Would you like to help review again? And here are what I have done in this update. * Refined the spec of JMap -histo based on Joe's comments in the CSR https://bugs.openjdk.java.net/browse/JDK-8218131 * Added the unit test for JMap based on Serguei's comments. * Fixed the comments format. Thanks ! Cheers, Lin ________________________________________ From: ?? Sent: Saturday, February 9, 2019 18:52 To: serguei.spitsyn at oracle.com; David Holmes; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Thanks All for reviewing the change and CSR, I am still OOTO now and I will update the webrev later and ask your help for review again. Happy Chinese New Year! Cheers, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Wednesday, February 6, 2019 6:44:43 AM To: ??; David Holmes; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Thank you for the fix! It looks good in general. Should it come with a unit test for new flags? http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.frames.html 154 // get the canonical path - important to avoid just 155 // passing a "heap.bin" and having the dump created 156 // in the target VM working directory rather than the 157 // directory where jmap is executed. Minor: Comment need to start with a capital letter: // Get the ... Thanks, Serguei On 1/30/19 10:42 PM, ?? wrote: Hi David, Paul, I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 May I ask your help to review? Thanks! BRs, Lin ________________________________________ From: David Holmes Sent: Thursday, January 31, 2019 9:19:31 AM To: Hohensee, Paul; ??; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo On 31/01/2019 10:41 am, Hohensee, Paul wrote: Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? Yes. Changes to command-line flags need a CSR. Thanks, David Thanks, Paul ?On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. vm.heapHisto("", "-live") Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to * 'vm.heapHisto("", "-live")' will request a full GC In attachListener.cpp, the line out->print_cr("Invalid argument to dumpheap operation: %s", arg1); should be out->print_cr("Invalid argument to inspectheap operation: %s", arg1); Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. Paul On 1/30/19, 12:18 AM, "??" wrote: Dear All, This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. I have identified the root cause of the issue. it is caused by 2 problems. 1. The path processing in heap_inspection() at attachListener.cpp. The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. I have upload a webrev05: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ May I ask your help for review? Thanks, Lin ________________________________________ From: ?? Sent: Monday, January 28, 2019 5:49:42 PM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Dear all, I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. Thanks! BRs, Lin ________________________________________ From: ?? Sent: Friday, January 25, 2019 9:00:19 AM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Dear All, May I get more review about this webrev? http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ Thanks! BRs, Lin ________________________________________ From: ?? Sent: Tuesday, January 22, 2019 2:18:06 PM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Paul, Thanks a lot for your review. I have refined it based on your comments. http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ Would you like to help review it again? Thanks BRs, Lin ________________________________________ From: Hohensee, Paul Sent: Friday, January 18, 2019 6:11:14 AM To: ??; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Just a few small things. In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. In attachListener.cpp, line 275, change "Fail to" to "Failed to". In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. Thanks, Paul On 1/11/19, 1:39 AM, "??" wrote: Hi Jc, Paul and All, Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ would you like to help review? Thanks, Lin ________________________________________ From: ?? Sent: Friday, January 11, 2019 10:25:27 AM To: JC Beyler Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: ??: [RFR]8215622: Add dump to file support for jmap histo Hi Jc, Thanks a lot. it is not a necessary change, I forget to omit it:) BRs, Lin ________________________________ ???: JC Beyler ????: 2019?1?11? 0:58:22 ???: ?? ??: Hohensee, Paul; serviceability-dev at openjdk.java.net ??: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Small nit: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html needs a copyright update, Jc On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: Dear All, I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ Would you like to help review? Thanks! BRs, Lin From: ?? Sent: Wednesday, January 9, 2019 11:00 AM To: 'JC Beyler' > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215622: Add dump to file support for jmap histo Dear JC, Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. Cheers, Lin From: JC Beyler > Sent: Wednesday, January 9, 2019 10:51 AM To: ?? > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Inlined as well :-) On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: Dear JC, Thanks for your comments, I inlined my comments here: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? --- (Lin) I will do that in next webrev. - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. Thanks! Jc All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. Cheers, Lin From: JC Beyler > Sent: Wednesday, January 9, 2019 1:42 AM To: ?? > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, I have a few nits: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html You could fix the spaces arount the for loop you changed: + for (int i=0; i<4; i++) { to + for (int i = 0; i < 4; i++) { http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html + filename = opt.substring(5); + if (filename != null) { -> I don't see how filename can be null here -> same filename could just be declared in the if + } else if (subopt.startsWith("file=")) { + filename = parseFileName(subopt); -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? -> in the option string printouts, you don't specify that all is an option as well, is that normal? The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". Thanks, Jc On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: Hi Paul, I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ Hi All, May I also ask your help for reviewing this webrev? webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 Thanks! Lin ________________________________ ???: serviceability-dev > ?? ?? > ????: 2019?1?3? 10:21 ???: Hohensee, Paul; serviceability-dev at openjdk.java.net ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo Dear Paul, Thanks a lot for your review! I am trying to remend the patch One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would be more reasonable than the ?if else? ? Thanks BRs, Lin From: Hohensee, Paul > Sent: Saturday, December 29, 2018 3:54 AM To: ?? >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Update the copyright dates to 2019 please, since this won?t get pushed until then. In JMap.java, I?d emulate dump() and use String filename = null; String subopts[] = options.split(","); for (String subopt : subopts){ if (subopt.isEmpty() || subopt.equals("all")) { // pass } else if (subopt.equals("live")) { liveopt = "-live"; } else if (subopt.startsWith("file=")) { // file= - check that is specified if (subopt.length() > 5) { filename = subopt.substring(5); } } else { usage(1); } } // get the canonical path - important to avoid just passing // a "heap.bin" and having the dump created in the target VM // working directory rather than the directory where jmap // is executed. filename = new File(filename).getCanonicalPath(); // inspectHeap is not the same as jcmd GC.class_histogram executeCommandForPid(pid, "inspectheap", filename, liveopt); I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. Thanks, Paul From: serviceability-dev > on behalf of ?? > Date: Thursday, December 20, 2018 at 11:03 PM To: "serviceability-dev at openjdk.java.net" > Subject: [RFR]8215622: Add dump to file support for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -- Thanks, Jc From stefan.karlsson at oracle.com Mon Feb 11 13:55:15 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 14:55:15 +0100 Subject: RFR: 8218746: SA: Implement discontiguous bitmap for ZGC Message-ID: Hi all, Please review this patch to implement a discontiuous bitmap for ZGC in the SA. http://cr.openjdk.java.net/~stefank/8218746/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218746 ZGC uses a 16TB virtual memory address range, so the normal scheme to map a bitmap over the entire address range uses too much memory. This patch lazily creates smaller bitmaps per ZPage, when at() or atPut() is called. This patch builds upon JDK-8218743. Tested with serviceability/sa and manually running Reverse Object Analysis in the SA. Thanks, StefanK From ioi.lam at oracle.com Mon Feb 11 17:23:29 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 11 Feb 2019 09:23:29 -0800 Subject: RFR(S) 8218751 Do not store original classfiles inside the CDS archive Message-ID: http://cr.openjdk.java.net/~iklam/jdk13/8218751-dont-store-classfiles-in-cds.v01/ https://bugs.openjdk.java.net/browse/JDK-8218751 For JVMTI ClassFileLoadHook support, the CDS archive currently stores the original classfile data of all archived classes. However, this consists of over 30% of the archive size. Because all original classfile data are already available in other files (such as the JDK lib/modules file, or JAR files in the classpath), we can simply read from these locations when needed by JVMTI. For the default CDS archive (included as part of the JDK distribution), the size is reduced from about 18.5MB to 12.1MB on Linux/x64. Thanks - Ioi From jini.george at oracle.com Mon Feb 11 18:00:04 2019 From: jini.george at oracle.com (Jini George) Date: Mon, 11 Feb 2019 23:30:04 +0530 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly In-Reply-To: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> References: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> Message-ID: <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> Hi Stefan, Looks good to me overall. One point though. physicalFieldOffset = type.getAddressField("_physical").getOffset(); Wrt the line above, is there any reason due to which getAddressField() instead of getField() was used ? getAddressField() is typically used when the field to be read in is a pointer. I feel getField() might be more appropriate in this situation. Thanks, Jini. On 2/11/2019 1:23 PM, Stefan Karlsson wrote: > Hi all, > > Please review this small patch to resolve ZPageAllocator::_physical as a > value object instead of a pointer. > > https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218732 > > This fixes the Heap Parameters view. > > Thanks, > StefanK From stefan.karlsson at oracle.com Mon Feb 11 18:09:29 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 11 Feb 2019 19:09:29 +0100 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly In-Reply-To: <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> References: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> Message-ID: <8c0505a1-c5d7-8de6-057d-4603d43df2c8@oracle.com> Hi Jini, On 2019-02-11 19:00, Jini George wrote: > Hi Stefan, > > Looks good to me overall. One point though. > > physicalFieldOffset = type.getAddressField("_physical").getOffset(); > > Wrt the line above, is there any reason due to which getAddressField() > instead of getField() was used ? getAddressField() is typically used > when the field to be read in is a pointer. I feel getField() might be > more appropriate in this situation. No, this is just an oversight. I have the same issue in my later OopHandle patch. I'll change this. Thanks for reviewing, StefanK > > > Thanks, > Jini. > > On 2/11/2019 1:23 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this small patch to resolve ZPageAllocator::_physical >> as a value object instead of a pointer. >> >> https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218732 >> >> This fixes the Heap Parameters view. >> >> Thanks, >> StefanK From gary.adams at oracle.com Mon Feb 11 19:26:24 2019 From: gary.adams at oracle.com (Gary Adams) Date: Mon, 11 Feb 2019 14:26:24 -0500 Subject: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out In-Reply-To: References: <5C5D832D.6030504@oracle.com> Message-ID: <5C61CC60.5060006@oracle.com> I missed a couple of tests in the vm/mlvm area {breakpoint, breakpointInCompiledCode, breakpointOtherStratum}. I filed JDK-8218754 to follow up with those timeouts during debugee exiting. The good news is the problem is easily reproduced in a local linux debug build, so it should be easier to track down. e.g. JDIBreakpointTest has a direct call to debugee.endDebugee(). May need the same fix used for canBeModified, e.g. resume the debugee to let it finish before waiting for an exit status. On 2/8/19, 1:37 PM, serguei.spitsyn at oracle.com wrote: > Hi Gary, > > I'm Okay with the fix if the test run is good. > > Thanks, > Serguei > > > On 2/8/19 05:25, Gary Adams wrote: >> The intermittent failures for remove_l005 appears to be due to a >> timing issue >> in the shutdown handling after the test has completed. The debugger >> has sent >> a "quit" command, but the debugee has not completed processing the >> command >> and exited as expected. >> >> This proposed change modifies the Debugee.endDebugee() processing to >> wait for the debuggee to complete before doing the tear down processing >> on the debugger side of the connection. This sequencing did expose >> an issue in the canBeModified test, where the debugee was never resumed >> after the VMStart event was detected. Resuming the debugee allows it to >> respond as expected when the direct call to endDebugee is invoked. >> >> Testing is still in progress, but it looks like this will resolve a >> number of >> tail end intermittent failures. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 >> Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/ > From hohensee at amazon.com Mon Feb 11 20:53:02 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 11 Feb 2019 20:53:02 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <4d75a7134165433e8dc1ecacd1f564dd@jd.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> Message-ID: <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> In the comments in JMap.java, replace "... one of \"live\" and \"all\" ..." with "... one of \"live\" or \"all\" ...". I.e., replace "and" with "or". Also, "jmap -histo" is still a valid command, so change the comment " jmap -histo: " to " jmap -histo[:] ". In BasicJMapTest.java, add tests for "-histo:all,file=" and "-histo:all". Thanks, Paul ?On 2/11/19, 4:55 AM, "??" wrote: Dear All, Thanks your time for review. I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.07/. Would you like to help review again? And here are what I have done in this update. * Refined the spec of JMap -histo based on Joe's comments in the CSR https://bugs.openjdk.java.net/browse/JDK-8218131 * Added the unit test for JMap based on Serguei's comments. * Fixed the comments format. Thanks ! Cheers, Lin ________________________________________ From: ?? Sent: Saturday, February 9, 2019 18:52 To: serguei.spitsyn at oracle.com; David Holmes; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Thanks All for reviewing the change and CSR, I am still OOTO now and I will update the webrev later and ask your help for review again. Happy Chinese New Year! Cheers, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Wednesday, February 6, 2019 6:44:43 AM To: ??; David Holmes; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Thank you for the fix! It looks good in general. Should it come with a unit test for new flags? http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.frames.html 154 // get the canonical path - important to avoid just 155 // passing a "heap.bin" and having the dump created 156 // in the target VM working directory rather than the 157 // directory where jmap is executed. Minor: Comment need to start with a capital letter: // Get the ... Thanks, Serguei On 1/30/19 10:42 PM, ?? wrote: Hi David, Paul, I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 May I ask your help to review? Thanks! BRs, Lin ________________________________________ From: David Holmes Sent: Thursday, January 31, 2019 9:19:31 AM To: Hohensee, Paul; ??; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo On 31/01/2019 10:41 am, Hohensee, Paul wrote: Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? Yes. Changes to command-line flags need a CSR. Thanks, David Thanks, Paul On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. vm.heapHisto("", "-live") Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to * 'vm.heapHisto("", "-live")' will request a full GC In attachListener.cpp, the line out->print_cr("Invalid argument to dumpheap operation: %s", arg1); should be out->print_cr("Invalid argument to inspectheap operation: %s", arg1); Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. Paul On 1/30/19, 12:18 AM, "??" wrote: Dear All, This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. I have identified the root cause of the issue. it is caused by 2 problems. 1. The path processing in heap_inspection() at attachListener.cpp. The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. I have upload a webrev05: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ May I ask your help for review? Thanks, Lin ________________________________________ From: ?? Sent: Monday, January 28, 2019 5:49:42 PM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Dear all, I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. Thanks! BRs, Lin ________________________________________ From: ?? Sent: Friday, January 25, 2019 9:00:19 AM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Dear All, May I get more review about this webrev? http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ Thanks! BRs, Lin ________________________________________ From: ?? Sent: Tuesday, January 22, 2019 2:18:06 PM To: Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Paul, Thanks a lot for your review. I have refined it based on your comments. http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ Would you like to help review it again? Thanks BRs, Lin ________________________________________ From: Hohensee, Paul Sent: Friday, January 18, 2019 6:11:14 AM To: ??; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Just a few small things. In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. In attachListener.cpp, line 275, change "Fail to" to "Failed to". In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. Thanks, Paul On 1/11/19, 1:39 AM, "??" wrote: Hi Jc, Paul and All, Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ would you like to help review? Thanks, Lin ________________________________________ From: ?? Sent: Friday, January 11, 2019 10:25:27 AM To: JC Beyler Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: ??: [RFR]8215622: Add dump to file support for jmap histo Hi Jc, Thanks a lot. it is not a necessary change, I forget to omit it:) BRs, Lin ________________________________ ???: JC Beyler ????: 2019?1?11? 0:58:22 ???: ?? ??: Hohensee, Paul; serviceability-dev at openjdk.java.net ??: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Small nit: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html needs a copyright update, Jc On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: Dear All, I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ Would you like to help review? Thanks! BRs, Lin From: ?? Sent: Wednesday, January 9, 2019 11:00 AM To: 'JC Beyler' > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215622: Add dump to file support for jmap histo Dear JC, Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. Cheers, Lin From: JC Beyler > Sent: Wednesday, January 9, 2019 10:51 AM To: ?? > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, Inlined as well :-) On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: Dear JC, Thanks for your comments, I inlined my comments here: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? --- (Lin) I will do that in next webrev. - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. Thanks! Jc All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. Cheers, Lin From: JC Beyler > Sent: Wednesday, January 9, 2019 1:42 AM To: ?? > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Hi Lin, I have a few nits: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html You could fix the spaces arount the for loop you changed: + for (int i=0; i<4; i++) { to + for (int i = 0; i < 4; i++) { http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html + filename = opt.substring(5); + if (filename != null) { -> I don't see how filename can be null here -> same filename could just be declared in the if + } else if (subopt.startsWith("file=")) { + filename = parseFileName(subopt); -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? -> in the option string printouts, you don't specify that all is an option as well, is that normal? The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". Thanks, Jc On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: Hi Paul, I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ Hi All, May I also ask your help for reviewing this webrev? webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 Thanks! Lin ________________________________ ???: serviceability-dev > ?? ?? > ????: 2019?1?3? 10:21 ???: Hohensee, Paul; serviceability-dev at openjdk.java.net ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo Dear Paul, Thanks a lot for your review! I am trying to remend the patch One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would be more reasonable than the ?if else? ? Thanks BRs, Lin From: Hohensee, Paul > Sent: Saturday, December 29, 2018 3:54 AM To: ?? >; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Update the copyright dates to 2019 please, since this won?t get pushed until then. In JMap.java, I?d emulate dump() and use String filename = null; String subopts[] = options.split(","); for (String subopt : subopts){ if (subopt.isEmpty() || subopt.equals("all")) { // pass } else if (subopt.equals("live")) { liveopt = "-live"; } else if (subopt.startsWith("file=")) { // file= - check that is specified if (subopt.length() > 5) { filename = subopt.substring(5); } } else { usage(1); } } // get the canonical path - important to avoid just passing // a "heap.bin" and having the dump created in the target VM // working directory rather than the directory where jmap // is executed. filename = new File(filename).getCanonicalPath(); // inspectHeap is not the same as jcmd GC.class_histogram executeCommandForPid(pid, "inspectheap", filename, liveopt); I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. Thanks, Paul From: serviceability-dev > on behalf of ?? > Date: Thursday, December 20, 2018 at 11:03 PM To: "serviceability-dev at openjdk.java.net" > Subject: [RFR]8215622: Add dump to file support for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?histo. It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 Thanks. BRs, Lin -- Thanks, Jc -- Thanks, Jc -- Thanks, Jc From serguei.spitsyn at oracle.com Mon Feb 11 21:10:30 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Feb 2019 13:10:30 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> Message-ID: On 2/11/19 12:53, Hohensee, Paul wrote: > In the comments in JMap.java, replace "... one of \"live\" and \"all\" ..." with "... one of \"live\" or \"all\" ...". I.e., replace "and" with "or". > Also, "jmap -histo" is still a valid command, so change the comment " jmap -histo: " to " jmap -histo[:] ". The same fix is needed in the -dump option: ? The "jmap -dump: " needs to be changed to " jmap -dump[:] ". The CSR also needs the same update in the -dump and -histo options despite the fact it has been finalized. > > In BasicJMapTest.java, add tests for "-histo:all,file=" and "-histo:all". I was about to ask for the same. Thanks, Serguei > Thanks, > > Paul > > ?On 2/11/19, 4:55 AM, "??" wrote: > > Dear All, > Thanks your time for review. > I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.07/. > Would you like to help review again? > And here are what I have done in this update. > * Refined the spec of JMap -histo based on Joe's comments in the CSR https://bugs.openjdk.java.net/browse/JDK-8218131 > * Added the unit test for JMap based on Serguei's comments. > * Fixed the comments format. > Thanks ! > > Cheers, > Lin > ________________________________________ > From: ?? > Sent: Saturday, February 9, 2019 18:52 > To: serguei.spitsyn at oracle.com; David Holmes; Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Thanks All for reviewing the change and CSR, I am still OOTO now and I will update the webrev later and ask your help for review again. > > Happy Chinese New Year! > > Cheers, > Lin > ________________________________________ > From: serguei.spitsyn at oracle.com > Sent: Wednesday, February 6, 2019 6:44:43 AM > To: ??; David Holmes; Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Thank you for the fix! > It looks good in general. > > Should it come with a unit test for new flags? > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.frames.html > > > 154 // get the canonical path - important to avoid just > 155 // passing a "heap.bin" and having the dump created > 156 // in the target VM working directory rather than the > 157 // directory where jmap is executed. > > Minor: Comment need to start with a capital letter: // Get the ... > > > Thanks, > Serguei > > On 1/30/19 10:42 PM, ?? wrote: > > Hi David, Paul, > I have uploaded the refined webrev at > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > May I ask your help to review? > Thanks! > > BRs, > Lin > ________________________________________ > From: David Holmes > Sent: Thursday, January 31, 2019 9:19:31 AM > To: Hohensee, Paul; ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > > > Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > Yes. Changes to command-line flags need a CSR. > > Thanks, > David > > > > Thanks, > > Paul > > On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > vm.heapHisto("", "-live") > > Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > * 'vm.heapHisto("", "-live")' will request a full GC > > In attachListener.cpp, the line > > out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > should be > > out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > Paul > > On 1/30/19, 12:18 AM, "??" wrote: > > Dear All, > This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > I have identified the root cause of the issue. it is caused by 2 problems. > 1. The path processing in heap_inspection() at attachListener.cpp. > The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > I have upload a webrev05: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > May I ask your help for review? > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Monday, January 28, 2019 5:49:42 PM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Dear all, > I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > Thanks! > > BRs, > Lin > ________________________________________ > From: ?? > Sent: Friday, January 25, 2019 9:00:19 AM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Dear All, > May I get more review about this webrev? > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > Thanks! > BRs, > Lin > ________________________________________ > From: ?? > Sent: Tuesday, January 22, 2019 2:18:06 PM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Paul, > Thanks a lot for your review. I have refined it based on your comments. > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > Would you like to help review it again? Thanks > > BRs, > Lin > ________________________________________ > From: Hohensee, Paul > Sent: Friday, January 18, 2019 6:11:14 AM > To: ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Just a few small things. > > In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > Thanks, > > Paul > > On 1/11/19, 1:39 AM, "??" wrote: > > Hi Jc, Paul and All, > Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > would you like to help review? > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Friday, January 11, 2019 10:25:27 AM > To: JC Beyler > Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > Hi Jc, > Thanks a lot. it is not a necessary change, I forget to omit it:) > > BRs, > Lin > ________________________________ > ???: JC Beyler > ????: 2019?1?11? 0:58:22 > ???: ?? > ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Small nit: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > needs a copyright update, > Jc > > > On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > Dear All, > I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > Would you like to help review? Thanks! > > BRs, > Lin > From: ?? > Sent: Wednesday, January 9, 2019 11:00 AM > To: 'JC Beyler' > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > Dear JC, > Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > Cheers, > Lin > > From: JC Beyler > > Sent: Wednesday, January 9, 2019 10:51 AM > To: ?? > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Inlined as well :-) > > On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > Dear JC, > Thanks for your comments, I inlined my comments here: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > --- (Lin) I will do that in next webrev. > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > > No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > Thanks! > Jc > > > All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > Cheers, > Lin > > > From: JC Beyler > > Sent: Wednesday, January 9, 2019 1:42 AM > To: ?? > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > I have a few nits: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > You could fix the spaces arount the for loop you changed: > > + for (int i=0; i<4; i++) { > to > > + for (int i = 0; i < 4; i++) { > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > + filename = opt.substring(5); > + if (filename != null) { > -> I don't see how filename can be null here > -> same filename could just be declared in the if > > > > + } else if (subopt.startsWith("file=")) { > + filename = parseFileName(subopt); > > -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > Thanks, > Jc > > On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > Hi Paul, > I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > Hi All, > May I also ask your help for reviewing this webrev? > webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > Thanks! > Lin > > ________________________________ > ???: serviceability-dev > ?? ?? > > ????: 2019?1?3? 10:21 > ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > > Dear Paul, > > Thanks a lot for your review! I am trying to remend the patch > > One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > be more reasonable than the ?if else? ? > > Thanks > > > > BRs, > > Lin > > > > > > > > From: Hohensee, Paul > > Sent: Saturday, December 29, 2018 3:54 AM > To: ?? >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Update the copyright dates to 2019 please, since this won?t get pushed until then. > > > > In JMap.java, I?d emulate dump() and use > > > > String filename = null; > > String subopts[] = options.split(","); > > > > for (String subopt : subopts){ > > if (subopt.isEmpty() || subopt.equals("all")) { > > // pass > > } else if (subopt.equals("live")) { > > liveopt = "-live"; > > } else if (subopt.startsWith("file=")) { > > // file= - check that is specified > > if (subopt.length() > 5) { > > filename = subopt.substring(5); > > } > > } else { > > usage(1); > > } > > } > > > > // get the canonical path - important to avoid just passing > > // a "heap.bin" and having the dump created in the target VM > > // working directory rather than the directory where jmap > > // is executed. > > filename = new File(filename).getCanonicalPath(); > > // inspectHeap is not the same as jcmd GC.class_histogram > > executeCommandForPid(pid, "inspectheap", filename, liveopt); > > > > I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > > > The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > > > Thanks, > > > > Paul > > > > From: serviceability-dev > on behalf of ?? > > Date: Thursday, December 20, 2018 at 11:03 PM > To: "serviceability-dev at openjdk.java.net" > > Subject: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi All, > > May I ask your help to review this patch for enhance jmap ?histo. > > It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > > Thanks. > > > > BRs, > > Lin > > > > > > > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc > > > > > > > > > > From hohensee at amazon.com Mon Feb 11 21:24:16 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 11 Feb 2019 21:24:16 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> Message-ID: <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> On " jmap -dump[:] ", turns out that "jmap -dump" is illegal. A quick test produces an error (actually, the "Usage" message), and the source code confirms it. for (String pid : pids) { if (pids.size() > 1) { System.out.println("Pid:" + pid); } if (option.equals("-histo")) { histo(pid, ""); } else if (option.startsWith("-histo:")) { histo(pid, option.substring("-histo:".length())); } else if (option.startsWith("-dump:")) { dump(pid, option.substring("-dump:".length())); } else if (option.equals("-finalizerinfo")) { executeCommandForPid(pid, "jcmd", "GC.finalizer_info"); } else if (option.equals("-clstats")) { executeCommandForPid(pid, "jcmd", "GC.class_stats"); } else { usage(1); } Should the spec and implementation be changed to allow "jmap -dump" as part of this fix? I'd say yes, since it would require another CSR to do it separately. Paul ?On 2/11/19, 1:11 PM, "serguei.spitsyn at oracle.com" wrote: On 2/11/19 12:53, Hohensee, Paul wrote: > In the comments in JMap.java, replace "... one of \"live\" and \"all\" ..." with "... one of \"live\" or \"all\" ...". I.e., replace "and" with "or". > Also, "jmap -histo" is still a valid command, so change the comment " jmap -histo: " to " jmap -histo[:] ". The same fix is needed in the -dump option: The "jmap -dump: " needs to be changed to " jmap -dump[:] ". The CSR also needs the same update in the -dump and -histo options despite the fact it has been finalized. > > In BasicJMapTest.java, add tests for "-histo:all,file=" and "-histo:all". I was about to ask for the same. Thanks, Serguei > Thanks, > > Paul > > On 2/11/19, 4:55 AM, "??" wrote: > > Dear All, > Thanks your time for review. > I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.07/. > Would you like to help review again? > And here are what I have done in this update. > * Refined the spec of JMap -histo based on Joe's comments in the CSR https://bugs.openjdk.java.net/browse/JDK-8218131 > * Added the unit test for JMap based on Serguei's comments. > * Fixed the comments format. > Thanks ! > > Cheers, > Lin > ________________________________________ > From: ?? > Sent: Saturday, February 9, 2019 18:52 > To: serguei.spitsyn at oracle.com; David Holmes; Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Thanks All for reviewing the change and CSR, I am still OOTO now and I will update the webrev later and ask your help for review again. > > Happy Chinese New Year! > > Cheers, > Lin > ________________________________________ > From: serguei.spitsyn at oracle.com > Sent: Wednesday, February 6, 2019 6:44:43 AM > To: ??; David Holmes; Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Thank you for the fix! > It looks good in general. > > Should it come with a unit test for new flags? > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.frames.html > > > 154 // get the canonical path - important to avoid just > 155 // passing a "heap.bin" and having the dump created > 156 // in the target VM working directory rather than the > 157 // directory where jmap is executed. > > Minor: Comment need to start with a capital letter: // Get the ... > > > Thanks, > Serguei > > On 1/30/19 10:42 PM, ?? wrote: > > Hi David, Paul, > I have uploaded the refined webrev at > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > May I ask your help to review? > Thanks! > > BRs, > Lin > ________________________________________ > From: David Holmes > Sent: Thursday, January 31, 2019 9:19:31 AM > To: Hohensee, Paul; ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > > > Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > Yes. Changes to command-line flags need a CSR. > > Thanks, > David > > > > Thanks, > > Paul > > On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > vm.heapHisto("", "-live") > > Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > * 'vm.heapHisto("", "-live")' will request a full GC > > In attachListener.cpp, the line > > out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > should be > > out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > Paul > > On 1/30/19, 12:18 AM, "??" wrote: > > Dear All, > This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > I have identified the root cause of the issue. it is caused by 2 problems. > 1. The path processing in heap_inspection() at attachListener.cpp. > The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > I have upload a webrev05: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > May I ask your help for review? > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Monday, January 28, 2019 5:49:42 PM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Dear all, > I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > Thanks! > > BRs, > Lin > ________________________________________ > From: ?? > Sent: Friday, January 25, 2019 9:00:19 AM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Dear All, > May I get more review about this webrev? > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > Thanks! > BRs, > Lin > ________________________________________ > From: ?? > Sent: Tuesday, January 22, 2019 2:18:06 PM > To: Hohensee, Paul; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Paul, > Thanks a lot for your review. I have refined it based on your comments. > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > Would you like to help review it again? Thanks > > BRs, > Lin > ________________________________________ > From: Hohensee, Paul > Sent: Friday, January 18, 2019 6:11:14 AM > To: ??; JC Beyler > Cc: serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Just a few small things. > > In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > Thanks, > > Paul > > On 1/11/19, 1:39 AM, "??" wrote: > > Hi Jc, Paul and All, > Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > would you like to help review? > > Thanks, > Lin > ________________________________________ > From: ?? > Sent: Friday, January 11, 2019 10:25:27 AM > To: JC Beyler > Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > Hi Jc, > Thanks a lot. it is not a necessary change, I forget to omit it:) > > BRs, > Lin > ________________________________ > ???: JC Beyler > ????: 2019?1?11? 0:58:22 > ???: ?? > ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Small nit: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > needs a copyright update, > Jc > > > On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > Dear All, > I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > Would you like to help review? Thanks! > > BRs, > Lin > From: ?? > Sent: Wednesday, January 9, 2019 11:00 AM > To: 'JC Beyler' > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > Dear JC, > Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > Cheers, > Lin > > From: JC Beyler > > Sent: Wednesday, January 9, 2019 10:51 AM > To: ?? > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > Inlined as well :-) > > On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > Dear JC, > Thanks for your comments, I inlined my comments here: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > --- (Lin) I will do that in next webrev. > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > > No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > Thanks! > Jc > > > All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > Cheers, > Lin > > > From: JC Beyler > > Sent: Wednesday, January 9, 2019 1:42 AM > To: ?? > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > Hi Lin, > > I have a few nits: > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > You could fix the spaces arount the for loop you changed: > > + for (int i=0; i<4; i++) { > to > > + for (int i = 0; i < 4; i++) { > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > + filename = opt.substring(5); > + if (filename != null) { > -> I don't see how filename can be null here > -> same filename could just be declared in the if > > > > + } else if (subopt.startsWith("file=")) { > + filename = parseFileName(subopt); > > -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > Thanks, > Jc > > On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > Hi Paul, > I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > Hi All, > May I also ask your help for reviewing this webrev? > webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > Thanks! > Lin > > ________________________________ > ???: serviceability-dev > ?? ?? > > ????: 2019?1?3? 10:21 > ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > > Dear Paul, > > Thanks a lot for your review! I am trying to remend the patch > > One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > be more reasonable than the ?if else? ? > > Thanks > > > > BRs, > > Lin > > > > > > > > From: Hohensee, Paul > > Sent: Saturday, December 29, 2018 3:54 AM > To: ?? >; serviceability-dev at openjdk.java.net > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Update the copyright dates to 2019 please, since this won?t get pushed until then. > > > > In JMap.java, I?d emulate dump() and use > > > > String filename = null; > > String subopts[] = options.split(","); > > > > for (String subopt : subopts){ > > if (subopt.isEmpty() || subopt.equals("all")) { > > // pass > > } else if (subopt.equals("live")) { > > liveopt = "-live"; > > } else if (subopt.startsWith("file=")) { > > // file= - check that is specified > > if (subopt.length() > 5) { > > filename = subopt.substring(5); > > } > > } else { > > usage(1); > > } > > } > > > > // get the canonical path - important to avoid just passing > > // a "heap.bin" and having the dump created in the target VM > > // working directory rather than the directory where jmap > > // is executed. > > filename = new File(filename).getCanonicalPath(); > > // inspectHeap is not the same as jcmd GC.class_histogram > > executeCommandForPid(pid, "inspectheap", filename, liveopt); > > > > I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > > > The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > > > Thanks, > > > > Paul > > > > From: serviceability-dev > on behalf of ?? > > Date: Thursday, December 20, 2018 at 11:03 PM > To: "serviceability-dev at openjdk.java.net" > > Subject: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi All, > > May I ask your help to review this patch for enhance jmap ?histo. > > It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > > Thanks. > > > > BRs, > > Lin > > > > > > > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc > > > -- > > Thanks, > Jc > > > > > > > > > > From serguei.spitsyn at oracle.com Mon Feb 11 21:30:06 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Feb 2019 13:30:06 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> Message-ID: On 2/11/19 13:24, Hohensee, Paul wrote: > On " jmap -dump[:] ", turns out that "jmap -dump" is illegal. A quick test produces an error (actually, the "Usage" message), and the source code confirms it. > > for (String pid : pids) { > if (pids.size() > 1) { > System.out.println("Pid:" + pid); > } > if (option.equals("-histo")) { > histo(pid, ""); > } else if (option.startsWith("-histo:")) { > histo(pid, option.substring("-histo:".length())); > } else if (option.startsWith("-dump:")) { > dump(pid, option.substring("-dump:".length())); > } else if (option.equals("-finalizerinfo")) { > executeCommandForPid(pid, "jcmd", "GC.finalizer_info"); > } else if (option.equals("-clstats")) { > executeCommandForPid(pid, "jcmd", "GC.class_stats"); > } else { > usage(1); > } > > Should the spec and implementation be changed to allow "jmap -dump" as part of this fix? I'd say - Yes. It makes sense to align the two options to behave similarly. > I'd say yes, since it would require another CSR to do it separately. I'd suggest to use the same CSR to simplify things and minimize the overhead. Thanks, Serguei > > Paul > > ?On 2/11/19, 1:11 PM, "serguei.spitsyn at oracle.com" wrote: > > On 2/11/19 12:53, Hohensee, Paul wrote: > > In the comments in JMap.java, replace "... one of \"live\" and \"all\" ..." with "... one of \"live\" or \"all\" ...". I.e., replace "and" with "or". Forgot to say that the same update is also needed for dump-options. Thanks, Serguei > > > Also, "jmap -histo" is still a valid command, so change the comment " jmap -histo: " to " jmap -histo[:] ". > > The same fix is needed in the -dump option: > The "jmap -dump: " needs to be changed to " jmap > -dump[:] ". > > The CSR also needs the same update in the -dump and -histo options > despite the fact it has been finalized. > > > > > In BasicJMapTest.java, add tests for "-histo:all,file=" and "-histo:all". > > I was about to ask for the same. > > Thanks, > Serguei > > > Thanks, > > > > Paul > > > > On 2/11/19, 4:55 AM, "??" wrote: > > > > Dear All, > > Thanks your time for review. > > I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.07/. > > Would you like to help review again? > > And here are what I have done in this update. > > * Refined the spec of JMap -histo based on Joe's comments in the CSR https://bugs.openjdk.java.net/browse/JDK-8218131 > > * Added the unit test for JMap based on Serguei's comments. > > * Fixed the comments format. > > Thanks ! > > > > Cheers, > > Lin > > ________________________________________ > > From: ?? > > Sent: Saturday, February 9, 2019 18:52 > > To: serguei.spitsyn at oracle.com; David Holmes; Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Thanks All for reviewing the change and CSR, I am still OOTO now and I will update the webrev later and ask your help for review again. > > > > Happy Chinese New Year! > > > > Cheers, > > Lin > > ________________________________________ > > From: serguei.spitsyn at oracle.com > > Sent: Wednesday, February 6, 2019 6:44:43 AM > > To: ??; David Holmes; Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Lin, > > > > Thank you for the fix! > > It looks good in general. > > > > Should it come with a unit test for new flags? > > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.frames.html > > > > > > 154 // get the canonical path - important to avoid just > > 155 // passing a "heap.bin" and having the dump created > > 156 // in the target VM working directory rather than the > > 157 // directory where jmap is executed. > > > > Minor: Comment need to start with a capital letter: // Get the ... > > > > > > Thanks, > > Serguei > > > > On 1/30/19 10:42 PM, ?? wrote: > > > > Hi David, Paul, > > I have uploaded the refined webrev at > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > > May I ask your help to review? > > Thanks! > > > > BRs, > > Lin > > ________________________________________ > > From: David Holmes > > Sent: Thursday, January 31, 2019 9:19:31 AM > > To: Hohensee, Paul; ??; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > > > > > > Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > > > > > Yes. Changes to command-line flags need a CSR. > > > > Thanks, > > David > > > > > > > > Thanks, > > > > Paul > > > > On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > > > A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > > > vm.heapHisto("", "-live") > > > > Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > > > * 'vm.heapHisto("", "-live")' will request a full GC > > > > In attachListener.cpp, the line > > > > out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > > > should be > > > > out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > > > Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > > > Paul > > > > On 1/30/19, 12:18 AM, "??" wrote: > > > > Dear All, > > This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > > I have identified the root cause of the issue. it is caused by 2 problems. > > 1. The path processing in heap_inspection() at attachListener.cpp. > > The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > > I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > > > 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > > > I have upload a webrev05: > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > > > May I ask your help for review? > > > > Thanks, > > Lin > > ________________________________________ > > From: ?? > > Sent: Monday, January 28, 2019 5:49:42 PM > > To: Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Dear all, > > I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > > Thanks! > > > > BRs, > > Lin > > ________________________________________ > > From: ?? > > Sent: Friday, January 25, 2019 9:00:19 AM > > To: Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Dear All, > > May I get more review about this webrev? > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > > > Thanks! > > BRs, > > Lin > > ________________________________________ > > From: ?? > > Sent: Tuesday, January 22, 2019 2:18:06 PM > > To: Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Paul, > > Thanks a lot for your review. I have refined it based on your comments. > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > Would you like to help review it again? Thanks > > > > BRs, > > Lin > > ________________________________________ > > From: Hohensee, Paul > > Sent: Friday, January 18, 2019 6:11:14 AM > > To: ??; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Just a few small things. > > > > In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > > > In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > > > In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > > > Thanks, > > > > Paul > > > > On 1/11/19, 1:39 AM, "??" wrote: > > > > Hi Jc, Paul and All, > > Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > > would you like to help review? > > > > Thanks, > > Lin > > ________________________________________ > > From: ?? > > Sent: Friday, January 11, 2019 10:25:27 AM > > To: JC Beyler > > Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > > Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Jc, > > Thanks a lot. it is not a necessary change, I forget to omit it:) > > > > BRs, > > Lin > > ________________________________ > > ???: JC Beyler > > ????: 2019?1?11? 0:58:22 > > ???: ?? > > ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > > ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Lin, > > > > Small nit: > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > > > needs a copyright update, > > Jc > > > > > > On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > > Dear All, > > I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > > Would you like to help review? Thanks! > > > > BRs, > > Lin > > From: ?? > > Sent: Wednesday, January 9, 2019 11:00 AM > > To: 'JC Beyler' > > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > > > Dear JC, > > Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > > > Cheers, > > Lin > > > > From: JC Beyler > > > Sent: Wednesday, January 9, 2019 10:51 AM > > To: ?? > > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Lin, > > > > Inlined as well :-) > > > > On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > > Dear JC, > > Thanks for your comments, I inlined my comments here: > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > --- (Lin) I will do that in next webrev. > > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > > > > > No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > > > I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > > > Thanks! > > Jc > > > > > > All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > > > Cheers, > > Lin > > > > > > From: JC Beyler > > > Sent: Wednesday, January 9, 2019 1:42 AM > > To: ?? > > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Lin, > > > > I have a few nits: > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > > > You could fix the spaces arount the for loop you changed: > > > > + for (int i=0; i<4; i++) { > > to > > > > + for (int i = 0; i < 4; i++) { > > > > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > > + filename = opt.substring(5); > > + if (filename != null) { > > -> I don't see how filename can be null here > > -> same filename could just be declared in the if > > > > > > > > + } else if (subopt.startsWith("file=")) { > > + filename = parseFileName(subopt); > > > > -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > > > -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > > > > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > > > Thanks, > > Jc > > > > On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > > > Hi Paul, > > I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > > And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > > > Hi All, > > May I also ask your help for reviewing this webrev? > > webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > > Thanks! > > Lin > > > > ________________________________ > > ???: serviceability-dev > ?? ?? > > > ????: 2019?1?3? 10:21 > > ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > > ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > > > > > Dear Paul, > > > > Thanks a lot for your review! I am trying to remend the patch > > > > One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > > > so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > > > be more reasonable than the ?if else? ? > > > > Thanks > > > > > > > > BRs, > > > > Lin > > > > > > > > > > > > > > > > From: Hohensee, Paul > > > Sent: Saturday, December 29, 2018 3:54 AM > > To: ?? >; serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > > > > > Update the copyright dates to 2019 please, since this won?t get pushed until then. > > > > > > > > In JMap.java, I?d emulate dump() and use > > > > > > > > String filename = null; > > > > String subopts[] = options.split(","); > > > > > > > > for (String subopt : subopts){ > > > > if (subopt.isEmpty() || subopt.equals("all")) { > > > > // pass > > > > } else if (subopt.equals("live")) { > > > > liveopt = "-live"; > > > > } else if (subopt.startsWith("file=")) { > > > > // file= - check that is specified > > > > if (subopt.length() > 5) { > > > > filename = subopt.substring(5); > > > > } > > > > } else { > > > > usage(1); > > > > } > > > > } > > > > > > > > // get the canonical path - important to avoid just passing > > > > // a "heap.bin" and having the dump created in the target VM > > > > // working directory rather than the directory where jmap > > > > // is executed. > > > > filename = new File(filename).getCanonicalPath(); > > > > // inspectHeap is not the same as jcmd GC.class_histogram > > > > executeCommandForPid(pid, "inspectheap", filename, liveopt); > > > > > > > > I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > > > > > > > The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > > > > > > > Thanks, > > > > > > > > Paul > > > > > > > > From: serviceability-dev > on behalf of ?? > > > Date: Thursday, December 20, 2018 at 11:03 PM > > To: "serviceability-dev at openjdk.java.net" > > > Subject: [RFR]8215622: Add dump to file support for jmap histo > > > > > > > > Hi All, > > > > May I ask your help to review this patch for enhance jmap ?histo. > > > > It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > > > This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > > > > > > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > > > > > > Thanks. > > > > > > > > BRs, > > > > Lin > > > > > > > > > > > > > > > > > > -- > > > > Thanks, > > Jc > > > > > > -- > > > > Thanks, > > Jc > > > > > > -- > > > > Thanks, > > Jc > > > > > > > > > > > > > > > > > > > > > > > From hohensee at amazon.com Mon Feb 11 22:20:55 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 11 Feb 2019 22:20:55 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> Message-ID: <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> The CSR was just closed, so we're stuck with doing another one later. Paul ?On 2/11/19, 1:31 PM, "serguei.spitsyn at oracle.com" wrote: On 2/11/19 13:24, Hohensee, Paul wrote: > On " jmap -dump[:] ", turns out that "jmap -dump" is illegal. A quick test produces an error (actually, the "Usage" message), and the source code confirms it. > > for (String pid : pids) { > if (pids.size() > 1) { > System.out.println("Pid:" + pid); > } > if (option.equals("-histo")) { > histo(pid, ""); > } else if (option.startsWith("-histo:")) { > histo(pid, option.substring("-histo:".length())); > } else if (option.startsWith("-dump:")) { > dump(pid, option.substring("-dump:".length())); > } else if (option.equals("-finalizerinfo")) { > executeCommandForPid(pid, "jcmd", "GC.finalizer_info"); > } else if (option.equals("-clstats")) { > executeCommandForPid(pid, "jcmd", "GC.class_stats"); > } else { > usage(1); > } > > Should the spec and implementation be changed to allow "jmap -dump" as part of this fix? I'd say - Yes. It makes sense to align the two options to behave similarly. > I'd say yes, since it would require another CSR to do it separately. I'd suggest to use the same CSR to simplify things and minimize the overhead. Thanks, Serguei > > Paul > > On 2/11/19, 1:11 PM, "serguei.spitsyn at oracle.com" wrote: > > On 2/11/19 12:53, Hohensee, Paul wrote: > > In the comments in JMap.java, replace "... one of \"live\" and \"all\" ..." with "... one of \"live\" or \"all\" ...". I.e., replace "and" with "or". Forgot to say that the same update is also needed for dump-options. Thanks, Serguei > > > Also, "jmap -histo" is still a valid command, so change the comment " jmap -histo: " to " jmap -histo[:] ". > > The same fix is needed in the -dump option: > The "jmap -dump: " needs to be changed to " jmap > -dump[:] ". > > The CSR also needs the same update in the -dump and -histo options > despite the fact it has been finalized. > > > > > In BasicJMapTest.java, add tests for "-histo:all,file=" and "-histo:all". > > I was about to ask for the same. > > Thanks, > Serguei > > > Thanks, > > > > Paul > > > > On 2/11/19, 4:55 AM, "??" wrote: > > > > Dear All, > > Thanks your time for review. > > I have uploaded the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.07/. > > Would you like to help review again? > > And here are what I have done in this update. > > * Refined the spec of JMap -histo based on Joe's comments in the CSR https://bugs.openjdk.java.net/browse/JDK-8218131 > > * Added the unit test for JMap based on Serguei's comments. > > * Fixed the comments format. > > Thanks ! > > > > Cheers, > > Lin > > ________________________________________ > > From: ?? > > Sent: Saturday, February 9, 2019 18:52 > > To: serguei.spitsyn at oracle.com; David Holmes; Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Thanks All for reviewing the change and CSR, I am still OOTO now and I will update the webrev later and ask your help for review again. > > > > Happy Chinese New Year! > > > > Cheers, > > Lin > > ________________________________________ > > From: serguei.spitsyn at oracle.com > > Sent: Wednesday, February 6, 2019 6:44:43 AM > > To: ??; David Holmes; Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Lin, > > > > Thank you for the fix! > > It looks good in general. > > > > Should it come with a unit test for new flags? > > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.frames.html > > > > > > 154 // get the canonical path - important to avoid just > > 155 // passing a "heap.bin" and having the dump created > > 156 // in the target VM working directory rather than the > > 157 // directory where jmap is executed. > > > > Minor: Comment need to start with a capital letter: // Get the ... > > > > > > Thanks, > > Serguei > > > > On 1/30/19 10:42 PM, ?? wrote: > > > > Hi David, Paul, > > I have uploaded the refined webrev at > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.06/ > > And submitted a CSR at https://bugs.openjdk.java.net/browse/JDK-8218131 > > May I ask your help to review? > > Thanks! > > > > BRs, > > Lin > > ________________________________________ > > From: David Holmes > > Sent: Thursday, January 31, 2019 9:19:31 AM > > To: Hohensee, Paul; ??; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > On 31/01/2019 10:41 am, Hohensee, Paul wrote: > > > > > > Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? > > > > > > > > Yes. Changes to command-line flags need a CSR. > > > > Thanks, > > David > > > > > > > > Thanks, > > > > Paul > > > > On 1/30/19, 9:33 AM, "serviceability-dev on behalf of Hohensee, Paul" wrote: > > > > A nit in TestLoggerWeakRefLeak.java, separate the 2 arguments to heapHisto() by a space. > > > > vm.heapHisto("", "-live") > > > > Also, the header comment line for getInstanceCountFromHeapHisto() should be changed to > > > > * 'vm.heapHisto("", "-live")' will request a full GC > > > > In attachListener.cpp, the line > > > > out->print_cr("Invalid argument to dumpheap operation: %s", arg1); > > > > should be > > > > out->print_cr("Invalid argument to inspectheap operation: %s", arg1); > > > > Otherwise looks fine. The two failing tests (the other one was test/jdk/java/util/concurrent/locks/Lock/TimedAcquireLeak.java) now pass on my mac laptop. > > > > Paul > > > > On 1/30/19, 12:18 AM, "??" wrote: > > > > Dear All, > > This issue mentioned is that test case "java/util/logging/TestLoggerWeakRefLeak.java" Failed after applied the webrev. > > I have identified the root cause of the issue. it is caused by 2 problems. > > 1. The path processing in heap_inspection() at attachListener.cpp. > > The problem is that when use jmap -histo:live , the path is actually set to "" when it is transfer to socket. so it cause JNI_ERR. > > I need to modify the logic here that if path[0] == '\0' , fall through to the next argument parsing, rather than return JNI_ERR. > > > > 2. Another problem is HotSpotVirtualMachine.java, it has a heapHisto() method, and the testcase use vm.heapHisto("-live"), And after the patch applied, it should be vm.heapHisto(""/*filepath*/, "-live"), seems we need to change the API for handling it. > > > > I have upload a webrev05: > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.05/ > > > > May I ask your help for review? > > > > Thanks, > > Lin > > ________________________________________ > > From: ?? > > Sent: Monday, January 28, 2019 5:49:42 PM > > To: Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Dear all, > > I have found there is problem for handling the "filepath" and it cause test "java/util/logging/TestLoggerWeakRefLeak.java" fail, I have identified the root cause, please wait for the new update. > > Thanks! > > > > BRs, > > Lin > > ________________________________________ > > From: ?? > > Sent: Friday, January 25, 2019 9:00:19 AM > > To: Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Dear All, > > May I get more review about this webrev? > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > > > Thanks! > > BRs, > > Lin > > ________________________________________ > > From: ?? > > Sent: Tuesday, January 22, 2019 2:18:06 PM > > To: Hohensee, Paul; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Paul, > > Thanks a lot for your review. I have refined it based on your comments. > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.04/ > > Would you like to help review it again? Thanks > > > > BRs, > > Lin > > ________________________________________ > > From: Hohensee, Paul > > Sent: Friday, January 18, 2019 6:11:14 AM > > To: ??; JC Beyler > > Cc: serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Just a few small things. > > > > In attachListener.cpp, line 278, is the static_cast needed? fileStream is a subclass of outputStream, so it should be ok to pass to the VM_GC_Heap_Inspection constructor, but maybe there's some C++ arcana I don't know about. > > > > In attachListener.cpp, line 275, change "Fail to" to "Failed to". > > > > In JMap.java, line 286, change use \"all\"" to use \"all\"." to match line 277. > > > > Thanks, > > > > Paul > > > > On 1/11/19, 1:39 AM, "??" wrote: > > > > Hi Jc, Paul and All, > > Here is webrev03 http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.03/ > > would you like to help review? > > > > Thanks, > > Lin > > ________________________________________ > > From: ?? > > Sent: Friday, January 11, 2019 10:25:27 AM > > To: JC Beyler > > Cc: Hohensee, Paul; serviceability-dev at openjdk.java.net > > Subject: ??: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Jc, > > Thanks a lot. it is not a necessary change, I forget to omit it:) > > > > BRs, > > Lin > > ________________________________ > > ???: JC Beyler > > ????: 2019?1?11? 0:58:22 > > ???: ?? > > ??: Hohensee, Paul; serviceability-dev at openjdk.java.net > > ??: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Lin, > > > > Small nit: > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/src/java.base/share/native/libjli/java.c.udiff.html > > > > needs a copyright update, > > Jc > > > > > > On Wed, Jan 9, 2019 at 7:48 PM ?? > wrote: > > Dear All, > > I have updated the refined webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.02/ > > Would you like to help review? Thanks! > > > > BRs, > > Lin > > From: ?? > > Sent: Wednesday, January 9, 2019 11:00 AM > > To: 'JC Beyler' > > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > Subject: RE: [RFR]8215622: Add dump to file support for jmap histo > > > > Dear JC, > > Thanks to point it out, I processed the ?-file=? case in JMap.java but forgot to do it in attachListener.cpp. I will do it in next webrev. > > > > Cheers, > > Lin > > > > From: JC Beyler > > > Sent: Wednesday, January 9, 2019 10:51 AM > > To: ?? > > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Lin, > > > > Inlined as well :-) > > > > On Tue, Jan 8, 2019 at 6:23 PM ?? > wrote: > > Dear JC, > > Thanks for your comments, I inlined my comments here: > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > --- (Lin) I will do that in next webrev. > > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > --- (Lin) The logic is that when user use ?-file=?, the file must be created successful, otherwise the ?-file=? not work, which break user?s expection, so it fail here. If user not specify ?-file=?, it indicate that user not expect to dump to file, so the outputStream will be used. Do you think it is reasonable? > > > > > > No that is reasonable BUT your code currently allows the user to do "--file="; in this absurd case, your code prints out "No dump file specified" and just continues. Why not make that fail as well? > > > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > ---(Lin) This is similar with what I have done in webrev00, but I think maybe processing arguments in JMap.java is more reasonable, I think logically, it is JMap?s responsibility to parsed it?s command line arguments, and then pass it to attachListener. The attachListener just hearing from the socket and get command and parsed arguments. And one more reason maybe that in java it is easy to get the canonical path from the API getCanonicalPath(), which I guess maybe a little complicate to do it cross platform in attachListener.cpp. > > > > I think it's a style choice perhaps? I'd rather have the code look at the arguments and see if it is --file or if it is --live or --all and then figure out what to do instead of having now "null or a file" for arg0. But I can see the conversation go both ways in this case. > > > > Thanks! > > Jc > > > > > > All other comments will be handled in the next webrev. Thanks a lot for your review and suggestions. > > > > Cheers, > > Lin > > > > > > From: JC Beyler > > > Sent: Wednesday, January 9, 2019 1:42 AM > > To: ?? > > > Cc: Hohensee, Paul >; serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > Hi Lin, > > > > I have a few nits: > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java.udiff.html > > > > You could fix the spaces arount the for loop you changed: > > > > + for (int i=0; i<4; i++) { > > to > > > > + for (int i = 0; i < 4; i++) { > > > > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/hotspot/share/services/attachListener.cpp.udiff.html > > - Should we do like the rest of the file and declare variables when needed instead of doing them all at the start? > > - Should the method return JNI_ERR if the file cannot be created (because if not, then why fail if no file is passed at all?) > > > > http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html > > + filename = opt.substring(5); > > + if (filename != null) { > > -> I don't see how filename can be null here > > -> same filename could just be declared in the if > > > > > > > > + } else if (subopt.startsWith("file=")) { > > + filename = parseFileName(subopt); > > > > -> So actually you are testing twice if the string starts with "file=", maybe remove the one in the method? > > > > -> in the option string printouts, you don't specify that all is an option as well, is that normal? > > > > > > The bigger issue I see is the passing of NULL for a filename, why do we not do things where you just really pass "-file=" to the attachListener.cpp and handle the parsing there?; it would then make more sense to me: we either pass "-file=" or not but we no longer have a "maybe there is or not a file, so maybe there is a NULL there". > > > > Thanks, > > Jc > > > > On Mon, Jan 7, 2019 at 2:11 AM ?? > wrote: > > > > Hi Paul, > > I think it is not necessary to have a loop for argument processing, since there is not so much arguments to handle. > > And I made a new webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > > > Hi All, > > May I also ask your help for reviewing this webrev? > > webrev http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > > Thanks! > > Lin > > > > ________________________________ > > ???: serviceability-dev > ?? ?? > > > ????: 2019?1?3? 10:21 > > ???: Hohensee, Paul; serviceability-dev at openjdk.java.net > > ??: [??????,????,??] RE: [RFR]8215622: Add dump to file support for jmap histo > > > > > > Dear Paul, > > > > Thanks a lot for your review! I am trying to remend the patch > > > > One problem is that in future, I will add more options for histo, such as ?parallel?, ?incremental?. > > > > so do you thinking option processing with loop in heap_inspection() in attachListener.cpp would > > > > be more reasonable than the ?if else? ? > > > > Thanks > > > > > > > > BRs, > > > > Lin > > > > > > > > > > > > > > > > From: Hohensee, Paul > > > Sent: Saturday, December 29, 2018 3:54 AM > > To: ?? >; serviceability-dev at openjdk.java.net > > Subject: Re: [RFR]8215622: Add dump to file support for jmap histo > > > > > > > > Update the copyright dates to 2019 please, since this won?t get pushed until then. > > > > > > > > In JMap.java, I?d emulate dump() and use > > > > > > > > String filename = null; > > > > String subopts[] = options.split(","); > > > > > > > > for (String subopt : subopts){ > > > > if (subopt.isEmpty() || subopt.equals("all")) { > > > > // pass > > > > } else if (subopt.equals("live")) { > > > > liveopt = "-live"; > > > > } else if (subopt.startsWith("file=")) { > > > > // file= - check that is specified > > > > if (subopt.length() > 5) { > > > > filename = subopt.substring(5); > > > > } > > > > } else { > > > > usage(1); > > > > } > > > > } > > > > > > > > // get the canonical path - important to avoid just passing > > > > // a "heap.bin" and having the dump created in the target VM > > > > // working directory rather than the directory where jmap > > > > // is executed. > > > > filename = new File(filename).getCanonicalPath(); > > > > // inspectHeap is not the same as jcmd GC.class_histogram > > > > executeCommandForPid(pid, "inspectheap", filename, liveopt); > > > > > > > > I.e., use an enhanced for loop to scan the array, and duplicate dump()?s executeCommandForPid() argument order, as well as dump()?s ?file=<>? check (the code that starts with ?if (subopt.startsWith?) and canonicalization. Actually, better to factor the latter out into its own method and use it from both histo() and dump(). > > > > > > > > The argument checking code in heap_inspection() in attachListener.cpp can be simplified along the lines of dump_heap(). I.e., you don?t need to loop over the argument list. To match up with dump_heap()?s info messages, the info message string at the end should be ?Heap inspection file created: %s?. > > > > > > > > Thanks, > > > > > > > > Paul > > > > > > > > From: serviceability-dev > on behalf of ?? > > > Date: Thursday, December 20, 2018 at 11:03 PM > > To: "serviceability-dev at openjdk.java.net" > > > Subject: [RFR]8215622: Add dump to file support for jmap histo > > > > > > > > Hi All, > > > > May I ask your help to review this patch for enhance jmap ?histo. > > > > It add the ?file=? arguments that allow jmap ?histo outputs data to file directly. > > > > This patch is also part of the enhancement described in https://bugs.openjdk.java.net/browse/JDK-8214535. > > > > > > > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215622 > > > > > > > > Thanks. > > > > > > > > BRs, > > > > Lin > > > > > > > > > > > > > > > > > > -- > > > > Thanks, > > Jc > > > > > > -- > > > > Thanks, > > Jc > > > > > > -- > > > > Thanks, > > Jc > > > > > > > > > > > > > > > > > > > > > > > From joe.darcy at oracle.com Mon Feb 11 22:22:59 2019 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 11 Feb 2019 14:22:59 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> Message-ID: <5C61F5C3.2050605@oracle.com> On 2/11/2019 2:20 PM, Hohensee, Paul wrote: > The CSR was just closed, so we're stuck with doing another one later. Before a changeset is pushed, its CSR can be amended (Withdraw or back to draft, then refinalize after editing.) HTH -Joe From alexey.menkov at oracle.com Mon Feb 11 23:20:25 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 11 Feb 2019 15:20:25 -0800 Subject: RFR: JDK-8214582: BasicJDWPConnectionTest.java: RuntimeException: Could not detect port from '' Message-ID: <8d76b446-0313-d37e-cb93-db4f9a4d73b6@oracle.com> Hi all, Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8214582 webrev: http://cr.openjdk.java.net/~amenkov/BasicJDWPConnEmptyPort/webrev/ The change fixes race condition when debuggee (LingeredApp) touches lock file, but the test haven't handled "Listening for transport ... at address ..." output. Now the test waits up to 10 seconds (adjusted to TIMEOUT_FACTOR) for the required output. --alex From alexey.menkov at oracle.com Mon Feb 11 23:59:41 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 11 Feb 2019 15:59:41 -0800 Subject: RFR JDK-8218702: [TESTBUG] com/sun/jdi/RepStep.java does not report debuggee errors Message-ID: Hi all, please review the fix for https://bugs.openjdk.java.net/browse/JDK-8218702 webrev: http://cr.openjdk.java.net/~amenkov/RepStep_redirect/webrev/ The fix adds events logging and debuggee stdout/stderr redirection (the test now logs crash in debuggee as described in JDK-8043571) --alex From serguei.spitsyn at oracle.com Tue Feb 12 00:15:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Feb 2019 16:15:21 -0800 Subject: RFR: JDK-8214582: BasicJDWPConnectionTest.java: RuntimeException: Could not detect port from '' In-Reply-To: <8d76b446-0313-d37e-cb93-db4f9a4d73b6@oracle.com> References: <8d76b446-0313-d37e-cb93-db4f9a4d73b6@oracle.com> Message-ID: Hi Alex, It looks Okay to me. Thanks, Serguei On 2/11/19 15:20, Alex Menkov wrote: > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8214582 > webrev: > http://cr.openjdk.java.net/~amenkov/BasicJDWPConnEmptyPort/webrev/ > > The change fixes race condition when debuggee (LingeredApp) touches > lock file, but the test haven't handled "Listening for transport ... > at address ..." output. > Now the test waits up to 10 seconds (adjusted to TIMEOUT_FACTOR) for > the required output. > > --alex From serguei.spitsyn at oracle.com Tue Feb 12 00:32:03 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Feb 2019 16:32:03 -0800 Subject: RFR JDK-8218702: [TESTBUG] com/sun/jdi/RepStep.java does not report debuggee errors In-Reply-To: References: Message-ID: Hi Alex, This fix also looks good to me. Thanks, Serguei On 2/11/19 15:59, Alex Menkov wrote: > Hi all, > > please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8218702 > webrev: > http://cr.openjdk.java.net/~amenkov/RepStep_redirect/webrev/ > > The fix adds events logging and debuggee stdout/stderr redirection > (the test now logs crash in debuggee as described in JDK-8043571) > > --alex From daniil.x.titov at oracle.com Tue Feb 12 00:41:15 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 11 Feb 2019 16:41:15 -0800 Subject: RFR JDK-8218702: [TESTBUG] com/sun/jdi/RepStep.java does not report debuggee errors In-Reply-To: <0E501A83-B810-439D-B144-2A46524CB77C@oracle.com> References: <0E501A83-B810-439D-B144-2A46524CB77C@oracle.com> Message-ID: Hi Alex, The fix looks good for me. Best regards, Daniil ?On 2/11/19, 3:59 PM, "serviceability-dev on behalf of Alex Menkov" wrote: Hi all, please review the fix for https://bugs.openjdk.java.net/browse/JDK-8218702 webrev: http://cr.openjdk.java.net/~amenkov/RepStep_redirect/webrev/ The fix adds events logging and debuggee stdout/stderr redirection (the test now logs crash in debuggee as described in JDK-8043571) --alex From daniil.x.titov at oracle.com Tue Feb 12 00:44:18 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 11 Feb 2019 16:44:18 -0800 Subject: JDK-8214582: BasicJDWPConnectionTest.java: RuntimeException: Could not detect port from '' In-Reply-To: <0FA211B6-DE6F-43C0-AE2A-35C74B9D6E9C@oracle.com> References: <8d76b446-0313-d37e-cb93-db4f9a4d73b6@oracle.com> <0FA211B6-DE6F-43C0-AE2A-35C74B9D6E9C@oracle.com> Message-ID: Hi Alex, +1 Thanks, Daniil ?On 2/11/19, 4:17 PM, "serviceability-dev on behalf of serguei.spitsyn at oracle.com" wrote: Hi Alex, It looks Okay to me. Thanks, Serguei On 2/11/19 15:20, Alex Menkov wrote: > Hi all, > > Please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8214582 > webrev: > http://cr.openjdk.java.net/~amenkov/BasicJDWPConnEmptyPort/webrev/ > > The change fixes race condition when debuggee (LingeredApp) touches > lock file, but the test haven't handled "Listening for transport ... > at address ..." output. > Now the test waits up to 10 seconds (adjusted to TIMEOUT_FACTOR) for > the required output. > > --alex From zanglin5 at jd.com Tue Feb 12 01:49:54 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Tue, 12 Feb 2019 01:49:54 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <5C61F5C3.2050605@oracle.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com>, <5C61F5C3.2050605@oracle.com> Message-ID: Dear All, Thanks again for the comments. one question from me is that "jmap -dump" must accept an argument indicates location of the heap dump file. if there is no such argument, it fails. (it is meaningless to output the binary directly to stdout/stderr for me.) so adding "jmap -dump" actually just output error message like "No dump file specified", rather than print the usage of JMap as implemented now. And this is also why there is no "-dump" or "-dump:" test in BasicJMapTest.java. Another option is to add default file generated at canonical path for -dump. then I can add the unit test. which one do you think is more reasonable? Moreover, one minor thing is that BasicJMapTest right now has test for "jmap -histo:" , not for "jmap -histo", so I think I need to add test for that. is this OK? Cheers, Lin ________________________________________ From: Joseph D. Darcy Sent: Tuesday, February 12, 2019 6:22:59 AM To: Hohensee, Paul; serguei.spitsyn at oracle.com; ??; David Holmes; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo On 2/11/2019 2:20 PM, Hohensee, Paul wrote: > The CSR was just closed, so we're stuck with doing another one later. Before a changeset is pushed, its CSR can be amended (Withdraw or back to draft, then refinalize after editing.) HTH -Joe From serguei.spitsyn at oracle.com Tue Feb 12 02:32:44 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 11 Feb 2019 18:32:44 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> Message-ID: <6df6f3cb-f7b8-9551-32f0-1e060847628a@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Feb 12 02:32:49 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 11 Feb 2019 18:32:49 -0800 Subject: RFR JDK-8218702: [TESTBUG] com/sun/jdi/RepStep.java does not report debuggee errors In-Reply-To: References: Message-ID: <1e320201-59aa-eb72-a817-893d23949512@oracle.com> How is this test different from other JDI tests in its handling of stdout and stderr? Why is it a special case that needs this fix? Chris On 2/11/19 3:59 PM, Alex Menkov wrote: > Hi all, > > please review the fix for > https://bugs.openjdk.java.net/browse/JDK-8218702 > webrev: > http://cr.openjdk.java.net/~amenkov/RepStep_redirect/webrev/ > > The fix adds events logging and debuggee stdout/stderr redirection > (the test now logs crash in debuggee as described in JDK-8043571) > > --alex From gary.adams at oracle.com Tue Feb 12 10:08:48 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 12 Feb 2019 05:08:48 -0500 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest Message-ID: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> The recent change to JDK-8068225 changed the order of operations in Debugee.endDebugee() to wait for the debugee to exit before disposing of the vm on the debugger side of the connection. For the tests based on JDIBreakpointTest the debuggee exit status is not used and the tests relied on the debugger side dispose operation to end the test. Since JDIBreakpointTest already includes a call to wait for the debugee, if does not need to use endDebuggee() to dispose and wait for the debugee to finish. Testing in progress. The vm/mlvm tests are included in tiers 2, 3 and 6. diff --git a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java --- a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java +++ b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java @@ -1,5 +1,5 @@ ?/* - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights reserved. ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ? * ? * This code is free software; you can redistribute it and/or modify it @@ -359,7 +359,7 @@ ???????? }.go(); ???????? if (!debuggee.terminated()) -??????????? debuggee.endDebugee(); +??????????? debuggee.dispose(); ???????? debuggee.waitFor(); ???????? return true; From gary.adams at oracle.com Tue Feb 12 11:59:06 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 12 Feb 2019 06:59:06 -0500 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> Message-ID: <5C62B50A.9050601@oracle.com> Have to guard against multiple calls to dispose. Revised webrev: http://cr.openjdk.java.net/~gadams/8218754/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8218754 On 2/12/19, 5:08 AM, gary.adams at oracle.com wrote: > The recent change to JDK-8068225 changed the order of operations > in Debugee.endDebugee() to wait for the debugee to exit before > disposing of the vm on the debugger side of the connection. > For the tests based on JDIBreakpointTest the debuggee exit > status is not used and the tests relied on the > debugger side dispose operation to end the test. > > Since JDIBreakpointTest already includes a call to wait for > the debugee, if does not need to use endDebuggee() > to dispose and wait for the debugee to finish. > > Testing in progress. The vm/mlvm tests are included in tiers 2, 3 and 6. > > diff --git > a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java > b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java > --- > a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java > +++ > b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -359,7 +359,7 @@ > }.go(); > > if (!debuggee.terminated()) > - debuggee.endDebugee(); > + debuggee.dispose(); > > debuggee.waitFor(); > return true; > From david.holmes at oracle.com Tue Feb 12 11:59:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2019 21:59:32 +1000 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> Message-ID: <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> Hi Gary, On 12/02/2019 8:08 pm, gary.adams at oracle.com wrote: > The recent change to JDK-8068225 changed the order of operations > in Debugee.endDebugee() to wait for the debugee to exit before > disposing of the vm on the debugger side of the connection. > For the tests based on JDIBreakpointTest the debuggee exit > status is not used and the tests relied on the > debugger side dispose operation to end the test. > > Since JDIBreakpointTest already includes a call to wait for > the debugee, if does not need to use endDebuggee() > to dispose and wait for the debugee to finish. I agree that potentially calling waitFor twice seems pointless. But how did the reordering of vm.dispose() and waitFor() cause all these tests to hang if they were waiting anyway? Does vm.dispose() have an effect on destroying the process? Also what concerns me is that dispose() is not resilient the way that endDebuggee is: public void dispose() { vm.dispose(); } versus public int endDebugee() { if (vm != null) { try { vm.dispose(); } catch (VMDisconnectedException ignore) { } vm = null; } Do we need to be concerned with a null VM or getting VMDisconnectedException? Thanks, David > Testing in progress. The vm/mlvm tests are included in tiers 2, 3 and 6. > > diff --git > a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java > b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java > --- > a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java > +++ > b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java > @@ -1,5 +1,5 @@ > ?/* > - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All rights > reserved. > ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > ? * > ? * This code is free software; you can redistribute it and/or modify it > @@ -359,7 +359,7 @@ > ???????? }.go(); > > ???????? if (!debuggee.terminated()) > -??????????? debuggee.endDebugee(); > +??????????? debuggee.dispose(); > > ???????? debuggee.waitFor(); > ???????? return true; > From gary.adams at oracle.com Tue Feb 12 12:11:19 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 12 Feb 2019 07:11:19 -0500 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> Message-ID: <5C62B7E7.4040206@oracle.com> Yes, see the revised webrev, we do have to guard against multiple calls to dispose, e.g. catch and ignore VMDisconnectException. We don't need to guard against a null vm. That would only exist if the vm was never initialized and we were shutting down. There is a race condition between the debuggee and the debugger process. In the original endDebugee, it attempted to do 2 things in parallel. By calling dispose then waitFor, in most cases the debugee would finish and report status before all the dispose operations completed. But some tests would fail if the dispose happened quicker than the debuggee could report final exit status. The tests based on JDIBreakpointTest on the other hand don't really care about the the final exit status. Once all the events have been seen and handled, the test wants to shutdown the session. On 2/12/19, 6:59 AM, David Holmes wrote: > Hi Gary, > > On 12/02/2019 8:08 pm, gary.adams at oracle.com wrote: >> The recent change to JDK-8068225 changed the order of operations >> in Debugee.endDebugee() to wait for the debugee to exit before >> disposing of the vm on the debugger side of the connection. >> For the tests based on JDIBreakpointTest the debuggee exit >> status is not used and the tests relied on the >> debugger side dispose operation to end the test. >> >> Since JDIBreakpointTest already includes a call to wait for >> the debugee, if does not need to use endDebuggee() >> to dispose and wait for the debugee to finish. > > I agree that potentially calling waitFor twice seems pointless. But > how did the reordering of vm.dispose() and waitFor() cause all these > tests to hang if they were waiting anyway? Does vm.dispose() have an > effect on destroying the process? > > Also what concerns me is that dispose() is not resilient the way that > endDebuggee is: > > public void dispose() { > vm.dispose(); > } > > versus > > public int endDebugee() { > if (vm != null) { > try { > vm.dispose(); > } catch (VMDisconnectedException ignore) { > } > vm = null; > } > > Do we need to be concerned with a null VM or getting > VMDisconnectedException? > > Thanks, > David > >> Testing in progress. The vm/mlvm tests are included in tiers 2, 3 and 6. >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >> --- >> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >> +++ >> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or >> modify it >> @@ -359,7 +359,7 @@ >> }.go(); >> >> if (!debuggee.terminated()) >> - debuggee.endDebugee(); >> + debuggee.dispose(); >> >> debuggee.waitFor(); >> return true; >> From david.holmes at oracle.com Tue Feb 12 12:14:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Feb 2019 22:14:34 +1000 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: <5C62B7E7.4040206@oracle.com> References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> <5C62B7E7.4040206@oracle.com> Message-ID: <9d83e496-22db-f157-9f78-2efce7429e41@oracle.com> On 12/02/2019 10:11 pm, Gary Adams wrote: > Yes, see the revised webrev, we do have to guard against > multiple calls to dispose, e.g. catch and ignore VMDisconnectException. > We don't need to guard against a null vm. That would only exist if > the vm was never initialized and we were shutting down. Okay. Revised webrev is better in that regard. > There is a race condition between the debuggee and the debugger process. > In the original endDebugee, it attempted to do 2 things in parallel. > By calling dispose then waitFor, in most cases the debugee would finish > and report status before all the dispose operations completed. > But some tests would fail if the dispose happened quicker than the debuggee > could report final exit status. > > The tests based on JDIBreakpointTest on? the other hand don't really > care about the the final exit status. Once all the events have been seen > and handled, the test wants to shutdown the session. I'm still not seeing how JDIBreakpointTest started hanging/timing-out after you switched the order of dispose and waitFor. Does dispose affect the debuggee process or the debugger process? Thanks, David > > On 2/12/19, 6:59 AM, David Holmes wrote: >> Hi Gary, >> >> On 12/02/2019 8:08 pm, gary.adams at oracle.com wrote: >>> The recent change to JDK-8068225 changed the order of operations >>> in Debugee.endDebugee() to wait for the debugee to exit before >>> disposing of the vm on the debugger side of the connection. >>> For the tests based on JDIBreakpointTest the debuggee exit >>> status is not used and the tests relied on the >>> debugger side dispose operation to end the test. >>> >>> Since JDIBreakpointTest already includes a call to wait for >>> the debugee, if does not need to use endDebuggee() >>> to dispose and wait for the debugee to finish. >> >> I agree that potentially calling waitFor twice seems pointless. But >> how did the reordering of vm.dispose() and waitFor() cause all these >> tests to hang if they were waiting anyway? Does vm.dispose() have an >> effect on destroying the process? >> >> Also what concerns me is that dispose() is not resilient the way that >> endDebuggee is: >> >> ?public void dispose() { >> ??? vm.dispose(); >> ?} >> >> versus >> >> ??? public int endDebugee() { >> ??????? if (vm != null) { >> ??????????? try { >> ??????????????? vm.dispose(); >> ??????????? } catch (VMDisconnectedException ignore) { >> ??????????? } >> ??????????? vm = null; >> ??????? } >> >> Do we need to be concerned with a null VM or getting >> VMDisconnectedException? >> >> Thanks, >> David >> >>> Testing in progress. The vm/mlvm tests are included in tiers 2, 3 and 6. >>> >>> diff --git >>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>> --- >>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>> +++ >>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>> @@ -1,5 +1,5 @@ >>> ? /* >>> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All >>> rights reserved. >>> + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All >>> rights reserved. >>> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> ?? * >>> ?? * This code is free software; you can redistribute it and/or >>> modify it >>> @@ -359,7 +359,7 @@ >>> ????????? }.go(); >>> >>> ????????? if (!debuggee.terminated()) >>> -??????????? debuggee.endDebugee(); >>> +??????????? debuggee.dispose(); >>> >>> ????????? debuggee.waitFor(); >>> ????????? return true; >>> > From gary.adams at oracle.com Tue Feb 12 12:40:36 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 12 Feb 2019 07:40:36 -0500 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: <9d83e496-22db-f157-9f78-2efce7429e41@oracle.com> References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> <5C62B7E7.4040206@oracle.com> <9d83e496-22db-f157-9f78-2efce7429e41@oracle.com> Message-ID: <5C62BEC4.20704@oracle.com> On 2/12/19, 7:14 AM, David Holmes wrote: > On 12/02/2019 10:11 pm, Gary Adams wrote: >> Yes, see the revised webrev, we do have to guard against >> multiple calls to dispose, e.g. catch and ignore VMDisconnectException. >> We don't need to guard against a null vm. That would only exist if >> the vm was never initialized and we were shutting down. > > Okay. Revised webrev is better in that regard. One more round to add the import for VMDisconnectedException. Webrev: http://cr.openjdk.java.net/~gadams/8218754/webrev.01/ > >> There is a race condition between the debuggee and the debugger process. >> In the original endDebugee, it attempted to do 2 things in parallel. >> By calling dispose then waitFor, in most cases the debugee would finish >> and report status before all the dispose operations completed. >> But some tests would fail if the dispose happened quicker than the >> debuggee >> could report final exit status. >> >> The tests based on JDIBreakpointTest on the other hand don't really >> care about the the final exit status. Once all the events have been >> seen and handled, the test wants to shutdown the session. > > I'm still not seeing how JDIBreakpointTest started hanging/timing-out > after you switched the order of dispose and waitFor. Does dispose > affect the debuggee process or the debugger process? The JDIBreakpointTest would timeout on the endDebugee call to waitFor. There was no reason for the debugee to exit at that point. The call to dispose, provided the debugee with it's reason to exit. Not sure which operation induces the debugee to exit. > > Thanks, > David > >> >> On 2/12/19, 6:59 AM, David Holmes wrote: >>> Hi Gary, >>> >>> On 12/02/2019 8:08 pm, gary.adams at oracle.com wrote: >>>> The recent change to JDK-8068225 changed the order of operations >>>> in Debugee.endDebugee() to wait for the debugee to exit before >>>> disposing of the vm on the debugger side of the connection. >>>> For the tests based on JDIBreakpointTest the debuggee exit >>>> status is not used and the tests relied on the >>>> debugger side dispose operation to end the test. >>>> >>>> Since JDIBreakpointTest already includes a call to wait for >>>> the debugee, if does not need to use endDebuggee() >>>> to dispose and wait for the debugee to finish. >>> >>> I agree that potentially calling waitFor twice seems pointless. But >>> how did the reordering of vm.dispose() and waitFor() cause all these >>> tests to hang if they were waiting anyway? Does vm.dispose() have an >>> effect on destroying the process? >>> >>> Also what concerns me is that dispose() is not resilient the way >>> that endDebuggee is: >>> >>> public void dispose() { >>> vm.dispose(); >>> } >>> >>> versus >>> >>> public int endDebugee() { >>> if (vm != null) { >>> try { >>> vm.dispose(); >>> } catch (VMDisconnectedException ignore) { >>> } >>> vm = null; >>> } >>> >>> Do we need to be concerned with a null VM or getting >>> VMDisconnectedException? >>> >>> Thanks, >>> David >>> >>>> Testing in progress. The vm/mlvm tests are included in tiers 2, 3 >>>> and 6. >>>> >>>> diff --git >>>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>> >>>> --- >>>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>> >>>> +++ >>>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>> >>>> @@ -1,5 +1,5 @@ >>>> /* >>>> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All >>>> rights reserved. >>>> + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All >>>> rights reserved. >>>> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>> * >>>> * This code is free software; you can redistribute it and/or >>>> modify it >>>> @@ -359,7 +359,7 @@ >>>> }.go(); >>>> >>>> if (!debuggee.terminated()) >>>> - debuggee.endDebugee(); >>>> + debuggee.dispose(); >>>> >>>> debuggee.waitFor(); >>>> return true; >>>> >> From hohensee at amazon.com Tue Feb 12 15:27:47 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 12 Feb 2019 15:27:47 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <5C61F5C3.2050605@oracle.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <70826c967ec543df9febd907812d4361@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> Message-ID: I don't see a way to change the Status from Closed to anything else. There's no option I can find to do so. Thanks, Paul ?On 2/11/19, 2:24 PM, "Joseph D. Darcy" wrote: On 2/11/2019 2:20 PM, Hohensee, Paul wrote: > The CSR was just closed, so we're stuck with doing another one later. Before a changeset is pushed, its CSR can be amended (Withdraw or back to draft, then refinalize after editing.) HTH -Joe From hohensee at amazon.com Tue Feb 12 15:30:01 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 12 Feb 2019 15:30:01 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <6df6f3cb-f7b8-9551-32f0-1e060847628a@oracle.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> <6df6f3cb-f7b8-9551-32f0-1e060847628a@oracle.com> Message-ID: <04848470-0B2A-4F36-8E3D-87581FEB74D3@amazon.com> I agree, let?s leave the dump option alone for now. Changing ?and? to ?or? is just a slight grammar correctness fix. Thanks, Paul From: "serguei.spitsyn at oracle.com" Date: Monday, February 11, 2019 at 6:33 PM To: ?? , "Joseph D. Darcy" , "Hohensee, Paul" , David Holmes , JC Beyler Cc: "serviceability-dev at openjdk.java.net" Subject: Re: [RFR]8215622: Add dump to file support for jmap histo Dear Lin, On 2/11/19 17:49, ?? wrote: Dear All, Thanks again for the comments. one question from me is that "jmap -dump" must accept an argument indicates location of the heap dump file. if there is no such argument, it fails. (it is meaningless to output the binary directly to stdout/stderr for me.) Does the option "format=b" tells us that the dump output can be in text format as well? The help tells nothing about what is the default format. I'd conclude that the default has to be text format if the option "format=b" is missed. Now, I'm looking at the option processing in the dump() method and see that option "format=b" is not really processed but just filtered out. It means that you are right, the only supported dumping format is binary. In this situation, I withdraw my suggestion to allow empty . At least, you do not need to care about it. However, there is still the suggestion from Paul to replace "and" with "or" in both dump-options and histo-options. so adding "jmap -dump" actually just output error message like "No dump file specified", rather than print the usage of JMap as implemented now. And this is also why there is no "-dump" or "-dump:" test in BasicJMapTest.java. I leave it to other people to decide what is better here. Another option is to add default file generated at canonical path for -dump. then I can add the unit test. which one do you think is more reasonable? It looks like a good idea. But I'm not sure about it yet. Let's see what others say. Moreover, one minor thing is that BasicJMapTest right now has test for "jmap -histo:" , not for "jmap -histo", so I think I need to add test for that. is this OK? Yes. Thanks, Serguei Cheers, Lin ________________________________________ From: Joseph D. Darcy Sent: Tuesday, February 12, 2019 6:22:59 AM To: Hohensee, Paul; serguei.spitsyn at oracle.com; ??; David Holmes; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo On 2/11/2019 2:20 PM, Hohensee, Paul wrote: The CSR was just closed, so we're stuck with doing another one later. Before a changeset is pushed, its CSR can be amended (Withdraw or back to draft, then refinalize after editing.) HTH -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Tue Feb 12 15:32:48 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 Feb 2019 15:32:48 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <068399ec-fbb8-b881-7ea2-1b684a42652a@redhat.com> References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> <1fd9aa7f-c5f5-80ef-dd47-73756a318d31@redhat.com> <068399ec-fbb8-b881-7ea2-1b684a42652a@redhat.com> Message-ID: <976b890a-79e6-e8d1-e516-97e15bdb6658@redhat.com> What's the status of this? Are you still looking at it? On 2/7/19 3:39 PM, Andrew Haley wrote: > On 2/7/19 2:36 PM, Nick Gasson (Arm Technology China) wrote: >> >> Yeah I tried this method too (see the end of my first email). It >> works fine except the PC is off by a few instructions. That can be >> fixed quite easily though if required, and it always points into the >> right method. > > We should fix those few cases. > >> I ended up doing the stack scanning thing because as far as I can >> tell that constructor is only used when we need to find the return >> PC from a native frame > > I don't think that ever happens. In the code I modified we know that > we have a good PC in the frame anchor. In the cases where we have a > native frame on the stack and nothing in the frame anchor we give > up. At least, I can see no counter-cases. > >> (I might have been wrong about this), so I couldn't see how it would >> ever get the right value. If we check vm.isJavaPCDbg() before we use >> the SP[-1] value that will make the remaining callers a bit safer >> (and set this.pc to null otherwise). > > That would be safe, for sure. > -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.fuchs at oracle.com Tue Feb 12 15:38:45 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 12 Feb 2019 16:38:45 +0100 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> Message-ID: <7ae12430-7fe3-3492-b9c6-8cc917766992@oracle.com> Hi Paul, On 12/02/2019 16:27, Hohensee, Paul wrote: > I don't see a way to change the Status from Closed to anything else. There's no option I can find to do so. It may be that only the assignee can see this. On the closed CSRs assigned to me I can see a "Back to Draft" button next to "More". Hope this helps, -- daniel From joe.darcy at oracle.com Tue Feb 12 17:06:44 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Feb 2019 09:06:44 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <7ae12430-7fe3-3492-b9c6-8cc917766992@oracle.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> <7ae12430-7fe3-3492-b9c6-8cc917766992@oracle.com> Message-ID: Yes, if you make yourself the assignee, you can change the state of the request (and then change the assignee back to the original person). HTH, -Joe On 2/12/2019 7:38 AM, Daniel Fuchs wrote: > Hi Paul, > > On 12/02/2019 16:27, Hohensee, Paul wrote: >> I don't see a way to change the Status from Closed to anything else. >> There's no option I can find to do so. > > It may be that only the assignee can see this. > On the closed CSRs assigned to me I can see a "Back to Draft" button > next to "More". > > Hope this helps, > > -- daniel From serguei.spitsyn at oracle.com Tue Feb 12 17:12:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Feb 2019 09:12:36 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <04848470-0B2A-4F36-8E3D-87581FEB74D3@amazon.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> <6df6f3cb-f7b8-9551-32f0-1e060847628a@oracle.com> <04848470-0B2A-4F36-8E3D-87581FEB74D3@amazon.com> Message-ID: <67b64641-4fe8-6112-b1a9-68a39ae81f56@oracle.com> An HTML attachment was scrubbed... URL: From hohensee at amazon.com Tue Feb 12 18:36:45 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 12 Feb 2019 18:36:45 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> <3f34421b11514358af3ed110b830a7f3@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> <7ae12430-7fe3-3492-b9c6-8cc917766992@oracle.com> Message-ID: <888EC94F-DAB9-4114-B81B-0C74936C78EB@amazon.com> Thanks, Joe and Daniel. Doesn't seem that we need it for this case anymore, but it's good to know how to proceed in the future. :) Paul ?On 2/12/19, 9:07 AM, "Joe Darcy" wrote: Yes, if you make yourself the assignee, you can change the state of the request (and then change the assignee back to the original person). HTH, -Joe On 2/12/2019 7:38 AM, Daniel Fuchs wrote: > Hi Paul, > > On 12/02/2019 16:27, Hohensee, Paul wrote: >> I don't see a way to change the Status from Closed to anything else. >> There's no option I can find to do so. > > It may be that only the assignee can see this. > On the closed CSRs assigned to me I can see a "Back to Draft" button > next to "More". > > Hope this helps, > > -- daniel From gary.adams at oracle.com Tue Feb 12 19:04:05 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 12 Feb 2019 14:04:05 -0500 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: <5C62BEC4.20704@oracle.com> References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> <5C62B7E7.4040206@oracle.com> <9d83e496-22db-f157-9f78-2efce7429e41@oracle.com> <5C62BEC4.20704@oracle.com> Message-ID: <9bfb9980-5293-cf46-c4c1-dba0a9c55cfa@oracle.com> Successfully ran 100X {solaris,macosx,windows,linux} debug builds for the tests impacted by Debugee.endDebugee() processing. |test/hotspot/jtreg/vmTestbase/nsk/jdi test/hotspot/jtreg/vmTestbase/vm/mlvm test/jdk/com/sun/jdi| On 2/12/19 7:40 AM, Gary Adams wrote: > On 2/12/19, 7:14 AM, David Holmes wrote: >> On 12/02/2019 10:11 pm, Gary Adams wrote: >>> Yes, see the revised webrev, we do have to guard against >>> multiple calls to dispose, e.g. catch and ignore VMDisconnectException. >>> We don't need to guard against a null vm. That would only exist if >>> the vm was never initialized and we were shutting down. >> >> Okay. Revised webrev is better in that regard. > One more round to add the import for VMDisconnectedException. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8218754/webrev.01/ >> >>> There is a race condition between the debuggee and the debugger >>> process. >>> In the original endDebugee, it attempted to do 2 things in parallel. >>> By calling dispose then waitFor, in most cases the debugee would finish >>> and report status before all the dispose operations completed. >>> But some tests would fail if the dispose happened quicker than the >>> debuggee >>> could report final exit status. >>> >>> The tests based on JDIBreakpointTest on? the other hand don't really >>> care about the the final exit status. Once all the events have been >>> seen and handled, the test wants to shutdown the session. >> >> I'm still not seeing how JDIBreakpointTest started hanging/timing-out >> after you switched the order of dispose and waitFor. Does dispose >> affect the debuggee process or the debugger process? > The JDIBreakpointTest would timeout on the endDebugee call to waitFor. > There was no reason for the debugee to exit at that point. > The call to dispose, provided the debugee with it's reason to exit. > Not sure which operation induces the debugee to exit. >> >> Thanks, >> David >> >>> >>> On 2/12/19, 6:59 AM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> On 12/02/2019 8:08 pm, gary.adams at oracle.com wrote: >>>>> The recent change to JDK-8068225 changed the order of operations >>>>> in Debugee.endDebugee() to wait for the debugee to exit before >>>>> disposing of the vm on the debugger side of the connection. >>>>> For the tests based on JDIBreakpointTest the debuggee exit >>>>> status is not used and the tests relied on the >>>>> debugger side dispose operation to end the test. >>>>> >>>>> Since JDIBreakpointTest already includes a call to wait for >>>>> the debugee, if does not need to use endDebuggee() >>>>> to dispose and wait for the debugee to finish. >>>> >>>> I agree that potentially calling waitFor twice seems pointless. But >>>> how did the reordering of vm.dispose() and waitFor() cause all >>>> these tests to hang if they were waiting anyway? Does vm.dispose() >>>> have an effect on destroying the process? >>>> >>>> Also what concerns me is that dispose() is not resilient the way >>>> that endDebuggee is: >>>> >>>> ?public void dispose() { >>>> ??? vm.dispose(); >>>> ?} >>>> >>>> versus >>>> >>>> ??? public int endDebugee() { >>>> ??????? if (vm != null) { >>>> ??????????? try { >>>> ??????????????? vm.dispose(); >>>> ??????????? } catch (VMDisconnectedException ignore) { >>>> ??????????? } >>>> ??????????? vm = null; >>>> ??????? } >>>> >>>> Do we need to be concerned with a null VM or getting >>>> VMDisconnectedException? >>>> >>>> Thanks, >>>> David >>>> >>>>> Testing in progress. The vm/mlvm tests are included in tiers 2, 3 >>>>> and 6. >>>>> >>>>> diff --git >>>>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>> >>>>> --- >>>>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>> >>>>> +++ >>>>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>> >>>>> @@ -1,5 +1,5 @@ >>>>> ? /* >>>>> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> ?? * >>>>> ?? * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> @@ -359,7 +359,7 @@ >>>>> ????????? }.go(); >>>>> >>>>> ????????? if (!debuggee.terminated()) >>>>> -??????????? debuggee.endDebugee(); >>>>> +??????????? debuggee.dispose(); >>>>> >>>>> ????????? debuggee.waitFor(); >>>>> ????????? return true; >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue Feb 12 19:24:12 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 12 Feb 2019 11:24:12 -0800 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: <9bfb9980-5293-cf46-c4c1-dba0a9c55cfa@oracle.com> References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> <5C62B7E7.4040206@oracle.com> <9d83e496-22db-f157-9f78-2efce7429e41@oracle.com> <5C62BEC4.20704@oracle.com> <9bfb9980-5293-cf46-c4c1-dba0a9c55cfa@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From calvin.cheung at oracle.com Tue Feb 12 19:29:03 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 12 Feb 2019 11:29:03 -0800 Subject: RFR(S) 8218751 Do not store original classfiles inside the CDS archive In-Reply-To: References: Message-ID: <5C631E7F.8020907@oracle.com> Hi Ioi, The following call is probably slower than before because it involves reading from a jar file. cfs = FileMapInfo::open_stream_for_jvmti(ik, CHECK_NULL); It is probably ok since the above is called under the following condition: if (JvmtiExport::should_post_class_file_load_hook()) Minor comments in the following 2 files: filemap.cpp 1494 assert(path_index >= 0, "should be called for shared built-in classes only"); Should the above be also checking (path_index < ClassLoaderExt::app_class_paths_start_index())? SpaceUtilizationCheck.java 106 throw new RuntimeException("Must have 5 consecutive, fully utilized regions"); 5 should be 4 thanks, Calvin On 2/11/19, 9:23 AM, Ioi Lam wrote: > http://cr.openjdk.java.net/~iklam/jdk13/8218751-dont-store-classfiles-in-cds.v01/ > > https://bugs.openjdk.java.net/browse/JDK-8218751 > > For JVMTI ClassFileLoadHook support, the CDS archive currently stores > the original classfile data of all archived classes. > > However, this consists of over 30% of the archive size. Because all > original classfile data are already available in other files (such as the > JDK lib/modules file, or JAR files in the classpath), we can simply read > from these locations when needed by JVMTI. > > For the default CDS archive (included as part of the JDK distribution), > the size is reduced from about 18.5MB to 12.1MB on Linux/x64. > > Thanks > > - Ioi > From serguei.spitsyn at oracle.com Tue Feb 12 20:00:16 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Feb 2019 12:00:16 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <888EC94F-DAB9-4114-B81B-0C74936C78EB@amazon.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> <7ae12430-7fe3-3492-b9c6-8cc917766992@oracle.com> <888EC94F-DAB9-4114-B81B-0C74936C78EB@amazon.com> Message-ID: On 2/12/19 10:36 AM, Hohensee, Paul wrote: > Thanks, Joe and Daniel. Doesn't seem that we need it for this case anymore, but it's good to know how to proceed in the future. :) Agreed. Thanks, Serguei > > Paul > > ?On 2/12/19, 9:07 AM, "Joe Darcy" wrote: > > Yes, if you make yourself the assignee, you can change the state of the > request (and then change the assignee back to the original person). > > HTH, > > -Joe > > On 2/12/2019 7:38 AM, Daniel Fuchs wrote: > > Hi Paul, > > > > On 12/02/2019 16:27, Hohensee, Paul wrote: > >> I don't see a way to change the Status from Closed to anything else. > >> There's no option I can find to do so. > > > > It may be that only the assignee can see this. > > On the closed CSRs assigned to me I can see a "Back to Draft" button > > next to "More". > > > > Hope this helps, > > > > -- daniel > > From serguei.spitsyn at oracle.com Tue Feb 12 20:10:42 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Feb 2019 12:10:42 -0800 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> <5C62B7E7.4040206@oracle.com> <9d83e496-22db-f157-9f78-2efce7429e41@oracle.com> <5C62BEC4.20704@oracle.com> <9bfb9980-5293-cf46-c4c1-dba0a9c55cfa@oracle.com> Message-ID: Hi Gary, +1 Thanks, Serguei On 2/12/19 11:24 AM, Chris Plummer wrote: > Hi Gary, > > The changes look good. > > thanks, > > Chris > > On 2/12/19 11:04 AM, gary.adams at oracle.com wrote: >> Successfully ran 100X {solaris,macosx,windows,linux} debug builds >> for the tests impacted by Debugee.endDebugee() processing. >> |test/hotspot/jtreg/vmTestbase/nsk/jdi >> test/hotspot/jtreg/vmTestbase/vm/mlvm test/jdk/com/sun/jdi| >> On 2/12/19 7:40 AM, Gary Adams wrote: >>> On 2/12/19, 7:14 AM, David Holmes wrote: >>>> On 12/02/2019 10:11 pm, Gary Adams wrote: >>>>> Yes, see the revised webrev, we do have to guard against >>>>> multiple calls to dispose, e.g. catch and ignore >>>>> VMDisconnectException. >>>>> We don't need to guard against a null vm. That would only exist if >>>>> the vm was never initialized and we were shutting down. >>>> >>>> Okay. Revised webrev is better in that regard. >>> One more round to add the import for VMDisconnectedException. >>> >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8218754/webrev.01/ >>>> >>>>> There is a race condition between the debuggee and the debugger >>>>> process. >>>>> In the original endDebugee, it attempted to do 2 things in parallel. >>>>> By calling dispose then waitFor, in most cases the debugee would >>>>> finish >>>>> and report status before all the dispose operations completed. >>>>> But some tests would fail if the dispose happened quicker than the >>>>> debuggee >>>>> could report final exit status. >>>>> >>>>> The tests based on JDIBreakpointTest on? the other hand don't really >>>>> care about the the final exit status. Once all the events have >>>>> been seen and handled, the test wants to shutdown the session. >>>> >>>> I'm still not seeing how JDIBreakpointTest started >>>> hanging/timing-out after you switched the order of dispose and >>>> waitFor. Does dispose affect the debuggee process or the debugger >>>> process? >>> The JDIBreakpointTest would timeout on the endDebugee call to waitFor. >>> There was no reason for the debugee to exit at that point. >>> The call to dispose, provided the debugee with it's reason to exit. >>> Not sure which operation induces the debugee to exit. >>>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> On 2/12/19, 6:59 AM, David Holmes wrote: >>>>>> Hi Gary, >>>>>> >>>>>> On 12/02/2019 8:08 pm, gary.adams at oracle.com wrote: >>>>>>> The recent change to JDK-8068225 changed the order of operations >>>>>>> in Debugee.endDebugee() to wait for the debugee to exit before >>>>>>> disposing of the vm on the debugger side of the connection. >>>>>>> For the tests based on JDIBreakpointTest the debuggee exit >>>>>>> status is not used and the tests relied on the >>>>>>> debugger side dispose operation to end the test. >>>>>>> >>>>>>> Since JDIBreakpointTest already includes a call to wait for >>>>>>> the debugee, if does not need to use endDebuggee() >>>>>>> to dispose and wait for the debugee to finish. >>>>>> >>>>>> I agree that potentially calling waitFor twice seems pointless. >>>>>> But how did the reordering of vm.dispose() and waitFor() cause >>>>>> all these tests to hang if they were waiting anyway? Does >>>>>> vm.dispose() have an effect on destroying the process? >>>>>> >>>>>> Also what concerns me is that dispose() is not resilient the way >>>>>> that endDebuggee is: >>>>>> >>>>>> ?public void dispose() { >>>>>> ??? vm.dispose(); >>>>>> ?} >>>>>> >>>>>> versus >>>>>> >>>>>> ??? public int endDebugee() { >>>>>> ??????? if (vm != null) { >>>>>> ??????????? try { >>>>>> ??????????????? vm.dispose(); >>>>>> ??????????? } catch (VMDisconnectedException ignore) { >>>>>> ??????????? } >>>>>> ??????????? vm = null; >>>>>> ??????? } >>>>>> >>>>>> Do we need to be concerned with a null VM or getting >>>>>> VMDisconnectedException? >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Testing in progress. The vm/mlvm tests are included in tiers 2, >>>>>>> 3 and 6. >>>>>>> >>>>>>> diff --git >>>>>>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>>>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>>>> >>>>>>> --- >>>>>>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>>>> >>>>>>> +++ >>>>>>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>>>> >>>>>>> @@ -1,5 +1,5 @@ >>>>>>> ? /* >>>>>>> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All >>>>>>> rights reserved. >>>>>>> + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All >>>>>>> rights reserved. >>>>>>> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>>>> ?? * >>>>>>> ?? * This code is free software; you can redistribute it and/or >>>>>>> modify it >>>>>>> @@ -359,7 +359,7 @@ >>>>>>> ????????? }.go(); >>>>>>> >>>>>>> ????????? if (!debuggee.terminated()) >>>>>>> -??????????? debuggee.endDebugee(); >>>>>>> +??????????? debuggee.dispose(); >>>>>>> >>>>>>> ????????? debuggee.waitFor(); >>>>>>> ????????? return true; >>>>>>> >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue Feb 12 20:45:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Feb 2019 06:45:34 +1000 Subject: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest In-Reply-To: <5C62BEC4.20704@oracle.com> References: <11172cf4-05be-e5ff-3353-2cf10f460a3a@oracle.com> <6cb73284-de24-aeb6-7cad-31d38a4cc011@oracle.com> <5C62B7E7.4040206@oracle.com> <9d83e496-22db-f157-9f78-2efce7429e41@oracle.com> <5C62BEC4.20704@oracle.com> Message-ID: <040194b4-0ffb-b9cf-087c-462cace55205@oracle.com> On 12/02/2019 10:40 pm, Gary Adams wrote: > On 2/12/19, 7:14 AM, David Holmes wrote: >> On 12/02/2019 10:11 pm, Gary Adams wrote: >>> Yes, see the revised webrev, we do have to guard against >>> multiple calls to dispose, e.g. catch and ignore VMDisconnectException. >>> We don't need to guard against a null vm. That would only exist if >>> the vm was never initialized and we were shutting down. >> >> Okay. Revised webrev is better in that regard. > One more round to add the import for VMDisconnectedException. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8218754/webrev.01/ Okay. >> >>> There is a race condition between the debuggee and the debugger process. >>> In the original endDebugee, it attempted to do 2 things in parallel. >>> By calling dispose then waitFor, in most cases the debugee would finish >>> and report status before all the dispose operations completed. >>> But some tests would fail if the dispose happened quicker than the >>> debuggee >>> could report final exit status. >>> >>> The tests based on JDIBreakpointTest on? the other hand don't really >>> care about the the final exit status. Once all the events have been >>> seen and handled, the test wants to shutdown the session. >> >> I'm still not seeing how JDIBreakpointTest started hanging/timing-out >> after you switched the order of dispose and waitFor. Does dispose >> affect the debuggee process or the debugger process? > The JDIBreakpointTest would timeout on the endDebugee call to waitFor. > There was no reason for the debugee to exit at that point. > The call to dispose, provided the debugee with it's reason to exit. > Not sure which operation induces the debugee to exit. I think there is a bigger problem underlying this. If the dispose() is needed to trigger the exit() then putting a waitFor before that will hang. But if the dispose() comes first then it can trigger the bug in 8068225. So endDebuggee seems to be only usable in contexts where the debuggee is already ending/exiting now. That really doesn't make sense to me - why would you need to call endDebuggee if its already ending? This fix addresses the current set of failures but I think more examination of this is needed. Thanks, David >> >> Thanks, >> David >> >>> >>> On 2/12/19, 6:59 AM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> On 12/02/2019 8:08 pm, gary.adams at oracle.com wrote: >>>>> The recent change to JDK-8068225 changed the order of operations >>>>> in Debugee.endDebugee() to wait for the debugee to exit before >>>>> disposing of the vm on the debugger side of the connection. >>>>> For the tests based on JDIBreakpointTest the debuggee exit >>>>> status is not used and the tests relied on the >>>>> debugger side dispose operation to end the test. >>>>> >>>>> Since JDIBreakpointTest already includes a call to wait for >>>>> the debugee, if does not need to use endDebuggee() >>>>> to dispose and wait for the debugee to finish. >>>> >>>> I agree that potentially calling waitFor twice seems pointless. But >>>> how did the reordering of vm.dispose() and waitFor() cause all these >>>> tests to hang if they were waiting anyway? Does vm.dispose() have an >>>> effect on destroying the process? >>>> >>>> Also what concerns me is that dispose() is not resilient the way >>>> that endDebuggee is: >>>> >>>> ?public void dispose() { >>>> ??? vm.dispose(); >>>> ?} >>>> >>>> versus >>>> >>>> ??? public int endDebugee() { >>>> ??????? if (vm != null) { >>>> ??????????? try { >>>> ??????????????? vm.dispose(); >>>> ??????????? } catch (VMDisconnectedException ignore) { >>>> ??????????? } >>>> ??????????? vm = null; >>>> ??????? } >>>> >>>> Do we need to be concerned with a null VM or getting >>>> VMDisconnectedException? >>>> >>>> Thanks, >>>> David >>>> >>>>> Testing in progress. The vm/mlvm tests are included in tiers 2, 3 >>>>> and 6. >>>>> >>>>> diff --git >>>>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>> >>>>> --- >>>>> a/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>> >>>>> +++ >>>>> b/test/hotspot/jtreg/vmTestbase/vm/mlvm/share/jdi/JDIBreakpointTest.java >>>>> >>>>> @@ -1,5 +1,5 @@ >>>>> ? /* >>>>> - * Copyright (c) 2011, 2018, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> + * Copyright (c) 2011, 2019, Oracle and/or its affiliates. All >>>>> rights reserved. >>>>> ?? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>>>> ?? * >>>>> ?? * This code is free software; you can redistribute it and/or >>>>> modify it >>>>> @@ -359,7 +359,7 @@ >>>>> ????????? }.go(); >>>>> >>>>> ????????? if (!debuggee.terminated()) >>>>> -??????????? debuggee.endDebugee(); >>>>> +??????????? debuggee.dispose(); >>>>> >>>>> ????????? debuggee.waitFor(); >>>>> ????????? return true; >>>>> >>> > From serguei.spitsyn at oracle.com Tue Feb 12 21:19:31 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Feb 2019 13:19:31 -0800 Subject: RFR(S) 8218751 Do not store original classfiles inside the CDS archive In-Reply-To: References: Message-ID: Hi Ioi, It looks good to me. Thanks, Serguei On 2/11/19 9:23 AM, Ioi Lam wrote: > http://cr.openjdk.java.net/~iklam/jdk13/8218751-dont-store-classfiles-in-cds.v01/ > > https://bugs.openjdk.java.net/browse/JDK-8218751 > > For JVMTI ClassFileLoadHook support, the CDS archive currently stores > the original classfile data of all archived classes. > > However, this consists of over 30% of the archive size. Because all > original classfile data are already available in other files (such as the > JDK lib/modules file, or JAR files in the classpath), we can simply read > from these locations when needed by JVMTI. > > For the default CDS archive (included as part of the JDK distribution), > the size is reduced from about 18.5MB to 12.1MB on Linux/x64. > > Thanks > > - Ioi > From igor.ignatyev at oracle.com Wed Feb 13 00:01:34 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 12 Feb 2019 16:01:34 -0800 Subject: RFR(T) : 8209455 : [error-prone] JdkObsolete in jdk.management.agent Message-ID: <3ACF3466-8D50-49D3-895D-2BFC9D947B89@oracle.com> http://cr.openjdk.java.net/~iignatyev//8209455/webrev.00 > 2 lines changed: 0 ins; 0 del; 2 mod; Hi all, could you please review this trivial cleanup which replaces StringBuffer by StringBuilder in jdk.management.agent module? webrev: http://cr.openjdk.java.net/~iignatyev/8209455/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8209455 Thanks, -- Igor From alexey.menkov at oracle.com Wed Feb 13 00:45:56 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Tue, 12 Feb 2019 16:45:56 -0800 Subject: RFR JDK-8218702: [TESTBUG] com/sun/jdi/RepStep.java does not report debuggee errors In-Reply-To: <1e320201-59aa-eb72-a817-893d23949512@oracle.com> References: <1e320201-59aa-eb72-a817-893d23949512@oracle.com> Message-ID: Hi Chris, Most of JDI tests use helper classes (VMConnection or Debuggee) which redirect debuggee outputs. LaunchingConnector is used only by RepStep, SunBootClassPathEmptyTest and DebugUsingCustomConnector and only RepStep really performs debugging (SingleStepping). --alex On 02/11/2019 18:32, Chris Plummer wrote: > How is this test different from other JDI tests in its handling of > stdout and stderr? Why is it a special case that needs this fix? > > Chris > > On 2/11/19 3:59 PM, Alex Menkov wrote: >> Hi all, >> >> please review the fix for >> https://bugs.openjdk.java.net/browse/JDK-8218702 >> webrev: >> http://cr.openjdk.java.net/~amenkov/RepStep_redirect/webrev/ >> >> The fix adds events logging and debuggee stdout/stderr redirection >> (the test now logs crash in debuggee as described in JDK-8043571) >> >> --alex > > From jianglizhou at google.com Wed Feb 13 01:18:04 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Tue, 12 Feb 2019 17:18:04 -0800 Subject: RFR(S) 8218751 Do not store original classfiles inside the CDS archive In-Reply-To: References: Message-ID: Hi Ioi, I'd like to understand the performance impact with this change. Do you have any performance numbers when JvmtiExport::should_post_class_file_load_hook() is required? This is a performance vs footprint trade-off. For some users, performance is more important than static footprint. Could you also please provide some background/motivation for this change? Thanks, Jiangli On Mon, Feb 11, 2019 at 9:24 AM Ioi Lam wrote: > > http://cr.openjdk.java.net/~iklam/jdk13/8218751-dont-store-classfiles-in-cds.v01/ > https://bugs.openjdk.java.net/browse/JDK-8218751 > > For JVMTI ClassFileLoadHook support, the CDS archive currently stores > the original classfile data of all archived classes. > > However, this consists of over 30% of the archive size. Because all > original classfile data are already available in other files (such as the > JDK lib/modules file, or JAR files in the classpath), we can simply read > from these locations when needed by JVMTI. > > For the default CDS archive (included as part of the JDK distribution), > the size is reduced from about 18.5MB to 12.1MB on Linux/x64. > > Thanks > > - Ioi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Wed Feb 13 04:53:07 2019 From: jini.george at oracle.com (Jini George) Date: Wed, 13 Feb 2019 10:23:07 +0530 Subject: RFR: 8218743: SA: Add support for large bitmaps In-Reply-To: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> References: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> Message-ID: <4d74d065-e744-4d83-a298-d39d7e842b0c@oracle.com> Hi Stefan, Looks good to me. Nits: pls do change the copyright year. Thanks, Jini. On 2/11/2019 6:06 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to add support for large bitmaps in the SA. > > http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218743 > > I've added a minimal interface (at, atPut, clear) that uses longs > instead of ints, and changed MarkBits to use this interface. > > I've implemented a segmented bitmap that, currently, all GCs use when > asked for a bitmap in MarkBits. Later ZGC will provide its own > discontiguous bitmap, implementing the new interface, but that will be > sent out as a separate RFE. > > I've tested this with a temporary patch that lowers the segment size and > implements a jtreg test: > http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 > > I ran through the all the tests in serviceability/sa with both these > patches. > > Thanks, > StefanK From zanglin5 at jd.com Wed Feb 13 05:26:28 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Wed, 13 Feb 2019 05:26:28 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> <7ae12430-7fe3-3492-b9c6-8cc917766992@oracle.com> <888EC94F-DAB9-4114-B81B-0C74936C78EB@amazon.com>, Message-ID: Dear All, I have uploaded new webrev at http://cr.openjdk.java.net/~xiaofeya/8215622/webrev.08/ Here are the changes I made: * fixed the grammar issue. * fixed the help info of jmap -histo * added several unit test in BasicJmapTest.java Would you like to help review it? Thanks. BRs, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Wednesday, February 13, 2019 4:00 To: Hohensee, Paul; Joe Darcy; Daniel Fuchs; ??; David Holmes; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215622: Add dump to file support for jmap histo On 2/12/19 10:36 AM, Hohensee, Paul wrote: > Thanks, Joe and Daniel. Doesn't seem that we need it for this case anymore, but it's good to know how to proceed in the future. :) Agreed. Thanks, Serguei > > Paul > > ?On 2/12/19, 9:07 AM, "Joe Darcy" wrote: > > Yes, if you make yourself the assignee, you can change the state of the > request (and then change the assignee back to the original person). > > HTH, > > -Joe > > On 2/12/2019 7:38 AM, Daniel Fuchs wrote: > > Hi Paul, > > > > On 12/02/2019 16:27, Hohensee, Paul wrote: > >> I don't see a way to change the Status from Closed to anything else. > >> There's no option I can find to do so. > > > > It may be that only the assignee can see this. > > On the closed CSRs assigned to me I can see a "Back to Draft" button > > next to "More". > > > > Hope this helps, > > > > -- daniel > > From serguei.spitsyn at oracle.com Wed Feb 13 06:57:15 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 12 Feb 2019 22:57:15 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> <4c797f80a87748c5bb260ea5715be75e@jd.com> <995e267b-8d21-d6ba-74fb-4ae7b406280d@oracle.com> <4d75a7134165433e8dc1ecacd1f564dd@jd.com> <3ECCB980-909F-473C-A4BF-5D55A4E16AAD@amazon.com> <47DBF2D1-5BA0-42ED-A78B-609FFE89D09A@amazon.com> <1F14E0F9-B5F9-49D0-A44C-04EB1672E7E7@amazon.com> <5C61F5C3.2050605@oracle.com> <7ae12430-7fe3-3492-b9c6-8cc917766992@oracle.com> <888EC94F-DAB9-4114-B81B-0C74936C78EB@amazon.com> Message-ID: An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Feb 13 07:04:38 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 Feb 2019 07:04:38 +0000 Subject: RFR(T) : 8209455 : [error-prone] JdkObsolete in jdk.management.agent In-Reply-To: <3ACF3466-8D50-49D3-895D-2BFC9D947B89@oracle.com> References: <3ACF3466-8D50-49D3-895D-2BFC9D947B89@oracle.com> Message-ID: On 13/02/2019 00:01, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8209455/webrev.00 >> 2 lines changed: 0 ins; 0 del; 2 mod; > > Hi all, > > could you please review this trivial cleanup which replaces StringBuffer by StringBuilder in jdk.management.agent module? > > webrev: http://cr.openjdk.java.net/~iignatyev/8209455/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8209455 > Looks okay but StringJoiner might be better here. -Alan From stefan.karlsson at oracle.com Wed Feb 13 08:42:36 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Feb 2019 09:42:36 +0100 Subject: RFR: 8218743: SA: Add support for large bitmaps In-Reply-To: <4d74d065-e744-4d83-a298-d39d7e842b0c@oracle.com> References: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> <4d74d065-e744-4d83-a298-d39d7e842b0c@oracle.com> Message-ID: <8f12f472-cf66-5fa1-187b-b260ad8ba8eb@oracle.com> Hi Jini, On 2019-02-13 05:53, Jini George wrote: > Hi Stefan, > > Looks good to me. Nits: pls do change the copyright year. Thanks for reviewing. I'll update the copyright years. Thanks, StefanK > > Thanks, > Jini. > > On 2/11/2019 6:06 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to add support for large bitmaps in the SA. >> >> http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8218743 >> >> I've added a minimal interface (at, atPut, clear) that uses longs >> instead of ints, and changed MarkBits to use this interface. >> >> I've implemented a segmented bitmap that, currently, all GCs use when >> asked for a bitmap in MarkBits. Later ZGC will provide its own >> discontiguous bitmap, implementing the new interface, but that will be >> sent out as a separate RFE. >> >> I've tested this with a temporary patch that lowers the segment size >> and implements a jtreg test: >> http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 >> >> I ran through the all the tests in serviceability/sa with both these >> patches. >> >> Thanks, >> StefanK From ioi.lam at oracle.com Wed Feb 13 13:39:55 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 13 Feb 2019 05:39:55 -0800 Subject: RFR(S) 8218751 Do not store original classfiles inside the CDS archive In-Reply-To: <5C631E7F.8020907@oracle.com> References: <5C631E7F.8020907@oracle.com> Message-ID: <9a1da139-984a-dd11-d4ec-2d089e2cbd20@oracle.com> Hi Calvin Thanks for the review. On 2/12/19 11:29 AM, Calvin Cheung wrote: > Hi Ioi, > > The following call is probably slower than before because it involves > reading from a jar file. > cfs = FileMapInfo::open_stream_for_jvmti(ik, CHECK_NULL); > It is probably ok since the above is called under the following > condition: > if (JvmtiExport::should_post_class_file_load_hook()) > I think the slow down is probably going to be OK. If not, some users will tell us :-) I remember the old days when CDS will be completely disabled when CFLH is used, but no one was complaining at that time. > Minor comments in the following 2 files: > > filemap.cpp > 1494?? assert(path_index >= 0, "should be called for shared built-in > classes only"); > > Should the above be also checking (path_index < > ClassLoaderExt::app_class_paths_start_index())? > I already have this check ? assert(path_index < (int)_shared_path_table_size, "sanity"); It's possible for path_index to be >= ClassLoaderExt::app_class_paths_start_index(). For example, if the class is being loaded from the app classpath (e.g., hello.jar when loading an archived HelloWorld class). > SpaceUtilizationCheck.java > 106?????????? throw new RuntimeException("Must have 5 consecutive, > fully utilized regions"); > > 5 should be 4 > Fixed. Thanks - Ioi > thanks, > Calvin > > On 2/11/19, 9:23 AM, Ioi Lam wrote: >> http://cr.openjdk.java.net/~iklam/jdk13/8218751-dont-store-classfiles-in-cds.v01/ >> >> https://bugs.openjdk.java.net/browse/JDK-8218751 >> >> For JVMTI ClassFileLoadHook support, the CDS archive currently stores >> the original classfile data of all archived classes. >> >> However, this consists of over 30% of the archive size. Because all >> original classfile data are already available in other files (such as >> the >> JDK lib/modules file, or JAR files in the classpath), we can simply read >> from these locations when needed by JVMTI. >> >> For the default CDS archive (included as part of the JDK distribution), >> the size is reduced from about 18.5MB to 12.1MB on Linux/x64. >> >> Thanks >> >> - Ioi >> From zgu at redhat.com Wed Feb 13 14:12:59 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Wed, 13 Feb 2019 09:12:59 -0500 Subject: RFR(S) 8212127: Cleanup TLAB fast refill statistics, perf counters and etc. In-Reply-To: <1549548205.31327.224.camel@redhat.com> References: <1549045645.31327.150.camel@redhat.com> <6ae5c38a-492c-114c-55e2-79165fdd2c44@oracle.com> <1549114691.31327.157.camel@redhat.com> <1549199610.31327.166.camel@redhat.com> <5deb0d4e-d2e5-deab-141f-6fd80a0b163c@oracle.com> <1549230180.31327.172.camel@redhat.com> <9c35c669-eb93-7c66-b9d0-83e8bd2e5670@redhat.com> <1549463651.31327.188.camel@redhat.com> <6c5d6d0e-c74a-bf2d-15aa-b046474c0830@redhat.com> <2d0f9402-797e-79dd-044f-50e422d837d4@oracle.com> <1549548205.31327.224.camel@redhat.com> Message-ID: <1550067179.20944.51.camel@redhat.com> Thanks, Per. > > Thanks for cleaning this up. GC changes look good. Just one minor > > thing, > > please align the assignment here: > > > > @@ -147,8 +145,7 @@ > > > > void ThreadLocalAllocBuffer::reset_statistics() { > > _number_of_refills = 0; > > - _fast_refill_waste = 0; > > - _slow_refill_waste = 0; > > + _refill_waste = 0; > > _gc_waste = 0; > > _slow_allocations = 0; > > _allocated_size = 0; > > > > > > Updated: http://cr.openjdk.java.net/~zgu/JDK-8212127/webrev.01/ > > -Zhengyu > > > > > I agree that Serviceability should ack the jstat change. Ping, anyone from Serviceability! Thanks, -Zhengyu > > > > cheers, > > Per From stefan.karlsson at oracle.com Wed Feb 13 14:52:05 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Feb 2019 15:52:05 +0100 Subject: RFR/C: 8218922: SA: Enable best-effort implementation of live regions iteration for ZGC Message-ID: Hi all, Please review / comment on this patch to enable a best-effort live heap region iteration implementation in ZGC. http://cr.openjdk.java.net/~stefank/8218922/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8218922 The SA has functionally that relies on live heap region information from the GCs. This is problematic when dead objects are left in the heap, and their classes have been unloaded. Because of this ZGC has so far not implemented this feature. However, we could provide a best-effort implementation that most likely will work if classes are not unloaded (or class unloading is turned off), and otherwise might fail to fully parse and report all live heap regions. For active, non-relocating pages the patch simply returns [start, top) and for pages being actively relocated, it reports regions containing the non-forwarded objects, the other objects are either dead or could be found in one of the to-regions. With this patch I'm able to get heap histograms with ZGC. Maybe this is enough to enable a bit more SA debugging capabilities when running with ZGC? What do you think, should we bring in this change? To be able to implement this more cleanly I've restructured the live region collection, and pushed GC specific code into the specific GCs. There are some extra usage of generics to make the code a bit easier to read and develop. Thanks, StefanK From gary.adams at oracle.com Wed Feb 13 16:53:50 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 13 Feb 2019 11:53:50 -0500 Subject: RFR: JDK-8066993: nsk.jdi.EventRequest.setEnabled.setenabled003 fails: event IS NOT a breakpoint Message-ID: <5C644B9E.30002@oracle.com> The setenabled003 test has been on the ProblemList since it was first moved to the open repos. After 1000 test runs on {solaris, macosx, windows, linux} for the test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled tests, the problem does not currently reproduce. My recommendation is that we remove it from the ProblemList at this time. 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 @@ -161,10 +161,8 @@ vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java 8072701 generic-all vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java 7034630 generic-all vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java 8013728 generic-all -vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all From stefan.karlsson at oracle.com Wed Feb 13 16:57:56 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 13 Feb 2019 17:57:56 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> <3d6e9642-47e0-8a2a-7a08-0d195db8a783@oracle.com> <40d90cf8-0b36-34c0-7122-23f829037c22@oracle.com> Message-ID: <189e8356-b7e5-dbfe-ede7-a30fa6495ca7@oracle.com> On 2019-02-13 17:12, coleen.phillimore at oracle.com wrote: > > > On 2/13/19 10:40 AM, Stefan Karlsson wrote: >> On 2019-02-13 14:40, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 2/11/19 3:39 AM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to fix the resolving of oops inside the >>>> (VM) OopHandles. >>>> >>>> https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8218734 >>>> >>>> Before this patch the OopHandle::_obj was assumed to be located at >>>> offset 0, and the SA resolved OopHandle (Klass::_java_mirror and >>>> ClassLoaderData::_class_loader) without the required load barrier >>>> for ZGC. I've added a new class VMOopHandle (The SA already has a >>>> OopHandle), which handles the resolving (load or load + barrier). >>> >>> This looks good but unfortunate that the SA has a different >>> OopHandle. Maybe it would be more accurate to call it >>> AccessOopHandle to imply that it has to use barriers? >> >> Maybe. I'm not sure I like the name AccessOopHandle any better, but >> if you feel strongly about this I'll change it. > I don't feel strongly about it. >> >>>> >>>> The OopHandle type is grouped under the Oops section in >>>> vmStructs.cpp. It's not an oop, so I added a newline to separate it >>>> out from the rest. Any suggestion of a better location in that file? >>>> >>> >>> Seems ok to me.? The change looks fine.? Thank you for fixing this. >> >> Thanks for reviewing. I'll change getAddressField to getField as >> suggested by Jini in another thread. >> > > Good, I didn't see any replies and was wondering if it should be sent > to another mailing list. I think you dropped serviceability-dev (TO:ed). StefanK > > Coleen > >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Coleen >>>> Tested with the jtreg tests in serviceability/sa + patches to make >>>> ZGC usable with the SA's hprof dumping. >>>> >>>> Thanks, >>>> StefanK >>> > From chris.plummer at oracle.com Wed Feb 13 19:16:52 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Feb 2019 11:16:52 -0800 Subject: RFR JDK-8218702: [TESTBUG] com/sun/jdi/RepStep.java does not report debuggee errors In-Reply-To: References: <1e320201-59aa-eb72-a817-893d23949512@oracle.com> Message-ID: Ok On 2/12/19 4:45 PM, Alex Menkov wrote: > Hi Chris, > > Most of JDI tests use helper classes (VMConnection or Debuggee) which > redirect debuggee outputs. > LaunchingConnector is used only by RepStep, SunBootClassPathEmptyTest > and DebugUsingCustomConnector and only RepStep really performs > debugging (SingleStepping). > > --alex > > On 02/11/2019 18:32, Chris Plummer wrote: >> How is this test different from other JDI tests in its handling of >> stdout and stderr? Why is it a special case that needs this fix? >> >> Chris >> >> On 2/11/19 3:59 PM, Alex Menkov wrote: >>> Hi all, >>> >>> please review the fix for >>> https://bugs.openjdk.java.net/browse/JDK-8218702 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/RepStep_redirect/webrev/ >>> >>> The fix adds events logging and debuggee stdout/stderr redirection >>> (the test now logs crash in debuggee as described in JDK-8043571) >>> >>> --alex >> >> From igor.ignatyev at oracle.com Wed Feb 13 19:21:55 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 13 Feb 2019 11:21:55 -0800 Subject: RFR(T) : 8209455 : [error-prone] JdkObsolete in jdk.management.agent In-Reply-To: References: <3ACF3466-8D50-49D3-895D-2BFC9D947B89@oracle.com> Message-ID: Hi Alan, actually, String::join is enough in this case, uploaded webrev.01 -- http://cr.openjdk.java.net/~iignatyev//8209455/webrev.01 Thanks, -- Igor > On Feb 12, 2019, at 11:04 PM, Alan Bateman wrote: > > On 13/02/2019 00:01, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8209455/webrev.00 >>> 2 lines changed: 0 ins; 0 del; 2 mod; >> >> Hi all, >> >> could you please review this trivial cleanup which replaces StringBuffer by StringBuilder in jdk.management.agent module? >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8209455/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209455 >> > Looks okay but StringJoiner might be better here. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Wed Feb 13 19:37:52 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Feb 2019 11:37:52 -0800 Subject: RFR: JDK-8066993: nsk.jdi.EventRequest.setEnabled.setenabled003 fails: event IS NOT a breakpoint In-Reply-To: <5C644B9E.30002@oracle.com> References: <5C644B9E.30002@oracle.com> Message-ID: <77e7fa74-5a97-869d-0799-d9d6c73bc555@oracle.com> Hi Gary, Looks good. What are your plans for bug management? I think the CR should actually be closed as CNR and removal from the problemlist be done as a subtask. Also, there are a lot of other failures reported with other tests under this bug. Kind of became a dumping ground, but none of them resulted in tests being quarantined. All of the reported failures seem to be with 8u60, and they probably still happen there. I'm not sure of the right procedure for closing out the bug in that case since no fix is being provided, so no backport can be done. Also, the affects versions includes 9 and 10. I think at some point Jerry reproduced something on 10, but didn't give any details. I'm not sure how to address that either. Chris On 2/13/19 8:53 AM, Gary Adams wrote: > The setenabled003 test has been on the ProblemList since it was first > moved to the open repos. After 1000 test runs on {solaris, macosx, > windows, linux} > for the test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled > tests, > the problem does not currently reproduce. > > My recommendation is that we remove it from the ProblemList at this time. > > > 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 > @@ -161,10 +161,8 @@ > ?vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java > 8072701 generic-all > ?vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java > 7034630 generic-all > ?vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java > 8013728 generic-all > -vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java > 8066993 generic-all > ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java > 8065773 generic-all > ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java > 8065773 generic-all From gary.adams at oracle.com Wed Feb 13 20:32:38 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Wed, 13 Feb 2019 15:32:38 -0500 Subject: RFR: JDK-8066993: nsk.jdi.EventRequest.setEnabled.setenabled003 fails: event IS NOT a breakpoint In-Reply-To: <77e7fa74-5a97-869d-0799-d9d6c73bc555@oracle.com> References: <5C644B9E.30002@oracle.com> <77e7fa74-5a97-869d-0799-d9d6c73bc555@oracle.com> Message-ID: <197abdbb-d404-5566-7e07-7be65d35dfdf@oracle.com> Right now I'm proposing we use the bug number that matches the entry in the ProblemList to remove the test from the ProblemList. The other matching rules that were added for connection closed and the other bugs with connection closed had no valid reason for attaching to a bug with a specific error in a specific test. Since the other tests were never added to the ProblemList, they obviously have not failed in a long time. If those errors show up, new bugs should be filed. This changeset would end up in jdk13. Since this change is specific to the ProblemList, backports to the older releases would have to be retested in those builds, if neeeded. Presumably some other fix has made it so this test no longer is failing. On 2/13/19 2:37 PM, Chris Plummer wrote: > Hi Gary, > > Looks good. What are your plans for bug management? I think the CR > should actually be closed as CNR and removal from the problemlist be > done as a subtask. > > Also, there are a lot of other failures reported with other tests > under this bug. Kind of became a dumping ground, but none of them > resulted in tests being quarantined. All of the reported failures seem > to be with 8u60, and they probably still happen there. I'm not sure of > the right procedure for closing out the bug in that case since no fix > is being provided, so no backport can be done. Also, the affects > versions includes 9 and 10. I think at some point Jerry reproduced > something on 10, but didn't give any details. I'm not sure how to > address that either. > > Chris > > On 2/13/19 8:53 AM, Gary Adams wrote: >> The setenabled003 test has been on the ProblemList since it was first >> moved to the open repos. After 1000 test runs on {solaris, macosx, >> windows, linux} >> for the test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled >> tests, >> the problem does not currently reproduce. >> >> My recommendation is that we remove it from the ProblemList at this >> time. >> >> >> 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 >> @@ -161,10 +161,8 @@ >> ?vmTestbase/nsk/jdi/ThreadReference/resume/resume001/TestDescription.java >> 8072701 generic-all >> ?vmTestbase/nsk/jdi/ThreadReference/stop/stop001/TestDescription.java >> 7034630 generic-all >> ?vmTestbase/nsk/jdi/BScenarios/hotswap/tc10x001/TestDescription.java >> 8013728 generic-all >> -vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java >> 8066993 generic-all >> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java >> 8065773 generic-all >> ?vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java >> 8065773 generic-all > > > From jcbeyler at google.com Wed Feb 13 22:42:13 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Feb 2019 14:42:13 -0800 Subject: RFR(T) : 8209455 : [error-prone] JdkObsolete in jdk.management.agent In-Reply-To: References: <3ACF3466-8D50-49D3-895D-2BFC9D947B89@oracle.com> Message-ID: Hi Igor, Looks good to me :) Jc On Wed, Feb 13, 2019 at 11:24 AM Igor Ignatyev wrote: > Hi Alan, > > actually, String::join is enough in this case, uploaded webrev.01 -- > http://cr.openjdk.java.net/~iignatyev//8209455/webrev.01 > > Thanks, > -- Igor > > On Feb 12, 2019, at 11:04 PM, Alan Bateman > wrote: > > On 13/02/2019 00:01, Igor Ignatyev wrote: > > http://cr.openjdk.java.net/~iignatyev//8209455/webrev.00 > > 2 lines changed: 0 ins; 0 del; 2 mod; > > > Hi all, > > could you please review this trivial cleanup which replaces StringBuffer > by StringBuilder in jdk.management.agent module? > > webrev: http://cr.openjdk.java.net/~iignatyev/8209455/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8209455 > > Looks okay but StringJoiner might be better here. > > -Alan > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Feb 13 23:00:16 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Feb 2019 15:00:16 -0800 Subject: RFR: JDK-8214582: BasicJDWPConnectionTest.java: RuntimeException: Could not detect port from '' In-Reply-To: References: <8d76b446-0313-d37e-cb93-db4f9a4d73b6@oracle.com> Message-ID: Hi Alex, Looks good to me too :) Jc On Mon, Feb 11, 2019 at 4:18 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Alex, > > It looks Okay to me. > > Thanks, > Serguei > > > On 2/11/19 15:20, Alex Menkov wrote: > > Hi all, > > > > Please review the fix for > > https://bugs.openjdk.java.net/browse/JDK-8214582 > > webrev: > > http://cr.openjdk.java.net/~amenkov/BasicJDWPConnEmptyPort/webrev/ > > > > The change fixes race condition when debuggee (LingeredApp) touches > > lock file, but the test haven't handled "Listening for transport ... > > at address ..." output. > > Now the test waits up to 10 seconds (adjusted to TIMEOUT_FACTOR) for > > the required output. > > > > --alex > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nick.Gasson at arm.com Thu Feb 14 01:16:51 2019 From: Nick.Gasson at arm.com (Nick Gasson (Arm Technology China)) Date: Thu, 14 Feb 2019 01:16:51 +0000 Subject: [aarch64-port-dev ] RFR: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <976b890a-79e6-e8d1-e516-97e15bdb6658@redhat.com> References: <48554800-8c44-1756-e372-59e5f1babe5f@redhat.com> <100cc6ef-cab1-4ee1-3ab8-8186f9d898e8@redhat.com> <1fd9aa7f-c5f5-80ef-dd47-73756a318d31@redhat.com> <068399ec-fbb8-b881-7ea2-1b684a42652a@redhat.com> <976b890a-79e6-e8d1-e516-97e15bdb6658@redhat.com> Message-ID: On 12/02/2019 23:32, Andrew Haley wrote: > What's the status of this? Are you still looking at it? > Apologies, I was on holiday until today so haven't done anything on it. I'll send an updated patch shortly... Nick From chris.plummer at oracle.com Thu Feb 14 02:43:16 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Feb 2019 18:43:16 -0800 Subject: RFR(S): 8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option Message-ID: Hi, Please review the following: http://cr.openjdk.java.net/~cjplummer/8218941/webrev https://bugs.openjdk.java.net/browse/JDK-8218941 Tested by running the following on all supported platforms: open/test/hotspot/jtreg/vmTestbase/nsk/jdb open/test/jdk/com/sun/jdi thanks, Chris From chris.plummer at oracle.com Thu Feb 14 03:37:38 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Feb 2019 19:37:38 -0800 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex Message-ID: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> Hi, Please review the following: http://cr.openjdk.java.net/~cjplummer/8218947/webrev https://bugs.openjdk.java.net/browse/JDK-8218947 Tested by running the following on all supported platforms: open/test/hotspot/jtreg/vmTestbase/nsk/jdb open/test/jdk/com/sun/jdi thanks, Chris From jcbeyler at google.com Thu Feb 14 03:41:30 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 13 Feb 2019 19:41:30 -0800 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> Message-ID: Hi Chris, Looks good to me :) Jc On Wed, Feb 13, 2019 at 7:38 PM Chris Plummer wrote: > Hi, > > Please review the following: > > http://cr.openjdk.java.net/~cjplummer/8218947/webrev > https://bugs.openjdk.java.net/browse/JDK-8218947 > > Tested by running the following on all supported platforms: > > open/test/hotspot/jtreg/vmTestbase/nsk/jdb > open/test/jdk/com/sun/jdi > > thanks, > > Chris > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Feb 14 04:32:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Feb 2019 14:32:18 +1000 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> Message-ID: <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> Hi Chris, On 14/02/2019 1:37 pm, Chris Plummer wrote: > Hi, > > Please review the following: > > http://cr.openjdk.java.net/~cjplummer/8218947/webrev > https://bugs.openjdk.java.net/browse/JDK-8218947 Are there times you may want to correlate those thread ids with ones in other logs/tools that are in hex? That aside: java.lang.Long.toString you don't need the java.lang part (it's always implicitly imported). Thanks, David ----- > Tested by running the following on all supported platforms: > > open/test/hotspot/jtreg/vmTestbase/nsk/jdb > open/test/jdk/com/sun/jdi > > thanks, > > Chris From david.holmes at oracle.com Thu Feb 14 04:36:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Feb 2019 14:36:29 +1000 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> Message-ID: <16a62d63-7559-7be5-ac19-8f606549e3b4@oracle.com> PS. return MessageOutput.format("object description and hex id", Need to change the message too! David On 14/02/2019 2:32 pm, David Holmes wrote: > Hi Chris, > > On 14/02/2019 1:37 pm, Chris Plummer wrote: >> Hi, >> >> Please review the following: >> >> http://cr.openjdk.java.net/~cjplummer/8218947/webrev >> https://bugs.openjdk.java.net/browse/JDK-8218947 > > Are there times you may want to correlate those thread ids with ones in > other logs/tools that are in hex? > > That aside: > > java.lang.Long.toString > > you don't need the java.lang part (it's always implicitly imported). > > Thanks, > David > ----- > >> Tested by running the following on all supported platforms: >> >> open/test/hotspot/jtreg/vmTestbase/nsk/jdb >> open/test/jdk/com/sun/jdi >> >> thanks, >> >> Chris From david.holmes at oracle.com Thu Feb 14 04:53:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Feb 2019 14:53:06 +1000 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: <16a62d63-7559-7be5-ac19-8f606549e3b4@oracle.com> References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> <16a62d63-7559-7be5-ac19-8f606549e3b4@oracle.com> Message-ID: pps. You'll also need to update the man page as it has an example showing the hex: threads List the threads that are currently running. For each thread, its name and current status are printed and an index that can be used in other commands. In this example, the thread index is 4, the thread is an instance of java.lang.Thread, the thread name is main, and it is currently running. 4. (java.lang.Thread)0x1 main running Is this change really worth bothering with? What's the status of jdb (I was surprised to seem this is all an example!) ? Does this need a CSR request? Cheers, David On 14/02/2019 2:36 pm, David Holmes wrote: > PS. > > ?return MessageOutput.format("object description and hex id", > > Need to change the message too! > > David > > On 14/02/2019 2:32 pm, David Holmes wrote: >> Hi Chris, >> >> On 14/02/2019 1:37 pm, Chris Plummer wrote: >>> Hi, >>> >>> Please review the following: >>> >>> http://cr.openjdk.java.net/~cjplummer/8218947/webrev >>> https://bugs.openjdk.java.net/browse/JDK-8218947 >> >> Are there times you may want to correlate those thread ids with ones >> in other logs/tools that are in hex? >> >> That aside: >> >> java.lang.Long.toString >> >> you don't need the java.lang part (it's always implicitly imported). >> >> Thanks, >> David >> ----- >> >>> Tested by running the following on all supported platforms: >>> >>> open/test/hotspot/jtreg/vmTestbase/nsk/jdb >>> open/test/jdk/com/sun/jdi >>> >>> thanks, >>> >>> Chris From david.holmes at oracle.com Thu Feb 14 05:00:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Feb 2019 15:00:09 +1000 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> <16a62d63-7559-7be5-ac19-8f606549e3b4@oracle.com> Message-ID: On 14/02/2019 2:53 pm, David Holmes wrote: > oops! Okay on-list then. No big deal :) David > pps. You'll also need to update the man page as it has an example > showing the hex: > > ???? threads > ????????????? List the threads that are currently running. For each > thread, its name and current status are printed and > ????????????? an index that can be used in other commands. In this > example, the thread index is 4, the thread is an > ????????????? instance of java.lang.Thread, the thread name is main, > and it is currently running. > > ????????????? 4. (java.lang.Thread)0x1 main????? running > > Is this change really worth bothering with? What's the status of jdb (I > was surprised to seem this is all an example!) ? Does this need a CSR > request? > > Cheers, > David > On 14/02/2019 2:36 pm, David Holmes wrote: >> PS. >> >> ??return MessageOutput.format("object description and hex id", >> >> Need to change the message too! >> >> David >> >> On 14/02/2019 2:32 pm, David Holmes wrote: >>> Hi Chris, >>> >>> On 14/02/2019 1:37 pm, Chris Plummer wrote: >>>> Hi, >>>> >>>> Please review the following: >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8218947/webrev >>>> https://bugs.openjdk.java.net/browse/JDK-8218947 >>> >>> Are there times you may want to correlate those thread ids with ones >>> in other logs/tools that are in hex? >>> >>> That aside: >>> >>> java.lang.Long.toString >>> >>> you don't need the java.lang part (it's always implicitly imported). >>> >>> Thanks, >>> David >>> ----- >>> >>>> Tested by running the following on all supported platforms: >>>> >>>> open/test/hotspot/jtreg/vmTestbase/nsk/jdb >>>> open/test/jdk/com/sun/jdi >>>> >>>> thanks, >>>> >>>> Chris From serguei.spitsyn at oracle.com Thu Feb 14 06:12:02 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Feb 2019 22:12:02 -0800 Subject: RFR(S): 8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option In-Reply-To: References: Message-ID: <6ca44d75-ee69-fb19-8ca5-553255f10926@oracle.com> Hi Chris, It looks good to me. Thanks, Serguei On 2/13/19 18:43, Chris Plummer wrote: > Hi, > > Please review the following: > > http://cr.openjdk.java.net/~cjplummer/8218941/webrev > https://bugs.openjdk.java.net/browse/JDK-8218941 > > Tested by running the following on all supported platforms: > > open/test/hotspot/jtreg/vmTestbase/nsk/jdb > open/test/jdk/com/sun/jdi > > thanks, > > Chris From chris.plummer at oracle.com Thu Feb 14 06:41:39 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Feb 2019 22:41:39 -0800 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> Message-ID: <0704ec07-7112-5c14-8dee-435db8f549b4@oracle.com> On 2/13/19 8:32 PM, David Holmes wrote: > Hi Chris, > > On 14/02/2019 1:37 pm, Chris Plummer wrote: >> Hi, >> >> Please review the following: >> >> http://cr.openjdk.java.net/~cjplummer/8218947/webrev >> https://bugs.openjdk.java.net/browse/JDK-8218947 > > Are there times you may want to correlate those thread ids with ones > in other logs/tools that are in hex? Not that I know of. It hasn't turned up in tests. > > That aside: > > java.lang.Long.toString > > you don't need the java.lang part (it's always implicitly imported). > Ok. I'll change that. thanks, Chris > Thanks, > David > ----- > >> Tested by running the following on all supported platforms: >> >> open/test/hotspot/jtreg/vmTestbase/nsk/jdb >> open/test/jdk/com/sun/jdi >> >> thanks, >> >> Chris From chris.plummer at oracle.com Thu Feb 14 06:41:56 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Feb 2019 22:41:56 -0800 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: <16a62d63-7559-7be5-ac19-8f606549e3b4@oracle.com> References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> <16a62d63-7559-7be5-ac19-8f606549e3b4@oracle.com> Message-ID: Ok. I'll fix. thanks, Chris On 2/13/19 8:36 PM, David Holmes wrote: > PS. > > ?return MessageOutput.format("object description and hex id", > > Need to change the message too! > > David > > On 14/02/2019 2:32 pm, David Holmes wrote: >> Hi Chris, >> >> On 14/02/2019 1:37 pm, Chris Plummer wrote: >>> Hi, >>> >>> Please review the following: >>> >>> http://cr.openjdk.java.net/~cjplummer/8218947/webrev >>> https://bugs.openjdk.java.net/browse/JDK-8218947 >> >> Are there times you may want to correlate those thread ids with ones >> in other logs/tools that are in hex? >> >> That aside: >> >> java.lang.Long.toString >> >> you don't need the java.lang part (it's always implicitly imported). >> >> Thanks, >> David >> ----- >> >>> Tested by running the following on all supported platforms: >>> >>> open/test/hotspot/jtreg/vmTestbase/nsk/jdb >>> open/test/jdk/com/sun/jdi >>> >>> thanks, >>> >>> Chris From chris.plummer at oracle.com Thu Feb 14 06:54:49 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 13 Feb 2019 22:54:49 -0800 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> <16a62d63-7559-7be5-ac19-8f606549e3b4@oracle.com> Message-ID: <6e8084a1-8457-1647-127b-ba065231d722@oracle.com> Hi David, I can update the man page. Can you point me to where it is in the source? I haven't been able to find it. It seems to be out of date in other ways also. This is what the output looks like (with my fix). main[1] threads Group system: ? (java.lang.ref.Reference$ReferenceHandler)908 Reference Handler running ? (java.lang.ref.Finalizer$FinalizerThread)909? Finalizer cond. waiting ? (java.lang.Thread)910???????????????????????? Signal Dispatcher running Group main: ? (java.lang.Thread)1?????????????????????????? main running (at breakpoint) Group InnocuousThreadGroup: ? (jdk.internal.misc.InnocuousThread)911??????? Common-Cleaner cond. waiting Note there is no index printed as the docs suggest. Also, the docs don't even mention having the threadID printed. I found this change very useful while using jdb to debug the JDWP debug agent. If I don't push it, it will likely just stay as an uncommitted change in my local repo indefinitely since I continue to find use for it. As for the status of jdb, it is supported and we do actively fix it. It's greatest use is probably in testing JDI, since a large number of JDI tests do so using jdb. Also, I've been using it a lot lately to test loom debugging support I've been adding to the JDWP debug agent. I don't know about needing a CSR request. The rules for needing one elude me. I consider you the expert in that area. :) thanks, Chris On 2/13/19 8:53 PM, David Holmes wrote: > > > pps. You'll also need to update the man page as it has an example > showing the hex: > > ???? threads > ????????????? List the threads that are currently running. For each > thread, its name and current status are printed and > ????????????? an index that can be used in other commands. In this > example, the thread index is 4, the thread is an > ????????????? instance of java.lang.Thread, the thread name is main, > and it is currently running. > > ????????????? 4. (java.lang.Thread)0x1 main????? running > > Is this change really worth bothering with? What's the status of jdb > (I was surprised to seem this is all an example!) ? Does this need a > CSR request? > > Cheers, > David > On 14/02/2019 2:36 pm, David Holmes wrote: >> PS. >> >> ??return MessageOutput.format("object description and hex id", >> >> Need to change the message too! >> >> David >> >> On 14/02/2019 2:32 pm, David Holmes wrote: >>> Hi Chris, >>> >>> On 14/02/2019 1:37 pm, Chris Plummer wrote: >>>> Hi, >>>> >>>> Please review the following: >>>> >>>> http://cr.openjdk.java.net/~cjplummer/8218947/webrev >>>> https://bugs.openjdk.java.net/browse/JDK-8218947 >>> >>> Are there times you may want to correlate those thread ids with ones >>> in other logs/tools that are in hex? >>> >>> That aside: >>> >>> java.lang.Long.toString >>> >>> you don't need the java.lang part (it's always implicitly imported). >>> >>> Thanks, >>> David >>> ----- >>> >>>> Tested by running the following on all supported platforms: >>>> >>>> open/test/hotspot/jtreg/vmTestbase/nsk/jdb >>>> open/test/jdk/com/sun/jdi >>>> >>>> thanks, >>>> >>>> Chris From serguei.spitsyn at oracle.com Thu Feb 14 07:07:42 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 13 Feb 2019 23:07:42 -0800 Subject: RFR(S): 8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option In-Reply-To: References: Message-ID: Hi Chris, It looks good to me. Thanks, Serguei On 2/13/19 18:43, Chris Plummer wrote: > Hi, > > Please review the following: > > http://cr.openjdk.java.net/~cjplummer/8218941/webrev > https://bugs.openjdk.java.net/browse/JDK-8218941 > > Tested by running the following on all supported platforms: > > open/test/hotspot/jtreg/vmTestbase/nsk/jdb > open/test/jdk/com/sun/jdi > > thanks, > > Chris From david.holmes at oracle.com Thu Feb 14 08:03:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Feb 2019 18:03:57 +1000 Subject: RFR(XS): 8218947: jdb threads command should print threadID in decimal, not hex In-Reply-To: <6e8084a1-8457-1647-127b-ba065231d722@oracle.com> References: <4f4dab9b-665e-405d-43c7-0467f2ade3fe@oracle.com> <99694a99-73aa-10bb-53d6-83b469810afa@oracle.com> <16a62d63-7559-7be5-ac19-8f606549e3b4@oracle.com> <6e8084a1-8457-1647-127b-ba065231d722@oracle.com> Message-ID: Hi Chris, On 14/02/2019 4:54 pm, Chris Plummer wrote: > Hi David, > > I can update the man page. Can you point me to where it is in the > source? I haven't been able to find it. It seems to be out of date in > other ways also. Will send pointer separately as it's not part of OpenJDK. > This is what the output looks like (with my fix). > > main[1] threads > Group system: > ? (java.lang.ref.Reference$ReferenceHandler)908 Reference Handler running > ? (java.lang.ref.Finalizer$FinalizerThread)909? Finalizer cond. waiting > ? (java.lang.Thread)910???????????????????????? Signal Dispatcher running > Group main: > ? (java.lang.Thread)1?????????????????????????? main running (at > breakpoint) > Group InnocuousThreadGroup: > ? (jdk.internal.misc.InnocuousThread)911??????? Common-Cleaner cond. > waiting > > Note there is no index printed as the docs suggest. Also, the docs don't > even mention having the threadID printed. Okay probably need a separate bug to update the man page then. > I found this change very useful while using jdb to debug the JDWP debug > agent. If I don't push it, it will likely just stay as an uncommitted > change in my local repo indefinitely since I continue to find use for it. > > As for the status of jdb, it is supported and we do actively fix it. > It's greatest use is probably in testing JDI, since a large number of > JDI tests do so using jdb. Also, I've been using it a lot lately to test > loom debugging support I've been adding to the JDWP debug agent. > > I don't know about needing a CSR request. The rules for needing one > elude me. I consider you the expert in that area. :) Well this isn't changing a programming interface just the UI, so unless people use it with some kind of screen scraping I can't see there being a compatibility issue. Cheers, David ----- > thanks, > > Chris > > On 2/13/19 8:53 PM, David Holmes wrote: >> >> >> pps. You'll also need to update the man page as it has an example >> showing the hex: >> >> ???? threads >> ????????????? List the threads that are currently running. For each >> thread, its name and current status are printed and >> ????????????? an index that can be used in other commands. In this >> example, the thread index is 4, the thread is an >> ????????????? instance of java.lang.Thread, the thread name is main, >> and it is currently running. >> >> ????????????? 4. (java.lang.Thread)0x1 main????? running >> >> Is this change really worth bothering with? What's the status of jdb >> (I was surprised to seem this is all an example!) ? Does this need a >> CSR request? >> >> Cheers, >> David >> On 14/02/2019 2:36 pm, David Holmes wrote: >>> PS. >>> >>> ??return MessageOutput.format("object description and hex id", >>> >>> Need to change the message too! >>> >>> David >>> >>> On 14/02/2019 2:32 pm, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 14/02/2019 1:37 pm, Chris Plummer wrote: >>>>> Hi, >>>>> >>>>> Please review the following: >>>>> >>>>> http://cr.openjdk.java.net/~cjplummer/8218947/webrev >>>>> https://bugs.openjdk.java.net/browse/JDK-8218947 >>>> >>>> Are there times you may want to correlate those thread ids with ones >>>> in other logs/tools that are in hex? >>>> >>>> That aside: >>>> >>>> java.lang.Long.toString >>>> >>>> you don't need the java.lang part (it's always implicitly imported). >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Tested by running the following on all supported platforms: >>>>> >>>>> open/test/hotspot/jtreg/vmTestbase/nsk/jdb >>>>> open/test/jdk/com/sun/jdi >>>>> >>>>> thanks, >>>>> >>>>> Chris > > > From erik.osterlund at oracle.com Thu Feb 14 08:19:58 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 09:19:58 +0100 Subject: RFR: 8218731: SA: Use concrete class the as return type of VMObjectFactory.newObject In-Reply-To: <5e050e49-2f05-bed8-a7da-96fd2cbcf120@oracle.com> References: <5e050e49-2f05-bed8-a7da-96fd2cbcf120@oracle.com> Message-ID: <4e2039bf-259c-c3f2-5315-0959d439472b@oracle.com> Hi Stefan, This looks good and trivial. Thanks, /Erik On 2019-02-11 08:47, Stefan Karlsson wrote: > Hi all, > > I propose this simple change to use the concrete class as the return > type of VMObjectFactory.newObject. > > https://cr.openjdk.java.net/~stefank/8218731/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8218731 > > This allows us to specify the class only once when calling newObject. > For example, now we can use: > return VMObjectFactory.newObject(ZPhysicalMemoryManager.class, > physicalAddr); > > Instead of having to write: > ?????? return > (ZPhysicalMemoryManager)VMObjectFactory.newObject(ZPhysicalMemoryManager.class, > physicalAddr); > > Thanks, > StefanK From erik.osterlund at oracle.com Thu Feb 14 08:26:40 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 09:26:40 +0100 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly In-Reply-To: <8c0505a1-c5d7-8de6-057d-4603d43df2c8@oracle.com> References: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> <8c0505a1-c5d7-8de6-057d-4603d43df2c8@oracle.com> Message-ID: <60585915-7b87-e984-8c22-9acae0f019d1@oracle.com> Hi Stefan, Given that the remark from Jini is fixed, this looks good. I don't need another webrev. Thanks, /Erik On 2019-02-11 19:09, Stefan Karlsson wrote: > Hi Jini, > > On 2019-02-11 19:00, Jini George wrote: >> Hi Stefan, >> >> Looks good to me overall. One point though. >> >> physicalFieldOffset = type.getAddressField("_physical").getOffset(); >> >> Wrt the line above, is there any reason due to which getAddressField() >> instead of getField() was used ? getAddressField() is typically used >> when the field to be read in is a pointer. I feel getField() might be >> more appropriate in this situation. > > No, this is just an oversight. I have the same issue in my later > OopHandle patch. I'll change this. > > Thanks for reviewing, > StefanK >> >> >> Thanks, >> Jini. >> >> On 2/11/2019 1:23 PM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this small patch to resolve ZPageAllocator::_physical >>> as a value object instead of a pointer. >>> >>> https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8218732 >>> >>> This fixes the Heap Parameters view. >>> >>> Thanks, >>> StefanK > From erik.osterlund at oracle.com Thu Feb 14 08:38:07 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 09:38:07 +0100 Subject: RFR: 8218733: SA: CollectedHeap provides broken implementation for used() and capacity() In-Reply-To: References: Message-ID: <1f1bdf2f-c108-960d-99fe-e39347a3da07@oracle.com> Hi Stefan, Looks good. Thanks, /Erik On 2019-02-11 09:13, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove the broken implementation of > CollectedHeap used() and capacity() and instead force all GCs to provide > their own implementations. > > https://cr.openjdk.java.net/~stefank/8218733/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218733 > > This was found while running > serviceability/sa/TestHeapDumpForLargeArray.java on an experimental > implementation of heap dumping in ZGC. > > ZGC didn't provide a ZCollectedHeap.used() function and > CollectedHeap.used() was used instead at: > ????????// Check weather we should dump the heap as segments > ????????useSegmentedHeapDump = vm.getUniverse().heap().used() > > HPROF_SEGMENTED_HEAP_DUMP_THRESHOLD; > > Because of this we incorrectly did not use segmented heap dumps, and > therefore overflowed later in the code > > Aleksey and Roman, > > Could you verify that the implementation for Epsilon is correct? I also > haven't implemented capacity for Shenandoah, as the information isn't > trivially available in the ShenandoahHeap SA class. Do you want to fix > it as part of this patch, or should I create a separate RFE for Shenandoah? > > Thanks, > StefanK From erik.osterlund at oracle.com Thu Feb 14 09:01:01 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 10:01:01 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> Message-ID: <56d28bba-68d3-22e2-4e40-1615944c26d2@oracle.com> Hi Stefan, Looks good. One thing though... At VMOopHandle.java line 38: * Remove weird double indentation * Remove weird double semicolon * Use Field instead of AddressField I don't think I need another webrev. Thanks, /Erik On 2019-02-11 09:39, Stefan Karlsson wrote: > Hi all, > > Please review this patch to fix the resolving of oops inside the (VM) > OopHandles. > > https://cr.openjdk.java.net/~stefank/8218734/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218734 > > Before this patch the OopHandle::_obj was assumed to be located at > offset 0, and the SA resolved OopHandle (Klass::_java_mirror and > ClassLoaderData::_class_loader) without the required load barrier for > ZGC. I've added a new class VMOopHandle (The SA already has a > OopHandle), which handles the resolving (load or load + barrier). > > The OopHandle type is grouped under the Oops section in vmStructs.cpp. > It's not an oop, so I added a newline to separate it out from the rest. > Any suggestion of a better location in that file? > > Tested with the jtreg tests in serviceability/sa + patches to make ZGC > usable with the SA's hprof dumping. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 09:10:25 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 10:10:25 +0100 Subject: RFR: 8218731: SA: Use concrete class the as return type of VMObjectFactory.newObject In-Reply-To: <4e2039bf-259c-c3f2-5315-0959d439472b@oracle.com> References: <5e050e49-2f05-bed8-a7da-96fd2cbcf120@oracle.com> <4e2039bf-259c-c3f2-5315-0959d439472b@oracle.com> Message-ID: Thanks, Erik. Stefank On 2019-02-14 09:19, Erik ?sterlund wrote: > Hi Stefan, > > This looks good and trivial. > > Thanks, > /Erik > > On 2019-02-11 08:47, Stefan Karlsson wrote: >> Hi all, >> >> I propose this simple change to use the concrete class as the return >> type of VMObjectFactory.newObject. >> >> https://cr.openjdk.java.net/~stefank/8218731/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8218731 >> >> This allows us to specify the class only once when calling newObject. >> For example, now we can use: >> return VMObjectFactory.newObject(ZPhysicalMemoryManager.class, >> physicalAddr); >> >> Instead of having to write: >> ??????? return >> (ZPhysicalMemoryManager)VMObjectFactory.newObject(ZPhysicalMemoryManager.class, >> physicalAddr); >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Thu Feb 14 09:10:37 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 10:10:37 +0100 Subject: RFR: 8218732: SA: Resolves ZPageAllocator::_physical incorrectly In-Reply-To: <60585915-7b87-e984-8c22-9acae0f019d1@oracle.com> References: <29d9a447-7941-a09c-d45b-5bfc35d40c87@oracle.com> <62c5d1bd-6680-3649-d84b-5967d88cfd9f@oracle.com> <8c0505a1-c5d7-8de6-057d-4603d43df2c8@oracle.com> <60585915-7b87-e984-8c22-9acae0f019d1@oracle.com> Message-ID: <8558a94f-96bb-4a90-7f1f-ed54f629b021@oracle.com> Thanks, Erik. Stefank On 2019-02-14 09:26, Erik ?sterlund wrote: > Hi Stefan, > > Given that the remark from Jini is fixed, this looks good. I don't need > another webrev. > > Thanks, > /Erik > > On 2019-02-11 19:09, Stefan Karlsson wrote: >> Hi Jini, >> >> On 2019-02-11 19:00, Jini George wrote: >>> Hi Stefan, >>> >>> Looks good to me overall. One point though. >>> >>> physicalFieldOffset = type.getAddressField("_physical").getOffset(); >>> >>> Wrt the line above, is there any reason due to which >>> getAddressField() instead of getField() was used ? getAddressField() >>> is typically used when the field to be read in is a pointer. I feel >>> getField() might be more appropriate in this situation. >> >> No, this is just an oversight. I have the same issue in my later >> OopHandle patch. I'll change this. >> >> Thanks for reviewing, >> StefanK >>> >>> >>> Thanks, >>> Jini. >>> >>> On 2/11/2019 1:23 PM, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this small patch to resolve ZPageAllocator::_physical >>>> as a value object instead of a pointer. >>>> >>>> https://cr.openjdk.java.net/~stefank/8218732/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8218732 >>>> >>>> This fixes the Heap Parameters view. >>>> >>>> Thanks, >>>> StefanK >> From erik.osterlund at oracle.com Thu Feb 14 09:11:53 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 14 Feb 2019 10:11:53 +0100 Subject: RFR: 8218743: SA: Add support for large bitmaps In-Reply-To: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> References: <496a1cb2-0c84-c03d-cb0c-b57544a47cb0@oracle.com> Message-ID: <930d2dc8-c5d6-9c0e-19dd-b40c198af858@oracle.com> Hi Stefan, Looks good. Thanks, /Erik On 2019-02-11 13:36, Stefan Karlsson wrote: > Hi all, > > Please review this patch to add support for large bitmaps in the SA. > > http://cr.openjdk.java.net/~stefank/8218743/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8218743 > > I've added a minimal interface (at, atPut, clear) that uses longs > instead of ints, and changed MarkBits to use this interface. > > I've implemented a segmented bitmap that, currently, all GCs use when > asked for a bitmap in MarkBits. Later ZGC will provide its own > discontiguous bitmap, implementing the new interface, but that will be > sent out as a separate RFE. > > I've tested this with a temporary patch that lowers the segment size and > implements a jtreg test: > http://cr.openjdk.java.net/~stefank/8218743/webrev.test.01 > > I ran through the all the tests in serviceability/sa with both these > patches. > > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 14 09:12:03 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 14 Feb 2019 10:12:03 +0100 Subject: RFR: 8218734: SA: Incorrect and raw loads of OopHandles In-Reply-To: <56d28bba-68d3-22e2-4e40-1615944c26d2@oracle.com> References: <4aaa42ff-1f65-817d-9001-70cc8dc924f4@oracle.com> <56d28bba-68d3-22e2-4e40-1615944c26d2@oracle.com> Message-ID: <058b39bb-a0da-621d-6981-36bbf06ec23f@oracle.