From jini.george at oracle.com Wed Jan 2 05:07:20 2019 From: jini.george at oracle.com (Jini George) Date: Wed, 2 Jan 2019 10:37:20 +0530 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> Message-ID: <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> 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 From harold.seigel at oracle.com Wed Jan 2 15:41:29 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Wed, 2 Jan 2019 10:41:29 -0500 Subject: RFR 8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'. In-Reply-To: <2602b588-9d9e-253e-a875-046846141364@oracle.com> References: <71efe071-62c1-b1cc-c98f-953c6790eae1@oracle.com> <37e19362-0065-eb00-9bfb-7dcd67f55318@oracle.com> <3b0ff6e7-0fa6-d631-e203-c6070c1e66f0@oracle.com> <1a8d1c28-bc6c-da60-11bb-a57b48ee90b9@oracle.com> <2602b588-9d9e-253e-a875-046846141364@oracle.com> Message-ID: Hi David, Thanks for the review.? I pushed the fix. I think the existing test works because the double quoted arguments are passed directly to the java process, with no intervening shell, and so the double quotes are not removed.? When running the same command from the Windows prompt, the shell is stripping out the enclosing double quotes before passing the -Xlog args to Java. Harold On 12/21/2018 5:08 PM, David Holmes wrote: > Hi Harold, > > On 22/12/2018 4:32 am, Harold David Seigel wrote: >> Hi David, >> >> Here is the latest webrev.? The only difference between this and the >> previous webrev is the addition of "@bug 8215398" to the test: >> >> http://cr.openjdk.java.net/~hseigel/bug_8215398.3/webrev/index.html > > Okay. > >> >> The point that I'm trying to make about logging's handling of single >> quotes vs. double quotes can perhaps best be shown on Linux: >> >> If I execute the following commands (on Linux): >> >> ??? java -Xlog:safepoint=trace:\"dquotes.log\" -version >> >> ??? java -Xlog:safepoint=trace:\'squotes.log\' -version >> >> and then list out the current directory: >> >> ???? > ls >> ??? 'squotes.log'? dquotes.log >> >> it shows that logging stripped off the double quotes, but not the >> single quotes. > > I see - that is very odd behaviour. > >> With my fix, these commands succeed on Windows even when run from the >> Windows shell: >> >> ??? java -Xlog:safepoint=trace:d:\safepointtrace.txt -version >> ??? java -Xlog:safepoint=trace:"d:\safepointtrace.txt" -version >> ??? java -Xlog:safepoint=trace:"d:\safepoint trace.txt" -version >> >> This one continues to fail because of the single quote issue >> described above: >> >> ??? java -Xlog:safepoint=trace:'d:\safepointtrace.txt' -version >> >> I hope we can move forward with this change. > > I don't have an issue with your fix. I just don't understand how the > existing test actually works when the test cases seems to fail at the > command-line for me. > > Thanks, > David > >> Thanks, Harold >> >> >> On 12/20/2018 9:28 PM, David Holmes wrote: >>> On 21/12/2018 7:30 am, Harold David Seigel wrote: >>>> Hi David, >>>> >>>> Thanks for looking at this! >>>> >>>> Please review this updated webrev.? The fix is the same but the >>>> webrev contains a new test instead of modifying an existing test: >>>> >>>> http://cr.openjdk.java.net/~hseigel/bug_8215398.2/webrev/ >>> >>> I think renaming the existing test would be better as the only >>> difference is the use of quotes. But if you want a new test please add: >>> >>> @bug 8215398 >>> >>>> The logging implementation does not handle single quotes as >>>> expected.? For example, if the TestQuotedLogOutputs.java test is >>>> changed to use single quotes instead of double quotes, it will >>>> fail, even on Linux, because the single quotes are included as part >>>> of the file name.? They are not stripped off.? That is why "java >>>> -Xlog:safepoint=trace:'d:\safepointtrace.txt' -version" fails. >>> >>> It fails with double-quotes too! AFAICS it always fails in a Windows >>> command shell. Maybe the test only passes in cygwin shell? >>> >>> That said I don't understand your comment. I expect the quotes to >>> delimit the filename in case the filename has spaces in the path >>> component. If they aren't stripped off it wouldn't be tokenizing at >>> the internal ":", so ... ??? >>> >>> Thanks, >>> David >>> >>>> Perhaps a new bug is needed to change logging's handling of single >>>> quotes?? It's a bit surprising that this issue hasn't already been >>>> reported. >>>> >>>> Thanks, Harold >>>> >>>> On 12/20/2018 2:07 AM, David Holmes wrote: >>>>> Hi Harold, >>>>> >>>>> On 19/12/2018 11:22 pm, Harold David Seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this small change to fix JDK-8215398.? The fix >>>>>> works by not treating ':' as a delimiter in a -Xlog... option >>>>>> string if it is following by a '\' and preceded by either a >>>>>> single character or the text 'file='.? The fix is for Windows only. >>>>>> >>>>>> Open Webrev: >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8215398/webrev/index.html >>>>> >>>>> I think I can follow the fix. >>>>> >>>>> But I'm a bit concerned about the test. AFAICS the test thought it >>>>> was already testing this case - albeit with the path quoted: >>>>> >>>>> ? 42???????? // Ensure log files can be specified with full path. >>>>> ? 43???????? // On windows, this means that the file name will >>>>> contain >>>>> ? 44???????? // a colon ('C:\log.txt' for example), which is used to >>>>> ? 45???????? // separate -Xlog: options >>>>> (-Xlog:tags:filename:decorators). >>>>> ? 46???????? // Try to log to a file in our current directory, >>>>> using its absolute path. >>>>> ? 47???????? String baseName = "test file.log"; >>>>> ? 48???????? Path filePath = Paths.get(baseName).toAbsolutePath(); >>>>> ? 49???????? String fileName = filePath.toString(); >>>>> ? 50???????? File file = filePath.toFile(); >>>>> ... >>>>> ? 65???????? String[] validOutputs = new String[] { >>>>> ? 66???????????? quote + fileName + quote, >>>>> ? 67???????????? "file=" + quote + fileName + quote, >>>>> ? 68???????????? quote + fileName + quote + ":", >>>>> ? 69???????????? quote + fileName + quote + "::" >>>>> ? 70???????? }; >>>>> >>>>> But even quoted if I specify the drive designator in the path, it >>>>> fails! Here's a local attempt at this: >>>>> >>>>> D:\ade> apps\Java\jdk-11\fastdebug\bin\java >>>>> -Xlog:safepoint=trace:'d:\safepointtrace.txt' -version >>>>> [0.014s][error][logging] Invalid decorator '\safepointtrace.txt''. >>>>> Invalid -Xlog option >>>>> '-Xlog:safepoint=trace:'d:\safepointtrace.txt'', see error log for >>>>> details. >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> So AFAICS the test can't possibly have been testing what it >>>>> thought it was testing! ??? >>>>> >>>>> I'm also not sure about just adding some unquoted variants to the >>>>> existing TestQuotedLogOutputs without renaming the test and >>>>> updating the @summary >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215398 >>>>>> >>>>>> The fix was regression tested by running Mach5 tiers 1 and 2 >>>>>> tests and builds on Linux-x64, Windows, and Mac OS X, running >>>>>> tiers 3-5 tests on Linux-x64, running JCK-12 Lang and VM tests on >>>>>> Linux-x64, and by hand on Windows. >>>>>> >>>>>> Thanks, Harol >>>>>> >>>> >> From goetz.lindenmaier at sap.com Wed Jan 2 15:47:33 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 2 Jan 2019 15:47:33 +0000 Subject: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms. In-Reply-To: <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> References: <101ecbcd-76c9-2311-04e4-871ca4f3764a@oracle.com> <0176fe1fda7c495582435d2b2a48dbb6@sap.com> <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> Message-ID: <125be3053c0b446ebbca14f84777115c@sap.com> Hi Gary, as promised, I'll do a follow up fixing all these. But all the tests you mention are either not configured for aix (@requires linux etc) or are passing currently. So no need for action here. I just want to do a fix for the nsk tests. So can I consider my updated webrev as reviewed by you? http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ Best regards, Goetz. > -----Original Message----- > From: gary.adams at oracle.com > Sent: Montag, 31. Dezember 2018 16:59 > To: Lindenmaier, Goetz ; serviceability-dev > (serviceability-dev at openjdk.java.net) > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and > AIX platforms. > > Here are few more DYLD_LIBRARY_PATH locations that would be worth > checking > > ./jdk/vm/JniInvocationTest.java:50: env.compute("DYLD_LIBRARY_PATH", (k, > v) -> (k == null) ? libdir : v + ":" + libdir); > ./jdk/tools/launcher/ExecutionEnvironment.java:66:??????????? ? > "DYLD_LIBRARY_PATH" > ./jdk/tools/launcher/JliLaunchTest.java:56:??????????? String > LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" : > "LD_LIBRARY_PATH"; > ./jdk/sun/security/krb5/auto/BasicProc.java:311: > p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos)); > ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402: > .env("DYLD_LIBRARY_PATH", libDir) > ./jdk/sun/security/krb5/auto/KDC.java:1725: "DYLD_LIBRARY_PATH", > nativePath + "/lib", > ./jdk/sun/security/krb5/auto/KDC.java:1818: "DYLD_LIBRARY_PATH", > nativePath + "/lib", > ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name = Platform.isOSX() > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; > ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72: (Platform.isOSX() > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"); > > On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote: > > Hi Gary, > > > >> Would it make sense to add a method to > test/lib/jdk/test/lib/Platform.java > >> similar to sharedLibraryExt() to cover the envName setting? > > Good point. I'll post a follow up change next year ... and believe me, > > that's not too far in the future ?? > > I'd like to keep this out of this test fix, as I want to downport it to > > 11 at some point and thus keep it small so that it will apply cleanly. > > > >> Are the other places DYLD_LIBRARY_PATH is set also need to be > >> updated for AIX? > > Alloc001 might need it. The other vmTestbase tests are all passing, > > so I didn't touch them. > > Webrev with alloc001: > > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ > > > > Best regards, > > Goetz. > > > > > > > >> > >> On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> Some of the nsk tests are not properly configured for the > >>> above platforms: > >>> > >>> nsk/jvmti/RetransformClasses/retransform003/TestDriver.java: > >>> > >> > nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.ja > >> va > >>> The tests use the path to native libraries, which is named "LIBPATH" on > >> AIX. > >>> nsk/share/jdi/ArgumentHandler.java > >>> Add ppc/s390/aix which don't have a shared memory connector. This > >> disables a row of failing tests. > >>> Please review this change. I would like to push it to jdk12, as it is a mere > >> test fix. > >>> http://cr.openjdk.java.net/~goetz/wr18/8215975- > nskTests/01/index.html > >>> > >>> Best regards, > >>> Goetz. > From gary.adams at oracle.com Wed Jan 2 16:12:31 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 02 Jan 2019 11:12:31 -0500 Subject: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms. In-Reply-To: <125be3053c0b446ebbca14f84777115c@sap.com> References: <101ecbcd-76c9-2311-04e4-871ca4f3764a@oracle.com> <0176fe1fda7c495582435d2b2a48dbb6@sap.com> <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> <125be3053c0b446ebbca14f84777115c@sap.com> Message-ID: <5C2CE2EF.30806@oracle.com> I had no further comments. On 1/2/19, 10:47 AM, Lindenmaier, Goetz wrote: > Hi Gary, > > as promised, I'll do a follow up fixing all these. > But all the tests you mention are either not configured for aix (@requires linux etc) > or are passing currently. So no need for action here. > > I just want to do a fix for the nsk tests. > So can I consider my updated webrev as reviewed by you? > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ > > Best regards, > Goetz. > > >> -----Original Message----- >> From: gary.adams at oracle.com >> Sent: Montag, 31. Dezember 2018 16:59 >> To: Lindenmaier, Goetz; serviceability-dev >> (serviceability-dev at openjdk.java.net) >> Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and >> AIX platforms. >> >> Here are few more DYLD_LIBRARY_PATH locations that would be worth >> checking >> >> ./jdk/vm/JniInvocationTest.java:50: env.compute("DYLD_LIBRARY_PATH", (k, >> v) -> (k == null) ? libdir : v + ":" + libdir); >> ./jdk/tools/launcher/ExecutionEnvironment.java:66: ? >> "DYLD_LIBRARY_PATH" >> ./jdk/tools/launcher/JliLaunchTest.java:56: String >> LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" : >> "LD_LIBRARY_PATH"; >> ./jdk/sun/security/krb5/auto/BasicProc.java:311: >> p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos)); >> ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402: >> .env("DYLD_LIBRARY_PATH", libDir) >> ./jdk/sun/security/krb5/auto/KDC.java:1725: "DYLD_LIBRARY_PATH", >> nativePath + "/lib", >> ./jdk/sun/security/krb5/auto/KDC.java:1818: "DYLD_LIBRARY_PATH", >> nativePath + "/lib", >> ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name = Platform.isOSX() >> ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; >> ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72: (Platform.isOSX() >> ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"); >> >> On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote: >>> Hi Gary, >>> >>>> Would it make sense to add a method to >> test/lib/jdk/test/lib/Platform.java >>>> similar to sharedLibraryExt() to cover the envName setting? >>> Good point. I'll post a follow up change next year ... and believe me, >>> that's not too far in the future ?? >>> I'd like to keep this out of this test fix, as I want to downport it to >>> 11 at some point and thus keep it small so that it will apply cleanly. >>> >>>> Are the other places DYLD_LIBRARY_PATH is set also need to be >>>> updated for AIX? >>> Alloc001 might need it. The other vmTestbase tests are all passing, >>> so I didn't touch them. >>> Webrev with alloc001: >>> http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ >>> >>> Best regards, >>> Goetz. >>> >>> >>> >>>> On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> Some of the nsk tests are not properly configured for the >>>>> above platforms: >>>>> >>>>> nsk/jvmti/RetransformClasses/retransform003/TestDriver.java: >>>>> >> nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.ja >>>> va >>>>> The tests use the path to native libraries, which is named "LIBPATH" on >>>> AIX. >>>>> nsk/share/jdi/ArgumentHandler.java >>>>> Add ppc/s390/aix which don't have a shared memory connector. This >>>> disables a row of failing tests. >>>>> Please review this change. I would like to push it to jdk12, as it is a mere >>>> test fix. >>>>> http://cr.openjdk.java.net/~goetz/wr18/8215975- >> nskTests/01/index.html >>>>> Best regards, >>>>> Goetz. From serguei.spitsyn at oracle.com Wed Jan 2 19:22:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 2 Jan 2019 11:22:14 -0800 Subject: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions In-Reply-To: References: <5C1D3662.4070505@oracle.com> Message-ID: Hi Gary, Looks good to me. Thanks, Serguei On 12/31/18 10:06, gary.adams at oracle.com wrote: > Here's a revised webrev. > > ? Webrev: > http://bussund0416.us.oracle.com/export/users/gradams/work/webrevs/8211343/webrev.01/ > > Updates in this round of changes : > ? - replaced index() with strchr() to avoid platform dependent issues > with strings.h include > ? - removed NSK_JVMTI_OPTION_VAL_SEP > ? - removed temporary debugging print statements > ? - removed empty options string from SetNativeMethodPrefix001 > ? - added free for temporary strdup buffer > ? - updated copyright for 2019 > > On 12/21/18 1:52 PM, Gary Adams wrote: >> Here is a first pass at a replacement parser for jvmti test options. >> >> ? Webrev: http://cr.openjdk.java.net/~gadams/8211343/webrev.00/ >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8211343 >> >> Testing is in progress. Need to check out more platforms. >> On local linux testing one jvmti test failed SetNativeMethodPrefix001 >> which passed an empty options string. >> ... > > From zanglin5 at jd.com Thu Jan 3 02:21:49 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Thu, 3 Jan 2019 02:21:49 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> Message-ID: <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Thu Jan 3 02:51:27 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 3 Jan 2019 08:21:27 +0530 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out Message-ID: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> Hello! Requesting reviews for a small fix for fixing the timeout failures of the test: ClhsdbInspect.java by increasing the timeout value. BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html The fix has been tested with about 200 repeated runs on windows post this fix. The timeout was not observed. Thanks, Jini. From serguei.spitsyn at oracle.com Thu Jan 3 05:06:52 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 2 Jan 2019 21:06:52 -0800 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> Message-ID: Hi Jini, It looks good to me. I hope you saw this test intermittently failing without the fix. Thanks, Serguei On 1/2/19 18:51, Jini George wrote: > Hello! > > Requesting reviews for a small fix for fixing the timeout failures of > the test: ClhsdbInspect.java by increasing the timeout value. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 > Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html > > The fix has been tested with about 200 repeated runs on windows post > this fix. The timeout was not observed. > > Thanks, > Jini. > > > From volker.simonis at gmail.com Thu Jan 3 08:49:42 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 Jan 2019 09:49:42 +0100 Subject: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms. In-Reply-To: <125be3053c0b446ebbca14f84777115c@sap.com> References: <101ecbcd-76c9-2311-04e4-871ca4f3764a@oracle.com> <0176fe1fda7c495582435d2b2a48dbb6@sap.com> <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> <125be3053c0b446ebbca14f84777115c@sap.com> Message-ID: Looks good to me. Thanks, Volker On Wed, Jan 2, 2019 at 4:48 PM Lindenmaier, Goetz wrote: > Hi Gary, > > as promised, I'll do a follow up fixing all these. > But all the tests you mention are either not configured for aix (@requires > linux etc) > or are passing currently. So no need for action here. > > I just want to do a fix for the nsk tests. > So can I consider my updated webrev as reviewed by you? > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ > > Best regards, > Goetz. > > > > -----Original Message----- > > From: gary.adams at oracle.com > > Sent: Montag, 31. Dezember 2018 16:59 > > To: Lindenmaier, Goetz ; serviceability-dev > > (serviceability-dev at openjdk.java.net) < > serviceability-dev at openjdk.java.net> > > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 > and > > AIX platforms. > > > > Here are few more DYLD_LIBRARY_PATH locations that would be worth > > checking > > > > ./jdk/vm/JniInvocationTest.java:50: env.compute("DYLD_LIBRARY_PATH", (k, > > v) -> (k == null) ? libdir : v + ":" + libdir); > > ./jdk/tools/launcher/ExecutionEnvironment.java:66: ? > > "DYLD_LIBRARY_PATH" > > ./jdk/tools/launcher/JliLaunchTest.java:56: String > > LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" : > > "LD_LIBRARY_PATH"; > > ./jdk/sun/security/krb5/auto/BasicProc.java:311: > > p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos)); > > ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402: > > .env("DYLD_LIBRARY_PATH", libDir) > > ./jdk/sun/security/krb5/auto/KDC.java:1725: "DYLD_LIBRARY_PATH", > > nativePath + "/lib", > > ./jdk/sun/security/krb5/auto/KDC.java:1818: "DYLD_LIBRARY_PATH", > > nativePath + "/lib", > > ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name = Platform.isOSX() > > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; > > ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72: (Platform.isOSX() > > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"); > > > > On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote: > > > Hi Gary, > > > > > >> Would it make sense to add a method to > > test/lib/jdk/test/lib/Platform.java > > >> similar to sharedLibraryExt() to cover the envName setting? > > > Good point. I'll post a follow up change next year ... and believe me, > > > that's not too far in the future ?? > > > I'd like to keep this out of this test fix, as I want to downport it to > > > 11 at some point and thus keep it small so that it will apply cleanly. > > > > > >> Are the other places DYLD_LIBRARY_PATH is set also need to be > > >> updated for AIX? > > > Alloc001 might need it. The other vmTestbase tests are all passing, > > > so I didn't touch them. > > > Webrev with alloc001: > > > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > >> > > >> On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote: > > >>> Hi, > > >>> > > >>> Some of the nsk tests are not properly configured for the > > >>> above platforms: > > >>> > > >>> nsk/jvmti/RetransformClasses/retransform003/TestDriver.java: > > >>> > > >> > > nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.ja > > >> va > > >>> The tests use the path to native libraries, which is named > "LIBPATH" on > > >> AIX. > > >>> nsk/share/jdi/ArgumentHandler.java > > >>> Add ppc/s390/aix which don't have a shared memory connector. This > > >> disables a row of failing tests. > > >>> Please review this change. I would like to push it to jdk12, as it > is a mere > > >> test fix. > > >>> http://cr.openjdk.java.net/~goetz/wr18/8215975- > > nskTests/01/index.html > > >>> > > >>> Best regards, > > >>> Goetz. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jan 3 09:13:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 3 Jan 2019 01:13:14 -0800 Subject: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms. In-Reply-To: References: <101ecbcd-76c9-2311-04e4-871ca4f3764a@oracle.com> <0176fe1fda7c495582435d2b2a48dbb6@sap.com> <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> <125be3053c0b446ebbca14f84777115c@sap.com> Message-ID: An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Jan 3 09:16:26 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Jan 2019 09:16:26 +0000 Subject: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms. In-Reply-To: References: <101ecbcd-76c9-2311-04e4-871ca4f3764a@oracle.com> <0176fe1fda7c495582435d2b2a48dbb6@sap.com> <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> <125be3053c0b446ebbca14f84777115c@sap.com> Message-ID: <84ea43c292214d48a0b1a48fcf7ff942@sap.com> Hi Volker, thanks for looking at this. ... I just came up with another single line I'd like to add here: http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/03/test/hotspot/jtreg/vmTestbase/nsk/jvmti/Allocate/alloc001/TestDescription.java.udiff.html I'd like to exclude this test as Aix does not support setting ulimit -v: New webrev: http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/03/ ... and I'll update the copyrights before pushing ... Sorry for the inconvenience! Goetz > -----Original Message----- > From: Volker Simonis > Sent: Donnerstag, 3. Januar 2019 09:50 > To: Lindenmaier, Goetz > Cc: gary.adams at oracle.com; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and > AIX platforms. > > Looks good to me. > > Thanks, > Volker > > > On Wed, Jan 2, 2019 at 4:48 PM Lindenmaier, Goetz > > > wrote: > > > Hi Gary, > > as promised, I'll do a follow up fixing all these. > But all the tests you mention are either not configured for aix > (@requires linux etc) > or are passing currently. So no need for action here. > > I just want to do a fix for the nsk tests. > So can I consider my updated webrev as reviewed by you? > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ > > Best regards, > Goetz. > > > > -----Original Message----- > > From: gary.adams at oracle.com > > > > Sent: Montag, 31. Dezember 2018 16:59 > > To: Lindenmaier, Goetz >; serviceability-dev > > (serviceability-dev at openjdk.java.net dev at openjdk.java.net> ) > > > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, > S390 and > > AIX platforms. > > > > Here are few more DYLD_LIBRARY_PATH locations that would be > worth > > checking > > > > ./jdk/vm/JniInvocationTest.java:50: > env.compute("DYLD_LIBRARY_PATH", (k, > > v) -> (k == null) ? libdir : v + ":" + libdir); > > ./jdk/tools/launcher/ExecutionEnvironment.java:66: ? > > "DYLD_LIBRARY_PATH" > > ./jdk/tools/launcher/JliLaunchTest.java:56: String > > LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" : > > "LD_LIBRARY_PATH"; > > ./jdk/sun/security/krb5/auto/BasicProc.java:311: > > p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos)); > > ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402: > > .env("DYLD_LIBRARY_PATH", libDir) > > ./jdk/sun/security/krb5/auto/KDC.java:1725: > "DYLD_LIBRARY_PATH", > > nativePath + "/lib", > > ./jdk/sun/security/krb5/auto/KDC.java:1818: > "DYLD_LIBRARY_PATH", > > nativePath + "/lib", > > ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name = > Platform.isOSX() > > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; > > ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72: > (Platform.isOSX() > > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"); > > > > On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote: > > > Hi Gary, > > > > > >> Would it make sense to add a method to > > test/lib/jdk/test/lib/Platform.java > > >> similar to sharedLibraryExt() to cover the envName setting? > > > Good point. I'll post a follow up change next year ... and believe > me, > > > that's not too far in the future ?? > > > I'd like to keep this out of this test fix, as I want to downport it to > > > 11 at some point and thus keep it small so that it will apply > cleanly. > > > > > >> Are the other places DYLD_LIBRARY_PATH is set also need to be > > >> updated for AIX? > > > Alloc001 might need it. The other vmTestbase tests are all > passing, > > > so I didn't touch them. > > > Webrev with alloc001: > > > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > >> > > >> On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote: > > >>> Hi, > > >>> > > >>> Some of the nsk tests are not properly configured for the > > >>> above platforms: > > >>> > > >>> > nsk/jvmti/RetransformClasses/retransform003/TestDriver.java: > > >>> > > >> > > > nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.ja > > >> va > > >>> The tests use the path to native libraries, which is named > "LIBPATH" on > > >> AIX. > > >>> nsk/share/jdi/ArgumentHandler.java > > >>> Add ppc/s390/aix which don't have a shared memory > connector. This > > >> disables a row of failing tests. > > >>> Please review this change. I would like to push it to jdk12, as it > is a mere > > >> test fix. > > >>> http://cr.openjdk.java.net/~goetz/wr18/8215975- > > nskTests/01/index.html > > >>> > > >>> Best regards, > > >>> Goetz. > > > > From volker.simonis at gmail.com Thu Jan 3 10:06:34 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 3 Jan 2019 11:06:34 +0100 Subject: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms. In-Reply-To: <84ea43c292214d48a0b1a48fcf7ff942@sap.com> References: <101ecbcd-76c9-2311-04e4-871ca4f3764a@oracle.com> <0176fe1fda7c495582435d2b2a48dbb6@sap.com> <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> <125be3053c0b446ebbca14f84777115c@sap.com> <84ea43c292214d48a0b1a48fcf7ff942@sap.com> Message-ID: OK, still looks good! Thanks, Volker On Thu, Jan 3, 2019 at 10:16 AM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Volker, > > thanks for looking at this. > > ... I just came up with another single line I'd like to add here: > > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/03/test/hotspot/jtreg/vmTestbase/nsk/jvmti/Allocate/alloc001/TestDescription.java.udiff.html > I'd like to exclude this test as Aix does not support setting ulimit -v: > > New webrev: > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/03/ > > ... and I'll update the copyrights before pushing ... > > Sorry for the inconvenience! > Goetz > > > -----Original Message----- > > From: Volker Simonis > > Sent: Donnerstag, 3. Januar 2019 09:50 > > To: Lindenmaier, Goetz > > Cc: gary.adams at oracle.com; serviceability-dev (serviceability- > > dev at openjdk.java.net) > > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 > and > > AIX platforms. > > > > Looks good to me. > > > > Thanks, > > Volker > > > > > > On Wed, Jan 2, 2019 at 4:48 PM Lindenmaier, Goetz > > > > > wrote: > > > > > > Hi Gary, > > > > as promised, I'll do a follow up fixing all these. > > But all the tests you mention are either not configured for aix > > (@requires linux etc) > > or are passing currently. So no need for action here. > > > > I just want to do a fix for the nsk tests. > > So can I consider my updated webrev as reviewed by you? > > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ > > > > Best regards, > > Goetz. > > > > > > > -----Original Message----- > > > From: gary.adams at oracle.com > > > > > > Sent: Montag, 31. Dezember 2018 16:59 > > > To: Lindenmaier, Goetz > >; serviceability-dev > > > (serviceability-dev at openjdk.java.net > dev at openjdk.java.net> ) > > > > > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the > PPC, > > S390 and > > > AIX platforms. > > > > > > Here are few more DYLD_LIBRARY_PATH locations that would be > > worth > > > checking > > > > > > ./jdk/vm/JniInvocationTest.java:50: > > env.compute("DYLD_LIBRARY_PATH", (k, > > > v) -> (k == null) ? libdir : v + ":" + libdir); > > > ./jdk/tools/launcher/ExecutionEnvironment.java:66: ? > > > "DYLD_LIBRARY_PATH" > > > ./jdk/tools/launcher/JliLaunchTest.java:56: String > > > LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" : > > > "LD_LIBRARY_PATH"; > > > ./jdk/sun/security/krb5/auto/BasicProc.java:311: > > > p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos)); > > > ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402: > > > .env("DYLD_LIBRARY_PATH", libDir) > > > ./jdk/sun/security/krb5/auto/KDC.java:1725: > > "DYLD_LIBRARY_PATH", > > > nativePath + "/lib", > > > ./jdk/sun/security/krb5/auto/KDC.java:1818: > > "DYLD_LIBRARY_PATH", > > > nativePath + "/lib", > > > ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name = > > Platform.isOSX() > > > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; > > > ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72: > > (Platform.isOSX() > > > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"); > > > > > > On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote: > > > > Hi Gary, > > > > > > > >> Would it make sense to add a method to > > > test/lib/jdk/test/lib/Platform.java > > > >> similar to sharedLibraryExt() to cover the envName setting? > > > > Good point. I'll post a follow up change next year ... and > believe > > me, > > > > that's not too far in the future ?? > > > > I'd like to keep this out of this test fix, as I want to > downport it to > > > > 11 at some point and thus keep it small so that it will apply > > cleanly. > > > > > > > >> Are the other places DYLD_LIBRARY_PATH is set also need to be > > > >> updated for AIX? > > > > Alloc001 might need it. The other vmTestbase tests are all > > passing, > > > > so I didn't touch them. > > > > Webrev with alloc001: > > > > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/ > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > > > > > > > > >> > > > >> On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote: > > > >>> Hi, > > > >>> > > > >>> Some of the nsk tests are not properly configured for the > > > >>> above platforms: > > > >>> > > > >>> > > nsk/jvmti/RetransformClasses/retransform003/TestDriver.java: > > > >>> > > > >> > > > > > nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.ja > > > >> va > > > >>> The tests use the path to native libraries, which is named > > "LIBPATH" on > > > >> AIX. > > > >>> nsk/share/jdi/ArgumentHandler.java > > > >>> Add ppc/s390/aix which don't have a shared memory > > connector. This > > > >> disables a row of failing tests. > > > >>> Please review this change. I would like to push it to jdk12, > as it > > is a mere > > > >> test fix. > > > >>> http://cr.openjdk.java.net/~goetz/wr18/8215975- > > > nskTests/01/index.html > > > >>> > > > >>> Best regards, > > > >>> Goetz. > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Jan 3 10:23:32 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 3 Jan 2019 10:23:32 +0000 Subject: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms. In-Reply-To: References: <101ecbcd-76c9-2311-04e4-871ca4f3764a@oracle.com> <0176fe1fda7c495582435d2b2a48dbb6@sap.com> <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> <125be3053c0b446ebbca14f84777115c@sap.com> Message-ID: <24bc20ec5ee34222854515182ee9047a@sap.com> Thanks Serguei! Best regards, Goetz. > -----Original Message----- > From: serguei.spitsyn at oracle.com > Sent: Donnerstag, 3. Januar 2019 10:13 > To: Volker Simonis ; Lindenmaier, Goetz > > Cc: serviceability-dev (serviceability-dev at openjdk.java.net) dev at openjdk.java.net> > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and > AIX platforms. > > Hi Goetz, > > ++LGTM > > Thanks, > Serguei > > > On 1/3/19 00:49, Volker Simonis wrote: > > > Looks good to me. > > Thanks, > Volker > > > On Wed, Jan 2, 2019 at 4:48 PM Lindenmaier, Goetz > > > wrote: > > > Hi Gary, > > as promised, I'll do a follow up fixing all these. > But all the tests you mention are either not configured for aix > (@requires linux etc) > or are passing currently. So no need for action here. > > I just want to do a fix for the nsk tests. > So can I consider my updated webrev as reviewed by you? > http://cr.openjdk.java.net/~goetz/wr18/8215975- > nskTests/02/ > > Best regards, > Goetz. > > > > -----Original Message----- > > From: gary.adams at oracle.com > > > > Sent: Montag, 31. Dezember 2018 16:59 > > To: Lindenmaier, Goetz >; serviceability-dev > > (serviceability-dev at openjdk.java.net dev at openjdk.java.net> ) > > > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to > the PPC, S390 and > > AIX platforms. > > > > Here are few more DYLD_LIBRARY_PATH locations that > would be worth > > checking > > > > ./jdk/vm/JniInvocationTest.java:50: > env.compute("DYLD_LIBRARY_PATH", (k, > > v) -> (k == null) ? libdir : v + ":" + libdir); > > ./jdk/tools/launcher/ExecutionEnvironment.java:66: > ? > > "DYLD_LIBRARY_PATH" > > ./jdk/tools/launcher/JliLaunchTest.java:56: String > > LD_LIBRARY_PATH = Platform.isOSX() ? > "DYLD_LIBRARY_PATH" : > > "LD_LIBRARY_PATH"; > > ./jdk/sun/security/krb5/auto/BasicProc.java:311: > > p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos)); > > > ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402: > > .env("DYLD_LIBRARY_PATH", libDir) > > ./jdk/sun/security/krb5/auto/KDC.java:1725: > "DYLD_LIBRARY_PATH", > > nativePath + "/lib", > > ./jdk/sun/security/krb5/auto/KDC.java:1818: > "DYLD_LIBRARY_PATH", > > nativePath + "/lib", > > ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name = > Platform.isOSX() > > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"; > > ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72: > (Platform.isOSX() > > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH"); > > > > On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote: > > > Hi Gary, > > > > > >> Would it make sense to add a method to > > test/lib/jdk/test/lib/Platform.java > > >> similar to sharedLibraryExt() to cover the envName > setting? > > > Good point. I'll post a follow up change next year ... and > believe me, > > > that's not too far in the future ?? > > > I'd like to keep this out of this test fix, as I want to > downport it to > > > 11 at some point and thus keep it small so that it will > apply cleanly. > > > > > >> Are the other places DYLD_LIBRARY_PATH is set also > need to be > > >> updated for AIX? > > > Alloc001 might need it. The other vmTestbase tests are all > passing, > > > so I didn't touch them. > > > Webrev with alloc001: > > > http://cr.openjdk.java.net/~goetz/wr18/8215975- > nskTests/02/ > > > > > > Best regards, > > > Goetz. > > > > > > > > > > > >> > > >> On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote: > > >>> Hi, > > >>> > > >>> Some of the nsk tests are not properly configured for > the > > >>> above platforms: > > >>> > > >>> > nsk/jvmti/RetransformClasses/retransform003/TestDriver.java: > > >>> > > >> > > > nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.ja > > >> va > > >>> The tests use the path to native libraries, which is > named "LIBPATH" on > > >> AIX. > > >>> nsk/share/jdi/ArgumentHandler.java > > >>> Add ppc/s390/aix which don't have a shared memory > connector. This > > >> disables a row of failing tests. > > >>> Please review this change. I would like to push it to > jdk12, as it is a mere > > >> test fix. > > >>> http://cr.openjdk.java.net/~goetz/wr18/8215975- > > nskTests/01/index.html > > >>> > > >>> Best regards, > > >>> Goetz. > > > > > From sgehwolf at redhat.com Thu Jan 3 11:24:00 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 03 Jan 2019 12:24:00 +0100 Subject: [8u] RFR: 8216058: [TESTBUG] tools/launcher/VersionCheck.java fails after JDK-8215992 Message-ID: <4a1285c1d5138110031e8af6efd5a01d41ef1208.camel@redhat.com> Hi, Could I please get a review for this 8u-only fix? Latest jdk8u-dev forest contains new launchers for SA tools, clhsdb and hsdb. The latter is a GUI app and when launched will block until the user closes the GUI. This results in a timout in tools/launcher/VersionCheck.java which launches all tools in JAVA_HOME/bin. In particular, hsdb -version would block in the described way and causes the timeout. The fix is to blacklist both new tools for the '-version' option. They only support '-J-version'. Bug: https://bugs.openjdk.java.net/browse/JDK-8216058 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8216058/webrev.01/ Testing: Failing VersionCheck.java prior the patch, passing after. Thoughts? Thanks, Severin From aph at redhat.com Thu Jan 3 12:01:25 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 3 Jan 2019 12:01:25 +0000 Subject: [8u] RFR: 8216058: [TESTBUG] tools/launcher/VersionCheck.java fails after JDK-8215992 In-Reply-To: <4a1285c1d5138110031e8af6efd5a01d41ef1208.camel@redhat.com> References: <4a1285c1d5138110031e8af6efd5a01d41ef1208.camel@redhat.com> Message-ID: On 1/3/19 11:24 AM, Severin Gehwolf wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8216058 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8216058/webrev.01/ > > Testing: Failing VersionCheck.java prior the patch, passing after. > > Thoughts? Yes, that looks like the obvious fix. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jini.george at oracle.com Thu Jan 3 12:27:37 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 3 Jan 2019 17:57:37 +0530 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> Message-ID: Thank you very much for the review, Serguei. Yes, I noticed it failing intermittently without the fix -- once it took 9m 13s to execute and failed, and in one of my post fix test executions, I had noticed it taking about 11+ min (which would have caused a failure without the fix). Thanks, Jini. On 1/3/2019 10:36 AM, serguei.spitsyn at oracle.com wrote: > Hi Jini, > > It looks good to me. > I hope you saw this test intermittently failing without the fix. > > Thanks, > Serguei > > > On 1/2/19 18:51, Jini George wrote: >> Hello! >> >> Requesting reviews for a small fix for fixing the timeout failures of >> the test: ClhsdbInspect.java by increasing the timeout value. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html >> >> The fix has been tested with about 200 repeated runs on windows post >> this fix. The timeout was not observed. >> >> Thanks, >> Jini. >> >> >> > From gary.adams at oracle.com Thu Jan 3 12:58:58 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 03 Jan 2019 07:58:58 -0500 Subject: RFR: JDK-8216059: nsk_jvmti_parseoptions still has dependency on tilde separator Message-ID: <5C2E0712.90006@oracle.com> The test/hotspot/jtreg/vmTestbase/vm/mlvm tests were missed when the parser was updated for JDK-8211343. Those tests use tilde (~) as an option separator. Here's a quick fix to add tilde back as an option separator. Testing is in progress. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp @@ -221,7 +221,7 @@ char *str = NULL; char *name = NULL; char *value = NULL; - const char *delimiters = " ,"; + const char *delimiters = " ,~"; if (options == NULL) return success; From chris.plummer at oracle.com Thu Jan 3 15:31:20 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 3 Jan 2019 07:31:20 -0800 Subject: RFR: JDK-8216059: nsk_jvmti_parseoptions still has dependency on tilde separator In-Reply-To: <5C2E0712.90006@oracle.com> References: <5C2E0712.90006@oracle.com> Message-ID: <884adad4-6b35-9752-6904-fa9b65e5ec93@oracle.com> Looks good. Chris On 1/3/19 4:58 AM, Gary Adams wrote: > The test/hotspot/jtreg/vmTestbase/vm/mlvm tests were missed when the > parser was updated for > JDK-8211343. Those tests use tilde (~) as an option separator. > > Here's a quick fix to add tilde back as an option separator. Testing > is in progress. > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp > b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp > --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp > +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp > @@ -221,7 +221,7 @@ > ???? char *str = NULL; > ???? char *name = NULL; > ???? char *value = NULL; > -??? const char *delimiters = " ,"; > +??? const char *delimiters = " ,~"; > ???? if (options == NULL) > ???????? return success; > From chris.plummer at oracle.com Thu Jan 3 16:24:05 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 3 Jan 2019 08:24:05 -0800 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> Message-ID: Hi Jini, 2400 seems excessive. That's 40 minutes, which translates to 160 minutes for our test runs. Did you mean timeout=240? It looks like a few of the Clhsdb tests were given large timeouts that are probably much more than is needed. thanks, Chris On 1/2/19 6:51 PM, Jini George wrote: > Hello! > > Requesting reviews for a small fix for fixing the timeout failures of > the test: ClhsdbInspect.java by increasing the timeout value. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 > Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html > > The fix has been tested with about 200 repeated runs on windows post > this fix. The timeout was not observed. > > Thanks, > Jini. > > > From gnu.andrew at redhat.com Thu Jan 3 16:33:06 2019 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 3 Jan 2019 16:33:06 +0000 Subject: [8u] RFR: 8216058: [TESTBUG] tools/launcher/VersionCheck.java fails after JDK-8215992 In-Reply-To: References: <4a1285c1d5138110031e8af6efd5a01d41ef1208.camel@redhat.com> Message-ID: On Thu, 3 Jan 2019 at 12:01, Andrew Haley wrote: > > On 1/3/19 11:24 AM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8216058 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8216058/webrev.01/ > > > > Testing: Failing VersionCheck.java prior the patch, passing after. > > > > Thoughts? > > Yes, that looks like the obvious fix. Thanks. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 +1. Seems to be the same case as appletviewer which is also in that list. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From jini.george at oracle.com Thu Jan 3 18:16:13 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 3 Jan 2019 23:46:13 +0530 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 Message-ID: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> Hello! Requesting reviews for: https://bugs.openjdk.java.net/browse/JDK-8215544 Webrev: http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/index.html The changes here are primarily for modifying the ClhsdbLauncher used for SA tests to check if 'sudo' privileges can be added for executing MacOS tests, and if so, adding these privileges before executing the tests. This is related to the changes which were proposed with: http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024373.html for (JDK-8199700: SA: Enable jhsdb jtreg tests for Mac OS X). The issue brought out with the proposed changes for JDK-8199700 have been fixed. This patch addresses the case where 'sudo' fails with errors like: sudo: no tty present and no askpass program specified or sudo: a password is required or if 'sudo' waits for a password. In these cases, the tests continue to get skipped. Many thanks to Goetz Lindenmaier for helping me with multiple rounds of testing of this in the SAP test farms! With this patch, about 22 SA tests get enabled now on MacOS on Mach5. More details at: https://bugs.openjdk.java.net/browse/JDK-8215544 Thanks, Jini. From jini.george at oracle.com Thu Jan 3 18:26:25 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 3 Jan 2019 23:56:25 +0530 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> Message-ID: Thank you very much, Chris, for taking a look. I will modify the timeout value to be 480 ==> 8 minutes ==> 32 minutes for tier1. Sounds good ? Thanks! Jini. On 1/3/2019 9:54 PM, Chris Plummer wrote: > Hi Jini, > > 2400 seems excessive. That's 40 minutes, which translates to 160 minutes > for our test runs. Did you mean timeout=240? It looks like a few of the > Clhsdb tests were given large timeouts that are probably much more than > is needed. > > thanks, > > Chris > > On 1/2/19 6:51 PM, Jini George wrote: >> Hello! >> >> Requesting reviews for a small fix for fixing the timeout failures of >> the test: ClhsdbInspect.java by increasing the timeout value. >> >> BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 >> Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html >> >> The fix has been tested with about 200 repeated runs on windows post >> this fix. The timeout was not observed. >> >> Thanks, >> Jini. >> >> >> > From jini.george at oracle.com Thu Jan 3 18:45:26 2019 From: jini.george at oracle.com (Jini George) Date: Fri, 4 Jan 2019 00:15:26 +0530 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> Message-ID: <4d9ddbd3-294d-c4ff-8cb4-30685e4d5fa5@oracle.com> Missed mentioning that I think this should be a good number considering that the max I have seen for this test is about 12 minutes and there is a safe buffer of about 20 more minutes. Thanks! Jini. On 1/3/2019 11:56 PM, Jini George wrote: > Thank you very much, Chris, for taking a look. I will modify the timeout > value to be 480 ==> 8 minutes ==> 32 minutes for tier1. Sounds good ? > > Thanks! > Jini. > > On 1/3/2019 9:54 PM, Chris Plummer wrote: >> Hi Jini, >> >> 2400 seems excessive. That's 40 minutes, which translates to 160 >> minutes for our test runs. Did you mean timeout=240? It looks like a >> few of the Clhsdb tests were given large timeouts that are probably >> much more than is needed. >> >> thanks, >> >> Chris >> >> On 1/2/19 6:51 PM, Jini George wrote: >>> Hello! >>> >>> Requesting reviews for a small fix for fixing the timeout failures of >>> the test: ClhsdbInspect.java by increasing the timeout value. >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html >>> >>> The fix has been tested with about 200 repeated runs on windows post >>> this fix. The timeout was not observed. >>> >>> Thanks, >>> Jini. >>> >>> >>> >> From serguei.spitsyn at oracle.com Thu Jan 3 19:28:56 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 3 Jan 2019 11:28:56 -0800 Subject: RFR: JDK-8216059: nsk_jvmti_parseoptions still has dependency on tilde separator In-Reply-To: <884adad4-6b35-9752-6904-fa9b65e5ec93@oracle.com> References: <5C2E0712.90006@oracle.com> <884adad4-6b35-9752-6904-fa9b65e5ec93@oracle.com> Message-ID: <84def46f-8c1e-0a09-6c9b-f180eaa351eb@oracle.com> +1 Thanks, Serguei On 1/3/19 07:31, Chris Plummer wrote: > Looks good. > > Chris > > On 1/3/19 4:58 AM, Gary Adams wrote: >> The test/hotspot/jtreg/vmTestbase/vm/mlvm tests were missed when the >> parser was updated for >> JDK-8211343. Those tests use tilde (~) as an option separator. >> >> Here's a quick fix to add tilde back as an option separator. Testing >> is in progress. >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp >> b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp >> --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp >> +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp >> @@ -221,7 +221,7 @@ >> ???? char *str = NULL; >> ???? char *name = NULL; >> ???? char *value = NULL; >> -??? const char *delimiters = " ,"; >> +??? const char *delimiters = " ,~"; >> ???? if (options == NULL) >> ???????? return success; >> > > From serguei.spitsyn at oracle.com Thu Jan 3 19:28:00 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 3 Jan 2019 11:28:00 -0800 Subject: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms. In-Reply-To: References: <101ecbcd-76c9-2311-04e4-871ca4f3764a@oracle.com> <0176fe1fda7c495582435d2b2a48dbb6@sap.com> <750630a7-63e8-495a-7c9b-54ff50af3c40@oracle.com> <125be3053c0b446ebbca14f84777115c@sap.com> <84ea43c292214d48a0b1a48fcf7ff942@sap.com> Message-ID: <28037e8a-c636-2e76-cd6f-9448f237e23d@oracle.com> An HTML attachment was scrubbed... URL: From leonid.mesnik at oracle.com Thu Jan 3 19:37:34 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 3 Jan 2019 11:37:34 -0800 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> Message-ID: <62733B0A-9757-45C9-8C45-CBFA42901DD3@oracle.com> > On Jan 3, 2019, at 10:26 AM, Jini George wrote: > > Thank you very much, Chris, for taking a look. I will modify the timeout value to be 480 ==> 8 minutes ==> 32 minutes for tier1. Sounds good ? > I think it makes a sense to move this test out of tier1. It takes too long time for tier1. Leonid > Thanks! > Jini. > > On 1/3/2019 9:54 PM, Chris Plummer wrote: >> Hi Jini, >> 2400 seems excessive. That's 40 minutes, which translates to 160 minutes for our test runs. Did you mean timeout=240? It looks like a few of the Clhsdb tests were given large timeouts that are probably much more than is needed. >> thanks, >> Chris >> On 1/2/19 6:51 PM, Jini George wrote: >>> Hello! >>> >>> Requesting reviews for a small fix for fixing the timeout failures of the test: ClhsdbInspect.java by increasing the timeout value. >>> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 >>> Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html >>> >>> The fix has been tested with about 200 repeated runs on windows post this fix. The timeout was not observed. >>> >>> Thanks, >>> Jini. >>> >>> >>> From chris.plummer at oracle.com Thu Jan 3 21:08:34 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 3 Jan 2019 13:08:34 -0800 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: <62733B0A-9757-45C9-8C45-CBFA42901DD3@oracle.com> References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> <62733B0A-9757-45C9-8C45-CBFA42901DD3@oracle.com> Message-ID: <33d2ed71-f47c-842b-d414-d598cce8f901@oracle.com> On 1/3/19 11:37 AM, Leonid Mesnik wrote: > >> On Jan 3, 2019, at 10:26 AM, Jini George wrote: >> >> Thank you very much, Chris, for taking a look. I will modify the timeout value to be 480 ==> 8 minutes ==> 32 minutes for tier1. Sounds good ? >> > I think it makes a sense to move this test out of tier1. It takes too long time for tier1. Agreed. I think changing the timeout to 480 is fine, but this test does run too long for tier1. Chris > > Leonid >> Thanks! >> Jini. >> >> On 1/3/2019 9:54 PM, Chris Plummer wrote: >>> Hi Jini, >>> 2400 seems excessive. That's 40 minutes, which translates to 160 minutes for our test runs. Did you mean timeout=240? It looks like a few of the Clhsdb tests were given large timeouts that are probably much more than is needed. >>> thanks, >>> Chris >>> On 1/2/19 6:51 PM, Jini George wrote: >>>> Hello! >>>> >>>> Requesting reviews for a small fix for fixing the timeout failures of the test: ClhsdbInspect.java by increasing the timeout value. >>>> >>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 >>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html >>>> >>>> The fix has been tested with about 200 repeated runs on windows post this fix. The timeout was not observed. >>>> >>>> Thanks, >>>> Jini. >>>> >>>> >>>> From jini.george at oracle.com Fri Jan 4 01:51:35 2019 From: jini.george at oracle.com (Jini George) Date: Fri, 4 Jan 2019 07:21:35 +0530 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: <33d2ed71-f47c-842b-d414-d598cce8f901@oracle.com> References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> <62733B0A-9757-45C9-8C45-CBFA42901DD3@oracle.com> <33d2ed71-f47c-842b-d414-d598cce8f901@oracle.com> Message-ID: <5c16a29e-b042-c6c9-0452-14147831a3e7@oracle.com> The modified webrev is at: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.01/ I will address the moving the test out of tier1 as a separate defect. Thank you, Jini. On 1/4/2019 2:38 AM, Chris Plummer wrote: > On 1/3/19 11:37 AM, Leonid Mesnik wrote: >> >>> On Jan 3, 2019, at 10:26 AM, Jini George wrote: >>> >>> Thank you very much, Chris, for taking a look. I will modify the >>> timeout value to be 480 ==> 8 minutes ==> 32 minutes for tier1. >>> Sounds good ? >>> >> I think it makes a sense to move this test out of tier1. It takes too >> long time for tier1. > Agreed. I think changing the timeout to 480 is fine, but this test does > run too long for tier1. > > Chris >> >> Leonid >>> Thanks! >>> Jini. >>> >>> On 1/3/2019 9:54 PM, Chris Plummer wrote: >>>> Hi Jini, >>>> 2400 seems excessive. That's 40 minutes, which translates to 160 >>>> minutes for our test runs. Did you mean timeout=240? It looks like a >>>> few of the Clhsdb tests were given large timeouts that are probably >>>> much more than is needed. >>>> thanks, >>>> Chris >>>> On 1/2/19 6:51 PM, Jini George wrote: >>>>> Hello! >>>>> >>>>> Requesting reviews for a small fix for fixing the timeout failures >>>>> of the test: ClhsdbInspect.java by increasing the timeout value. >>>>> >>>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html >>>>> >>>>> The fix has been tested with about 200 repeated runs on windows >>>>> post this fix. The timeout was not observed. >>>>> >>>>> Thanks, >>>>> Jini. >>>>> >>>>> >>>>> > From leonid.mesnik at oracle.com Fri Jan 4 06:48:38 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 3 Jan 2019 22:48:38 -0800 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: <5c16a29e-b042-c6c9-0452-14147831a3e7@oracle.com> References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> <62733B0A-9757-45C9-8C45-CBFA42901DD3@oracle.com> <33d2ed71-f47c-842b-d414-d598cce8f901@oracle.com> <5c16a29e-b042-c6c9-0452-14147831a3e7@oracle.com> Message-ID: Looks good. Leonid > On Jan 3, 2019, at 5:51 PM, Jini George wrote: > > The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8213457/webrev.01/ > > I will address the moving the test out of tier1 as a separate defect. > > Thank you, > Jini. > > On 1/4/2019 2:38 AM, Chris Plummer wrote: >> On 1/3/19 11:37 AM, Leonid Mesnik wrote: >>> >>>> On Jan 3, 2019, at 10:26 AM, Jini George wrote: >>>> >>>> Thank you very much, Chris, for taking a look. I will modify the timeout value to be 480 ==> 8 minutes ==> 32 minutes for tier1. Sounds good ? >>>> >>> I think it makes a sense to move this test out of tier1. It takes too long time for tier1. >> Agreed. I think changing the timeout to 480 is fine, but this test does run too long for tier1. >> Chris >>> >>> Leonid >>>> Thanks! >>>> Jini. >>>> >>>> On 1/3/2019 9:54 PM, Chris Plummer wrote: >>>>> Hi Jini, >>>>> 2400 seems excessive. That's 40 minutes, which translates to 160 minutes for our test runs. Did you mean timeout=240? It looks like a few of the Clhsdb tests were given large timeouts that are probably much more than is needed. >>>>> thanks, >>>>> Chris >>>>> On 1/2/19 6:51 PM, Jini George wrote: >>>>>> Hello! >>>>>> >>>>>> Requesting reviews for a small fix for fixing the timeout failures of the test: ClhsdbInspect.java by increasing the timeout value. >>>>>> >>>>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 >>>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html >>>>>> >>>>>> The fix has been tested with about 200 repeated runs on windows post this fix. The timeout was not observed. >>>>>> >>>>>> Thanks, >>>>>> Jini. >>>>>> >>>>>> >>>>>> From jini.george at oracle.com Fri Jan 4 07:49:08 2019 From: jini.george at oracle.com (Jini George) Date: Fri, 4 Jan 2019 13:19:08 +0530 Subject: RFR: (XS): JDK-8213457: serviceability/sa/ClhsdbInspect.java time out In-Reply-To: References: <00c3cb91-10b2-6da6-4d03-159e5c287b96@oracle.com> <62733B0A-9757-45C9-8C45-CBFA42901DD3@oracle.com> <33d2ed71-f47c-842b-d414-d598cce8f901@oracle.com> <5c16a29e-b042-c6c9-0452-14147831a3e7@oracle.com> Message-ID: <2674a09c-c6dd-de2f-db71-dcd2ec779ffa@oracle.com> Thank you very much, Leonid. - Jini. On 1/4/2019 12:18 PM, Leonid Mesnik wrote: > Looks good. > > Leonid > >> On Jan 3, 2019, at 5:51 PM, Jini George wrote: >> >> The modified webrev is at: >> >> http://cr.openjdk.java.net/~jgeorge/8213457/webrev.01/ >> >> I will address the moving the test out of tier1 as a separate defect. >> >> Thank you, >> Jini. >> >> On 1/4/2019 2:38 AM, Chris Plummer wrote: >>> On 1/3/19 11:37 AM, Leonid Mesnik wrote: >>>> >>>>> On Jan 3, 2019, at 10:26 AM, Jini George wrote: >>>>> >>>>> Thank you very much, Chris, for taking a look. I will modify the timeout value to be 480 ==> 8 minutes ==> 32 minutes for tier1. Sounds good ? >>>>> >>>> I think it makes a sense to move this test out of tier1. It takes too long time for tier1. >>> Agreed. I think changing the timeout to 480 is fine, but this test does run too long for tier1. >>> Chris >>>> >>>> Leonid >>>>> Thanks! >>>>> Jini. >>>>> >>>>> On 1/3/2019 9:54 PM, Chris Plummer wrote: >>>>>> Hi Jini, >>>>>> 2400 seems excessive. That's 40 minutes, which translates to 160 minutes for our test runs. Did you mean timeout=240? It looks like a few of the Clhsdb tests were given large timeouts that are probably much more than is needed. >>>>>> thanks, >>>>>> Chris >>>>>> On 1/2/19 6:51 PM, Jini George wrote: >>>>>>> Hello! >>>>>>> >>>>>>> Requesting reviews for a small fix for fixing the timeout failures of the test: ClhsdbInspect.java by increasing the timeout value. >>>>>>> >>>>>>> BugID: https://bugs.openjdk.java.net/browse/JDK-8213457 >>>>>>> Webrev: http://cr.openjdk.java.net/~jgeorge/8213457/webrev.00/index.html >>>>>>> >>>>>>> The fix has been tested with about 200 repeated runs on windows post this fix. The timeout was not observed. >>>>>>> >>>>>>> Thanks, >>>>>>> Jini. >>>>>>> >>>>>>> >>>>>>> > From zanglin5 at jd.com Mon Jan 7 10:09:52 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Mon, 7 Jan 2019 10:09:52 +0000 Subject: =?gb2312?B?tPC4tDogW1JGUl04MjE1NjIyOiBBZGQgZHVtcCB0byBmaWxlIHN1cHBvcnQg?= =?gb2312?Q?for_jmap_histo?= In-Reply-To: <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> , <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> Message-ID: 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 ?Chisto. It add the ??file=?? arguments that allow jmap ?Chisto 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Mon Jan 7 11:02:05 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Mon, 7 Jan 2019 11:02:05 +0000 Subject: =?gb2312?B?tPC4tDogW1JGUl04MjE1NjIzOiBBZGQgaW5jcmVtZW50YWwgZHVtcCBmb3Ig?= =?gb2312?Q?jmap_histo?= In-Reply-To: <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> References: <66546343ae324ab28bb54951ad774a89@jd.com>, <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> Message-ID: <0aa27238065e4b3f97887b82ec1a30bd@jd.com> Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ??????: Hohensee, Paul ????????: 2019??1??1?? 4:56 ??????: ????; serviceability-dev at openjdk.java.net ????: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won??t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ??incremental?? could become ??chunkcount=??, where defaults to infinity (max value of size_t). I??d not use a default file name when ??chunkcount?? is specified, I??d just write to whatever the output stream is. ??chunkcount?? is then independent of ??file??. I??d add another histo argument for the maximum file size, call it ??maxfilesize??, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ??incremental?? argument as syntactic sugar for ??chunkcount=8k,maxfilesize=5m??. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ??const int?? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev on behalf of ???? Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net" Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?Chisto. It adds the ??incremental?? arguments that allow jmap ?Chisto to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. 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/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Mon Jan 7 11:14:10 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Mon, 7 Jan 2019 11:14:10 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <0aa27238065e4b3f97887b82ec1a30bd@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com>, <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> Message-ID: <808c7521374449eb855d0ace87c38b6c@jd.com> And another way is to add a argument ??IncrementalFile=??,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ??out??. What do you think? Thanks, Lin From: ???? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul ; serviceability-dev at openjdk.java.net Subject: ????: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ??????: Hohensee, Paul > ????????: 2019??1??1?? 4:56 ??????: ????; serviceability-dev at openjdk.java.net ????: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won??t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ??incremental?? could become ??chunkcount=??, where defaults to infinity (max value of size_t). I??d not use a default file name when ??chunkcount?? is specified, I??d just write to whatever the output stream is. ??chunkcount?? is then independent of ??file??. I??d add another histo argument for the maximum file size, call it ??maxfilesize??, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ??incremental?? argument as syntactic sugar for ??chunkcount=8k,maxfilesize=5m??. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ??const int?? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev > on behalf of ???? > Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net" > Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?Chisto. It adds the ??incremental?? arguments that allow jmap ?Chisto to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. 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/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Mon Jan 7 16:30:25 2019 From: jini.george at oracle.com (Jini George) Date: Mon, 7 Jan 2019 22:00:25 +0530 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> Message-ID: Gentle reminder ! Thanks, Jini. On 1/3/2019 11:46 PM, Jini George wrote: > Hello! > > Requesting reviews for: > > https://bugs.openjdk.java.net/browse/JDK-8215544 > Webrev: http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/index.html > > The changes here are primarily for modifying the ClhsdbLauncher used for > SA tests to check if 'sudo' privileges can be added for executing MacOS > tests, and if so, adding these privileges before executing the tests. > This is related to the changes which were proposed with: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024373.html > > > for (JDK-8199700: SA: Enable jhsdb jtreg tests for Mac OS X). > > The issue brought out with the proposed changes for JDK-8199700 have > been fixed. This patch addresses the case where 'sudo' fails with errors > like: > > sudo: no tty present and no askpass program specified > ?or > sudo: a password is required > > or if 'sudo' waits for a password. In these cases, the tests continue to > get skipped. > > Many thanks to Goetz Lindenmaier for helping me with multiple rounds of > testing of this in the SAP test farms! With this patch, about 22 SA > tests get enabled now on MacOS on Mach5. > > More details at: https://bugs.openjdk.java.net/browse/JDK-8215544 > > Thanks, > Jini. From jcbeyler at google.com Mon Jan 7 18:32:05 2019 From: jcbeyler at google.com (JC Beyler) Date: Mon, 7 Jan 2019 10:32:05 -0800 Subject: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions In-Reply-To: <5C1CEBAD.1080601@oracle.com> References: <5C1B96B6.1040002@oracle.com> <5C1BC44D.9030305@oracle.com> <55bef8f2-08e5-1e43-0960-485b1ffb064e@oracle.com> <5C1CEBAD.1080601@oracle.com> Message-ID: Hi Gary, My only comment here is that it seems to that the delimiter list you have there is not complete (or backwards compatible). The original code uses: int isOptSep(char c) { return isspace(c) || c == '~'; } So perhaps the delimiter list you are providing should be augmented to support that? Thanks, Jc On Fri, Dec 21, 2018 at 5:31 AM Gary Adams wrote: > My intention is to establish a more robust argument parsing > and then see how much code and comments can be replaced. > > Since strsep is BSD based and not available on windows, > an alternative is to use strpbrk which is on windows and > posix. > > #include > #include > > char* token(char **s, char *delim) { > char *p; > char *start = *s; > > if (s == NULL || *s == NULL) { > return NULL; > } > > p = strpbrk(*s, delim); > if (p != NULL) { > /* Advance to next token. */ > *p = '\0'; > *s = p + 1; > } else { > /* End of tokens. */ > *s = NULL; > } > > return start; > } > > > int main(int argc, char **argv){ > char *str = strdup("waittime=5,verbose foo bar= = =rab baz=11"); > char *name; > char *value; > > while ((name = token(&str, " ,")) != NULL) { > value = index(name, '='); > > if (value == NULL) { > printf ("%s\n", name); > } else { > *value++ = '\0'; > printf ("%s=%s\n", name, value); > } > } > } > > ... > > ./main > waittime=5 > verbose > foo > bar= > = > =rab > baz=11 > > > > > > On 12/20/18, 12:10 PM, Chris Plummer wrote: > > Wow, the existing comments for this function take a lot of work to > translate. You basically need to understand the code in order to understand > the comment. Kind of backwards. Below I've included all the existing code > and comments, with my translation of the comments and also additional > annotations. > > But before getting into that, I think the proposed fix is just working > around all the bugs elsewhere in the function by making opt point to a > string that just contains the current option we are working on, rather than > attempting (poorly and incorrectly) to point to the next option within the > options string. Although tokenizing the string in this way is probably the > better approach, it would be nice to at the same time clean up all the > other errors and comments in this code. > > /** > * > * The current option will not perform more than one > * single option which given, this is due to places explained > * in this question. > * > **/ > > # This current implementation will not parse more than one option. The > # reason is explained in comments below. > > /* > * This whole play can be reduced with simple StringTokenizer (strtok). > * > */ > > # This function can be simplified by using strok(). > > int nsk_jvmti_parseOptions(const char options[]) { > size_t len; > const char* opt; > int success = NSK_TRUE; > > context.options.string = NULL; > context.options.count = 0; > context.waittime = 2; > > if (options == NULL) > return NSK_TRUE; > > len = strlen(options); > context.options.string = (char*)malloc(len + 2); > > if (context.options.string == NULL) { > nsk_complain("nsk_jvmti_parseOptions(): out of memory\n"); > return NSK_FALSE; > } > strncpy(context.options.string, options, len); > context.options.string[len] = '\0'; > context.options.string[len+1] = '\0'; > > for (opt = context.options.string; ;) { > const char* opt_end; > const char* val_sep; > int opt_len=0; > int val_len=0; > int exit=1; > > while (*opt != '\0' && isOptSep(*opt)) opt++; > if (*opt == '\0') break; > > val_sep = NULL; > /* > This should break when the first option it encounters other > wise > */ > # This should break at the end of the first option, before the option > value is specified > # if there is an option value. > for (opt_end = opt, opt_len=0; !(*opt_end == '\0' || > isOptSep(*opt_end)); opt_end++,opt_len++) { > if (*opt_end == NSK_JVMTI_OPTION_VAL_SEP) { > val_sep = opt_end; > exit=0; > break; > } > } > > if (exit == 1) break; > > /* now scan for the search for the option value end. > > */ > # Now scan for the end of the option value. > [Chris: This is a bug because it assumes that there is a value. If we > stopped in the above > loop due to finding the option separator (which also seems to be broken), > then we start > reading the next option as the option value.] > exit =1; > opt_end++; > val_sep++; > /** > * I was expecting this jvmti_parseOptions(), > * should be for multiple options as well. > * If this break is not there then It will expects > * to have. so a space should be sufficient as well. > */ > # I was expecting that nsk_jvmti_parseOptions() would parse multiple > options. > [Chris: I have no idea what the rest of the comment means. Due to the bug > above > with handling an option with no value, the code below doesn't do what was > expected. > The commented out part of it tried to do the right thing by searching for > the '-' for the > next option, whichis wrong because options don't begin with a '\'. They > are separated > by a comma, although the code elsewhere wants them separated by a space or > a `~`.] > for (val_len=0; !(*opt_end == '\0' || isOptSep(*opt_end)); > opt_end++,val_len++) { > //if (*opt_end == NSK_JVMTI_OPTION_START) { > // break; > //} > } > > if (!add_option(opt, opt_len, val_sep, val_len)) { > success = NSK_FALSE; > break; > } > opt_end++; > opt = opt_end; > } > > > On 12/20/18 8:33 AM, Gary Adams wrote: > > I prototyped with strsep, because strtok is not safe > and did not want to deal with the strtok_r versus > strtok_s (windows) platform variants. > > ... > #include > #include > > int main(int argc, char **argv){ > char *str = strdup("waittime=5,verbose foo bar baz=11"); > char *name; > char *value; > > while ((name = strsep (&str, " ,")) != NULL) { > value = index(name, '='); > > if (value == NULL) { > printf ("%s\n", name); > } else { > *value++ = '\0'; > printf ("%s=%s\n", name, value); > } > } > > ... > > ./main > waittime=5 > verbose > foo > bar > baz=11 > > > On 12/20/18, 10:54 AM, JC Beyler wrote: > > Hi Gary, > > I had seen that too and forgot to file it! So thanks! > > I think the comment you removed is interesting, I'm not sure what it means > exactly and I've tried re-reading a few times but the use of "in this > question" is weird :-) > > Anyway, the webrev looks good except perhaps for the use of strsep, which > is BSD, instead of strtok, which is C89/C99/Posix. > > Thanks for doing this! > Jc > > On Thu, Dec 20, 2018 at 5:17 AM Gary Adams wrote: > > During some earlier jvmti test debugging, I noticed that it was not > possible to > add a quick argument to the current tests and rerun the test. e.g. > expand "waittime=5" to > "waittime=5,verbose". I tracked down the options parsing in > jvmti_tools.cpp and saw some > comments that only a single option could be parsed. > > So I filed this bug to revisit the issue for the next release: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8211343 > > I think the option parsing should be ripped out and redone, > but for now I think a simple tweak to use strsep(), might go a long way > to solving the multiple option support. I just started testing, > but wanted to know if anyone else has been down this rabbit hole > before. > > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp > b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp > --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp > +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp > @@ -196,22 +196,14 @@ > } > > > -/** > - * > - * The current option will not perform more than one > - * single option which given, this is due to places explained > - * in this question. > - * > - **/ > - > /* > - * This whole play can be reduced with simple StringTokenizer (strtok). > - * > + * Parse a comma or space separated list of options. > */ > > int nsk_jvmti_parseOptions(const char options[]) { > size_t len; > const char* opt; > + char *str = strdup(options); > int success = NSK_TRUE; > > context.options.string = NULL; > @@ -232,7 +224,7 @@ > context.options.string[len] = '\0'; > context.options.string[len+1] = '\0'; > > - for (opt = context.options.string; ;) { > + while ((opt = strsep(&str, " ,")) != NULL) { > const char* opt_end; > const char* val_sep; > int opt_len=0; > > > > -- > > Thanks, > Jc > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Jan 7 18:42:40 2019 From: jcbeyler at google.com (JC Beyler) Date: Mon, 7 Jan 2019 10:42:40 -0800 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Mon Jan 7 18:51:42 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 7 Jan 2019 13:51:42 -0500 Subject: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions In-Reply-To: References: <5C1B96B6.1040002@oracle.com> <5C1BC44D.9030305@oracle.com> <55bef8f2-08e5-1e43-0960-485b1ffb064e@oracle.com> <5C1CEBAD.1080601@oracle.com> Message-ID: Please see: JDK-8216059 nsk_jvmti_parseoptions still has dependency on tilde separator https://bugs.openjdk.java.net/browse/JDK-8216059 Dan On 1/7/19 1:32 PM, JC Beyler wrote: > Hi Gary, > > My only comment here is that it seems to that the delimiter list you > have there is not complete (or backwards compatible). The original > code uses: > int isOptSep(char c) { > ? ? return isspace(c) || c == '~'; > } > > So perhaps the delimiter list you are providing should be augmented to > support that? > > Thanks, > Jc > > On Fri, Dec 21, 2018 at 5:31 AM Gary Adams > wrote: > > My intention is to establish a more robust argument parsing > and then see how much code and comments can be replaced. > > Since strsep is BSD based and not available on windows, > an alternative is to use strpbrk which is on windows and > posix. > > #include > #include > > char* token(char **s, char *delim) { > ? char *p; > ? char *start = *s; > > ? if (s == NULL || *s == NULL) { > ??? return NULL; > ? } > > ? p = strpbrk(*s, delim); > ? if (p != NULL) { > ??? /* Advance to next token. */ > ??? *p = '\0'; > ??? *s = p + 1; > ? } else { > ??? /* End of tokens. */ > ??? *s = NULL; > ? } > > ? return start; > } > > > int? main(int argc, char **argv){ > ? char *str = strdup("waittime=5,verbose foo bar= = =rab baz=11"); > ? char *name; > ? char *value; > > ? while ((name = token(&str, " ,")) != NULL) { > ??? value = index(name, '='); > > ??? if (value == NULL) { > ????? printf ("%s\n", name); > ??? } else { > ????? *value++ = '\0'; > ????? printf ("%s=%s\n", name, value); > ??? } > ? } > } > > ... > > ./main > waittime=5 > verbose > foo > bar= > = > =rab > baz=11 > > > > > > On 12/20/18, 12:10 PM, Chris Plummer wrote: >> Wow, the existing comments for this function take a lot of work >> to translate. You basically need to understand the code in order >> to understand the comment. Kind of backwards. Below I've included >> all the existing code and comments, with my translation of the >> comments and also additional annotations. >> >> But before getting into that, I think the proposed fix is just >> working around all the bugs elsewhere in the function by making >> opt point to a string that just contains the current option we >> are working on, rather than attempting (poorly and incorrectly) >> to point to the next option within the options string. Although >> tokenizing the string in this way is probably the better >> approach, it would be nice to at the same time clean up all the >> other errors and comments in this code. >> >> /** >> ?* >> ?* The current option will not perform more than one >> ?* single option which given, this is due to places explained >> ?* in this question. >> ?* >> ?**/ >> >> # This current implementation will not parse more than one >> option. The >> # reason is explained in comments below. >> >> ?/* >> ? * This whole play can be reduced with simple StringTokenizer >> (strtok). >> ? * >> ? */ >> >> # This function can be simplified by using strok(). >> >> int nsk_jvmti_parseOptions(const char options[]) { >> ??? size_t len; >> ??? const char* opt; >> ??? int success = NSK_TRUE; >> >> ??? context.options.string = NULL; >> ??? context.options.count = 0; >> ??? context.waittime = 2; >> >> ??? if (options == NULL) >> ??????? return NSK_TRUE; >> >> ??? len = strlen(options); >> ??? context.options.string = (char*)malloc(len + 2); >> >> ??? if (context.options.string == NULL) { >> ??????????? nsk_complain("nsk_jvmti_parseOptions(): out of >> memory\n"); >> ??????????? return NSK_FALSE; >> ??? } >> ??? strncpy(context.options.string, options, len); >> ??? context.options.string[len] = '\0'; >> ??? context.options.string[len+1] = '\0'; >> >> ??? for (opt = context.options.string; ;) { >> ??????? const char* opt_end; >> ??????? const char* val_sep; >> ??????? int opt_len=0; >> ??????? int val_len=0; >> ??????? int exit=1; >> >> ??????? while (*opt != '\0' && isOptSep(*opt)) opt++; >> ??????? if (*opt == '\0') break; >> >> ??????? val_sep = NULL; >> ??????? /* >> ??????????? This should break when the first option it encounters >> other wise >> ??????? */ >> # This should break at the end of the first option, before the >> option value is specified >> # if there is an option value. >> ??????? for (opt_end = opt, opt_len=0; !(*opt_end == '\0' || >> isOptSep(*opt_end)); opt_end++,opt_len++) { >> ??????????? if (*opt_end == NSK_JVMTI_OPTION_VAL_SEP) { >> ??????????????? val_sep = opt_end; >> ??????????????? exit=0; >> ??????????????? break; >> ??????????? } >> ??????? } >> >> ??????? if (exit == 1) break; >> >> ??????? /* now scan for the search? for the option value end. >> >> ??????? */ >> # Now scan for the end of the option value. >> [Chris: This is a bug because it assumes that there is a value. >> If we stopped in the above >> loop due to finding the option separator (which also seems to be >> broken), then we start >> reading the next option as the option value.] >> ??????? exit =1; >> ??????? opt_end++; >> ??????? val_sep++; >> ??????? /** >> ???????? * I was expecting this jvmti_parseOptions(), >> ???????? * should be for multiple options as well. >> ???????? * If this break is not there then It will expects >> ???????? * to have. so a space should be sufficient as well. >> ???????? */ >> # I was expecting that nsk_jvmti_parseOptions() would parse >> multiple options. >> [Chris: I have no idea what the rest of the comment means. Due to >> the bug above >> with handling an option with no value, the code below doesn't do >> what was expected. >> The commented out part of it tried to do the right thing by >> searching for the '-' for the >> next option, whichis wrong because options don't begin with a >> '\'. They are separated >> by a comma, although the code elsewhere wants them separated by a >> space or a `~`.] >> ??????? for (val_len=0; !(*opt_end == '\0' || >> isOptSep(*opt_end)); opt_end++,val_len++) { >> ??????????? //if (*opt_end == NSK_JVMTI_OPTION_START) { >> ??????????? //??? break; >> ??????????? //} >> ??????? } >> >> ??????? if (!add_option(opt, opt_len, val_sep, val_len)) { >> ??????????? success = NSK_FALSE; >> ??????????? break; >> ??????? } >> ??????? opt_end++; >> ??????? opt = opt_end; >> ??? } >> >> >> On 12/20/18 8:33 AM, Gary Adams wrote: >>> I prototyped with strsep, because strtok is not safe >>> and did not want to deal with the strtok_r versus >>> strtok_s (windows) platform variants. >>> >>> ... >>> #include >>> #include >>> >>> int? main(int argc, char **argv){ >>> ? char *str = strdup("waittime=5,verbose foo bar baz=11"); >>> ? char *name; >>> ? char *value; >>> >>> ? while ((name = strsep (&str, " ,")) != NULL) { >>> ??? value = index(name, '='); >>> >>> ??? if (value == NULL) { >>> ????? printf ("%s\n", name); >>> ??? } else { >>> ????? *value++ = '\0'; >>> ????? printf ("%s=%s\n", name, value); >>> ??? } >>> ? } >>> >>> ... >>> >>> ./main >>> waittime=5 >>> verbose >>> foo >>> bar >>> baz=11 >>> >>> >>> On 12/20/18, 10:54 AM, JC Beyler wrote: >>>> Hi Gary, >>>> >>>> I had seen that too and forgot to file it! So thanks! >>>> >>>> I think the comment you removed is interesting, I'm not sure >>>> what it means exactly and I've tried re-reading a few times but >>>> the use of "in this question"? is weird :-) >>>> >>>> Anyway, the webrev looks good except perhaps for the use of >>>> strsep, which is BSD, instead of strtok, which is C89/C99/Posix. >>>> >>>> Thanks for doing this! >>>> Jc >>>> >>>> On Thu, Dec 20, 2018 at 5:17 AM Gary Adams >>>> > wrote: >>>> >>>> During some earlier jvmti test debugging, I noticed that it >>>> was not >>>> possible to >>>> add a quick argument to the current tests and rerun the >>>> test. e.g. >>>> expand "waittime=5" to >>>> "waittime=5,verbose". I tracked down the options parsing in >>>> jvmti_tools.cpp and saw some >>>> comments that only a single option could be parsed. >>>> >>>> So I filed this bug to revisit the issue for the next release: >>>> >>>> ? ?Issue: https://bugs.openjdk.java.net/browse/JDK-8211343 >>>> >>>> I think the option parsing should be ripped out and redone, >>>> but for now I think a simple tweak to use strsep(), might >>>> go a long way >>>> to solving the multiple option support. I just started testing, >>>> but wanted to know if anyone else has been down this rabbit >>>> hole >>>> before. >>>> >>>> >>>> diff --git >>>> a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp >>>> >>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp >>>> --- >>>> a/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp >>>> +++ >>>> b/test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp >>>> @@ -196,22 +196,14 @@ >>>> ? } >>>> >>>> >>>> -/** >>>> - * >>>> - * The current option will not perform more than one >>>> - * single option which given, this is due to places explained >>>> - * in this question. >>>> - * >>>> - **/ >>>> - >>>> ? ?/* >>>> -? * This whole play can be reduced with simple >>>> StringTokenizer (strtok). >>>> -? * >>>> +? ?* Parse a comma or space separated list of options. >>>> ? ? */ >>>> >>>> ? int nsk_jvmti_parseOptions(const char options[]) { >>>> ? ? ? size_t len; >>>> ? ? ? const char* opt; >>>> +? ? char *str = strdup(options); >>>> ? ? ? int success = NSK_TRUE; >>>> >>>> ? ? ? context.options.string = NULL; >>>> @@ -232,7 +224,7 @@ >>>> ? ? ? context.options.string[len] = '\0'; >>>> ? ? ? context.options.string[len+1] = '\0'; >>>> >>>> -? ? for (opt = context.options.string; ;) { >>>> +? ? while ((opt = strsep(&str, " ,")) != NULL) { >>>> ? ? ? ? ? const char* opt_end; >>>> ? ? ? ? ? const char* val_sep; >>>> ? ? ? ? ? int opt_len=0; >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >> > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon Jan 7 18:52:30 2019 From: jcbeyler at google.com (JC Beyler) Date: Mon, 7 Jan 2019 10:52:30 -0800 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> Message-ID: Hi Jini, It looks good to me but I have a few nits: http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html + // by appending 'sudo' to it. Check now if sudo passes in this + // environment with a simple 'echo' command. -> Really shouldn't provide implementation details about what is being done by that method; if we change that, this comment will rot :-) canAddPrivileges is explicit enough in my mind http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/test/lib/SA/SATestUtils.java.html -> You put some System.out.println; are they intended to still be there or were they for debug? 77 for (String val: cmdStringList) { 78 outStringList.add(val); 79 } Couldn't we use addAll ? Thanks, Jc On Mon, Jan 7, 2019 at 8:33 AM Jini George wrote: > Gentle reminder ! > > Thanks, > Jini. > > On 1/3/2019 11:46 PM, Jini George wrote: > > Hello! > > > > Requesting reviews for: > > > > https://bugs.openjdk.java.net/browse/JDK-8215544 > > Webrev: http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/index.html > > > > The changes here are primarily for modifying the ClhsdbLauncher used for > > SA tests to check if 'sudo' privileges can be added for executing MacOS > > tests, and if so, adding these privileges before executing the tests. > > This is related to the changes which were proposed with: > > > > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-July/024373.html > > > > > > for (JDK-8199700: SA: Enable jhsdb jtreg tests for Mac OS X). > > > > The issue brought out with the proposed changes for JDK-8199700 have > > been fixed. This patch addresses the case where 'sudo' fails with errors > > like: > > > > sudo: no tty present and no askpass program specified > > or > > sudo: a password is required > > > > or if 'sudo' waits for a password. In these cases, the tests continue to > > get skipped. > > > > Many thanks to Goetz Lindenmaier for helping me with multiple rounds of > > testing of this in the SAP test farms! With this patch, about 22 SA > > tests get enabled now on MacOS on Mach5. > > > > More details at: https://bugs.openjdk.java.net/browse/JDK-8215544 > > > > Thanks, > > Jini. > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Tue Jan 8 16:32:48 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 08 Jan 2019 11:32:48 -0500 Subject: RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out Message-ID: <5C34D0B0.3060709@oracle.com> A number failures of threadstart002 have been reported on windows-x64-debug builds. This configuration has a jtreg timeout factor assigned so the test can run 10x slower and not experience a timeout. Unfortunately, these older vmTestbase tests were not fully integrated with the jtreg timeout and factor capabilities. This test in particular uses a 2 second timeout when monitoring transitions between starting a thread and the check for the thread being resumed. This hard coded timeout is not scaled. As a quick workaround the timeout can be scaled up to allow 20 second window, as if the scaling factor had been applied as jtreg harness intended. Issue: https://bugs.openjdk.java.net/browse/JDK-8213001 diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp @@ -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 @@ -34,7 +34,7 @@ #define PASSED 0 #define STATUS_FAILED 2 -#define WAIT_TIME 2000 +#define WAIT_TIME 20000 static jvmtiEnv *jvmti = NULL; static jvmtiCapabilities caps; From jini.george at oracle.com Tue Jan 8 17:06:49 2019 From: jini.george at oracle.com (Jini George) Date: Tue, 8 Jan 2019 22:36:49 +0530 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> Message-ID: 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 jcbeyler at google.com Tue Jan 8 17:13:43 2019 From: jcbeyler at google.com (JC Beyler) Date: Tue, 8 Jan 2019 09:13:43 -0800 Subject: RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out In-Reply-To: <5C34D0B0.3060709@oracle.com> References: <5C34D0B0.3060709@oracle.com> Message-ID: Hi Gary, Looks good to me, is there a bug to track that we might want to modernize the timeouts for these tests? Thanks, Jc On Tue, Jan 8, 2019 at 8:30 AM Gary Adams wrote: > A number failures of threadstart002 have been reported on > windows-x64-debug builds. > > This configuration has a jtreg timeout factor assigned so the test can > run 10x slower > and not experience a timeout. > > Unfortunately, these older vmTestbase tests were not fully integrated > with the jtreg > timeout and factor capabilities. > > This test in particular uses a 2 second timeout when monitoring transitions > between starting a thread and the check for the thread being resumed. > This hard coded timeout is not scaled. > > As a quick workaround the timeout can be scaled up to allow 20 second > window, > as if the scaling factor had been applied as jtreg harness intended. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8213001 > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > > > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > --- > > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > +++ > > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > @@ -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 > @@ -34,7 +34,7 @@ > > #define PASSED 0 > #define STATUS_FAILED 2 > -#define WAIT_TIME 2000 > +#define WAIT_TIME 20000 > > static jvmtiEnv *jvmti = NULL; > static jvmtiCapabilities caps; > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.thompson at oracle.com Tue Jan 8 17:17:24 2019 From: martin.thompson at oracle.com (Marty Thompson) Date: Tue, 8 Jan 2019 09:17:24 -0800 (PST) Subject: RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out In-Reply-To: References: <5C34D0B0.3060709@oracle.com> Message-ID: <819907e1-1520-423c-95ad-46b4218a57f9@default> Hi JC, ? I believe that?s covered by https://bugs.openjdk.java.net/browse/JDK-8206013. ? Regards, ? Marty ? From: JC Beyler Sent: Tuesday, January 8, 2019 9:14 AM To: Gary Adams Cc: OpenJDK Serviceability Subject: Re: RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out ? Hi Gary, ? Looks good to me, is there a bug to track that we might want to modernize the timeouts for these tests? ? Thanks, Jc ? On Tue, Jan 8, 2019 at 8:30 AM Gary Adams wrote: A number failures of threadstart002 have been reported on windows-x64-debug builds. This configuration has a jtreg timeout factor assigned so the test can run 10x slower and not experience a timeout. Unfortunately, these older vmTestbase tests were not fully integrated with the jtreg timeout and factor capabilities. This test in particular uses a 2 second timeout when monitoring transitions between starting a thread and the check for the thread being resumed. This hard coded timeout is not scaled. As a quick workaround the timeout can be scaled up to allow 20 second window, as if the scaling factor had been applied as jtreg harness intended. ? ?Issue: https://bugs.openjdk.java.net/browse/JDK-8213001 diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp --- a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp +++ b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp @@ -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 @@ -34,7 +34,7 @@ ? #define PASSED 0 ? #define STATUS_FAILED 2 -#define WAIT_TIME 2000 +#define WAIT_TIME 20000 ? static jvmtiEnv *jvmti = NULL; ? static jvmtiCapabilities caps; ? -- ? Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Jan 8 17:42:01 2019 From: jcbeyler at google.com (JC Beyler) Date: Tue, 8 Jan 2019 09:42:01 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> Message-ID: 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" < > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue Jan 8 17:42:43 2019 From: jcbeyler at google.com (JC Beyler) Date: Tue, 8 Jan 2019 09:42:43 -0800 Subject: RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out In-Reply-To: <819907e1-1520-423c-95ad-46b4218a57f9@default> References: <5C34D0B0.3060709@oracle.com> <819907e1-1520-423c-95ad-46b4218a57f9@default> Message-ID: Hi Marty, Thanks :-) Perfect! Jc On Tue, Jan 8, 2019 at 9:17 AM Marty Thompson wrote: > Hi JC, > > > > I believe that?s covered by > https://bugs.openjdk.java.net/browse/JDK-8206013. > > > > Regards, > > > > Marty > > > > *From:* JC Beyler > *Sent:* Tuesday, January 8, 2019 9:14 AM > *To:* Gary Adams > *Cc:* OpenJDK Serviceability > *Subject:* Re: RFR: JDK-8213001: > vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug > agent times out > > > > Hi Gary, > > > > Looks good to me, is there a bug to track that we might want to modernize > the timeouts for these tests? > > > > Thanks, > > Jc > > > > On Tue, Jan 8, 2019 at 8:30 AM Gary Adams wrote: > > A number failures of threadstart002 have been reported on > windows-x64-debug builds. > > This configuration has a jtreg timeout factor assigned so the test can > run 10x slower > and not experience a timeout. > > Unfortunately, these older vmTestbase tests were not fully integrated > with the jtreg > timeout and factor capabilities. > > This test in particular uses a 2 second timeout when monitoring transitions > between starting a thread and the check for the thread being resumed. > This hard coded timeout is not scaled. > > As a quick workaround the timeout can be scaled up to allow 20 second > window, > as if the scaling factor had been applied as jtreg harness intended. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8213001 > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > > > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > --- > > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > +++ > > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > @@ -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 > @@ -34,7 +34,7 @@ > > #define PASSED 0 > #define STATUS_FAILED 2 > -#define WAIT_TIME 2000 > +#define WAIT_TIME 20000 > > static jvmtiEnv *jvmti = NULL; > static jvmtiCapabilities caps; > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Wed Jan 9 01:23:06 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 Jan 2019 10:23:06 +0900 Subject: RFR: 8181313: SA: Remove libthread_db dependency on Linux Message-ID: Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8181313 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.00/ It has passed all tests on submit repo, and serviceability/sa tests on Linux x64. Thanks, Yasumas From zanglin5 at jd.com Wed Jan 9 01:46:55 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Wed, 9 Jan 2019 01:46:55 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo References: <66546343ae324ab28bb54951ad774a89@jd.com>, <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> Message-ID: Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ???? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul ; serviceability-dev at openjdk.java.net; ???? Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ??IncrementalFile=??,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ??out??. What do you think? Thanks, Lin From: ???? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: ????: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ??????: Hohensee, Paul > ????????: 2019??1??1?? 4:56 ??????: ????; serviceability-dev at openjdk.java.net ????: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won??t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ??incremental?? could become ??chunkcount=??, where defaults to infinity (max value of size_t). I??d not use a default file name when ??chunkcount?? is specified, I??d just write to whatever the output stream is. ??chunkcount?? is then independent of ??file??. I??d add another histo argument for the maximum file size, call it ??maxfilesize??, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ??incremental?? argument as syntactic sugar for ??chunkcount=8k,maxfilesize=5m??. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ??const int?? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev > on behalf of ???? > Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net" > Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?Chisto. It adds the ??incremental?? arguments that allow jmap ?Chisto to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. 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/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jan 9 02:05:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Jan 2019 12:05:52 +1000 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: <0B661A5C-E59D-481C-BC3B-0951621F1F51@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> Message-ID: <5e9c223c-71c5-980e-03b9-679e69942f23@oracle.com> 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" 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" 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 zanglin5 at jd.com Wed Jan 9 02:22:57 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Wed, 9 Jan 2019 02:22:57 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> Message-ID: <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> 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? 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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Jan 9 02:50:42 2019 From: jcbeyler at google.com (JC Beyler) Date: Tue, 8 Jan 2019 18:50:42 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> Message-ID: 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" < > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Wed Jan 9 02:59:32 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Wed, 9 Jan 2019 02:59:32 +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> Message-ID: <3dc434fec6c44ce69b80f8cdab450250@jd.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed Jan 9 02:59:54 2019 From: jcbeyler at google.com (JC Beyler) Date: Tue, 8 Jan 2019 18:59:54 -0800 Subject: RFR (S) 8212824: Remove unnecessary spaces before/after comparison in vmTestbase Message-ID: Hi all, Could I get a review for a small-ish webrev that only changes white-spaces (or removes unnecessary new lines): Bug: https://bugs.openjdk.java.net/browse/JDK-8212824 Webrev: http://cr.openjdk.java.net/~jcbeyler/8212824/webrev.00/ Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Wed Jan 9 04:11:11 2019 From: jini.george at oracle.com (Jini George) Date: Wed, 9 Jan 2019 09:41:11 +0530 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> Message-ID: <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> Thank you very much for the review, JC. My comments inline: On 1/8/2019 12:22 AM, JC Beyler wrote: > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html > ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check now if sudo > passes in this > ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' command. > ? ? ?-> Really shouldn't provide implementation details about what is > being done by that method; if we change that, this comment will rot :-) > canAddPrivileges is explicit enough in my mind Done. I have removed the comment. > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/test/lib/SA/SATestUtils.java.html > > ? ? -> You put some System.out.println; are they intended to still be > there or were they for debug? I guess you meant this one: System.out.println("Adding 'sudo -E' to the command."); This one is meant to be there. > > > 77 for (String val: cmdStringList) { > 78 outStringList.add(val); > 79 } > > > Couldn't we use addAll ? Done. The modified webrev is at: http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html Thanks, Jini. From jcbeyler at google.com Wed Jan 9 06:12:02 2019 From: jcbeyler at google.com (JC Beyler) Date: Tue, 8 Jan 2019 22:12:02 -0800 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase Message-ID: Hi all, Fixing up the tests in vmTestbase to not be testing explicitly against NSK_TRUE/NSK_FALSE. Here is the webrev to do that: Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 Webrev: http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jan 9 06:31:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Jan 2019 16:31:12 +1000 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: References: Message-ID: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> Hi Jc, On 9/01/2019 4:12 pm, JC Beyler wrote: > Hi all, > > Fixing up the tests in vmTestbase to not be testing explicitly against > NSK_TRUE/NSK_FALSE. Here is the webrev to do that: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ Hold up! We don't do explicit tests when the variable is a bool/boolean but when it is an int, as here, we do. Are you planning on converting everything to use bool? Cheers, David > Thanks, > Jc From jcbeyler at google.com Wed Jan 9 06:43:41 2019 From: jcbeyler at google.com (JC Beyler) Date: Tue, 8 Jan 2019 22:43:41 -0800 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> References: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> Message-ID: Hi David, I was not planning on doing it but we could. This change came from a request to remove the booleans from tests for a prior webrev change. I've seen previous conversations about wanting to test explicitly against JNI_TRUE but thought this was a slightly different case. Basically, from your comment, it seems I could go three ways for this change: 1) Not do it and close the bug as won't fix :-) 2) Go the extra step and change the various variables being tested to bool My preference is to do (2) as much as possible; any case that cannot be put in a boolean form without having major changes to the code base, I'd leave as is. And then call it a day for this subject. What do you think (ie in cases where the variable can be set to a bool, do it and then have the test be an implicit test)? Thanks! Jc On Tue, Jan 8, 2019 at 10:31 PM David Holmes wrote: > Hi Jc, > > On 9/01/2019 4:12 pm, JC Beyler wrote: > > Hi all, > > > > Fixing up the tests in vmTestbase to not be testing explicitly against > > NSK_TRUE/NSK_FALSE. Here is the webrev to do that: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ > > Hold up! We don't do explicit tests when the variable is a bool/boolean > but when it is an int, as here, we do. > > Are you planning on converting everything to use bool? > > Cheers, > David > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed Jan 9 07:14:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Jan 2019 17:14:26 +1000 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: References: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> Message-ID: <50b8c141-860e-6787-d9d8-e2ab79392ce8@oracle.com> On 9/01/2019 4:43 pm, JC Beyler wrote: > Hi David, > > I was not planning on doing it but we could. This change came from a > request to remove the booleans from tests for a prior webrev change. > I've seen previous conversations about wanting to test explicitly > against JNI_TRUE but thought this was a slightly different case. The basic hotspot style rule is "avoid implicit booleans". > Basically, from your comment, it seems I could go three ways for this > change: > ? 1) Not do it and close the bug as won't fix :-) Certainly the path of least resistance. :) > ? 2) Go the extra step and change the various variables being tested to > bool > > My preference is to do (2) as much as possible; any case that cannot be > put in a boolean form without having major changes to the code base, I'd > leave as is. And then call it a day for this subject. > > What do you think (ie in cases where the variable can be set to a bool, > do it and then have the test be an implicit test)? It's really up to you. It seems a lot of work and I don't know if you can actually push this all the way through without needing some int<->bool conversion somewhere anyway. Cheers, David > Thanks! > Jc > > On Tue, Jan 8, 2019 at 10:31 PM David Holmes > wrote: > > Hi Jc, > > On 9/01/2019 4:12 pm, JC Beyler wrote: > > Hi all, > > > > Fixing up the tests in vmTestbase to not be testing explicitly > against > > NSK_TRUE/NSK_FALSE. Here is the webrev to do that: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ > > Hold up! We don't do explicit tests when the variable is a bool/boolean > but when it is an int, as here, we do. > > Are you planning on converting everything to use bool? > > Cheers, > David > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From gary.adams at oracle.com Wed Jan 9 15:43:18 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 09 Jan 2019 10:43:18 -0500 Subject: RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out In-Reply-To: <5C34D0B0.3060709@oracle.com> References: <5C34D0B0.3060709@oracle.com> Message-ID: <5C361696.70505@oracle.com> I could use another reviewer, or an ok to push as a trivial change. On 1/8/19, 11:32 AM, Gary Adams wrote: > A number failures of threadstart002 have been reported on > windows-x64-debug builds. > > This configuration has a jtreg timeout factor assigned so the test can > run 10x slower > and not experience a timeout. > > Unfortunately, these older vmTestbase tests were not fully integrated > with the jtreg > timeout and factor capabilities. > > This test in particular uses a 2 second timeout when monitoring > transitions > between starting a thread and the check for the thread being resumed. > This hard coded timeout is not scaled. > > As a quick workaround the timeout can be scaled up to allow 20 second > window, > as if the scaling factor had been applied as jtreg harness intended. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8213001 > > diff --git > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > > --- > a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > +++ > b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp > @@ -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 > @@ -34,7 +34,7 @@ > > #define PASSED 0 > #define STATUS_FAILED 2 > -#define WAIT_TIME 2000 > +#define WAIT_TIME 20000 > > static jvmtiEnv *jvmti = NULL; > static jvmtiCapabilities caps; From daniel.daugherty at oracle.com Wed Jan 9 16:37:27 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 9 Jan 2019 11:37:27 -0500 Subject: RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out In-Reply-To: <5C361696.70505@oracle.com> References: <5C34D0B0.3060709@oracle.com> <5C361696.70505@oracle.com> Message-ID: On 1/9/19 10:43 AM, Gary Adams wrote: > I could use another reviewer, or an ok to push as a trivial change. Thumbs up! Yes, this qualifies as a trivial change. However, even a trivial change requires a (R)eviewer. JC is currently a committer. Dan > > On 1/8/19, 11:32 AM, Gary Adams wrote: >> A number failures of threadstart002 have been reported on >> windows-x64-debug builds. >> >> This configuration has a jtreg timeout factor assigned so the test >> can run 10x slower >> and not experience a timeout. >> >> Unfortunately, these older vmTestbase tests were not fully integrated >> with the jtreg >> timeout and factor capabilities. >> >> This test in particular uses a 2 second timeout when monitoring >> transitions >> between starting a thread and the check for the thread being resumed. >> This hard coded timeout is not scaled. >> >> As a quick workaround the timeout can be scaled up to allow 20 second >> window, >> as if the scaling factor had been applied as jtreg harness intended. >> >> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8213001 >> >> diff --git >> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp >> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp >> >> --- >> a/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp >> +++ >> b/test/hotspot/jtreg/vmTestbase/nsk/jvmti/ThreadStart/threadstart002/threadstart002.cpp >> @@ -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 >> @@ -34,7 +34,7 @@ >> >> ?#define PASSED 0 >> ?#define STATUS_FAILED 2 >> -#define WAIT_TIME 2000 >> +#define WAIT_TIME 20000 >> >> ?static jvmtiEnv *jvmti = NULL; >> ?static jvmtiCapabilities caps; > > From david.holmes at oracle.com Wed Jan 9 21:28:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2019 07:28:49 +1000 Subject: RFR 8207964: [TESTBUG] Change stressTime to default to 30 for nsk tests In-Reply-To: References: Message-ID: Hi Harold, cc'd serviceability as a lot of nsk tests are in that area. On 10/01/2019 4:56 am, Harold David Seigel wrote: > Hi, > > Please review this fix to change the default stress time for hotspot > vmTestbase tests from 60 seconds to 30 seconds. Which tests actually use this default value? > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8207964/webrev/index.html The actual change to the default appears correct. I just don't know what impact this is going to have on any actual tests. Thanks, David > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8207964 > > The fix was tested by running Mach5 hotspot tiers 1-5 on Linux-x64, > Windows, Solaris, and Mac OS X. > > Thanks, Harold > From zanglin5 at jd.com Thu Jan 10 03:48:09 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Thu, 10 Jan 2019 03:48:09 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> Message-ID: <3281becb646347759cf0a9412524eb1e@jd.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Thu Jan 10 06:10:12 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 10 Jan 2019 11:40:12 +0530 Subject: RFR: 8181313: SA: Remove libthread_db dependency on Linux In-Reply-To: References: Message-ID: <7419f616-31d4-4aef-f982-bc14f09b4ca6@oracle.com> Thank you for implementing this change, Yasumasa. It looks good to me. Just a nit. ==> linux/native/libsaproc/libproc_impl.c Could you please remove these lines ? I don't think these are needed anymore. 421 422 // new libthread_db of NPTL seem to require this symbol 423 JNIEXPORT ps_err_e JNICALL 424 ps_get_thread_area() { 425 print_debug("ps_get_thread_area not implemented\n"); 426 return PS_OK; 427 } ==> linux/native/libsaproc/proc_service.h Could you please remove these lines too ? 79 80 // new libthread_db of NPTL seem to require this symbol 81 JNIEXPORT ps_err_e JNICALL 82 ps_get_thread_area(); Thanks, Jini. On 1/9/2019 6:53 AM, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8181313 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.00/ > > It has passed all tests on submit repo, and serviceability/sa tests on > Linux x64. > > > Thanks, > > Yasumas > From gary.adams at oracle.com Thu Jan 10 13:02:40 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 10 Jan 2019 08:02:40 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file Message-ID: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> SourceDebugExtensionTest was placed on the ProblemList because of filesystem rename issues on Windows 2012 test systems. The test does not appear to fail on the current mach5 test systems. There was some question concerning symbolic links that might have been problematic at that time. Additional testing in progress... ? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -838,8 +838,6 @@ ?com/sun/jdi/RepStep.java 8043571 generic-all -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all - ?com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all From yasuenag at gmail.com Thu Jan 10 13:20:37 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 10 Jan 2019 22:20:37 +0900 Subject: RFR: 8181313: SA: Remove libthread_db dependency on Linux In-Reply-To: <7419f616-31d4-4aef-f982-bc14f09b4ca6@oracle.com> References: <7419f616-31d4-4aef-f982-bc14f09b4ca6@oracle.com> Message-ID: <2efdc891-bd4a-ff13-fedc-fa9ae11e0b8a@gmail.com> Hi Jini, Thank you for your comment. I uploaded a new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.01/ It passed tests on submit repo. Could you review again? Yasumasa On 2019/01/10 15:10, Jini George wrote: > Thank you for implementing this change, Yasumasa. It looks good to me. Just a nit. > > ==> linux/native/libsaproc/libproc_impl.c > Could you please remove these lines ? I don't think these are needed anymore. > > 421 > 422 // new libthread_db of NPTL seem to require this symbol > 423 JNIEXPORT ps_err_e JNICALL > 424 ps_get_thread_area() { > 425?? print_debug("ps_get_thread_area not implemented\n"); > 426?? return PS_OK; > 427 } > > ==> linux/native/libsaproc/proc_service.h > Could you please remove these lines too ? > ?79 > ?80 // new libthread_db of NPTL seem to require this symbol > ?81 JNIEXPORT ps_err_e JNICALL > ?82 ps_get_thread_area(); > > Thanks, > Jini. > > > > On 1/9/2019 6:53 AM, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8181313 >> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.00/ >> >> It has passed all tests on submit repo, and serviceability/sa tests on >> Linux x64. >> >> >> Thanks, >> >> Yasumas >> From jini.george at oracle.com Thu Jan 10 15:10:19 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 10 Jan 2019 20:40:19 +0530 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> Message-ID: 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 Thu Jan 10 16:05:17 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 10 Jan 2019 21:35:17 +0530 Subject: RFR: 8181313: SA: Remove libthread_db dependency on Linux In-Reply-To: <2efdc891-bd4a-ff13-fedc-fa9ae11e0b8a@gmail.com> References: <7419f616-31d4-4aef-f982-bc14f09b4ca6@oracle.com> <2efdc891-bd4a-ff13-fedc-fa9ae11e0b8a@gmail.com> Message-ID: <9f8a615d-9caa-936f-f439-e3d47ba313fd@oracle.com> Thanks, Yasumasa, but I meant removing the declaration and definition of ps_get_thread_area() also. I don't think it is needed anymore. Thanks, Jini. On 1/10/2019 6:50 PM, Yasumasa Suenaga wrote: > Hi Jini, > > Thank you for your comment. > I uploaded a new webrev: > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.01/ > > It passed tests on submit repo. > Could you review again? > > > Yasumasa > > > On 2019/01/10 15:10, Jini George wrote: >> Thank you for implementing this change, Yasumasa. It looks good to me. >> Just a nit. >> >> ==> linux/native/libsaproc/libproc_impl.c >> Could you please remove these lines ? I don't think these are needed >> anymore. >> >> 421 >> 422 // new libthread_db of NPTL seem to require this symbol >> 423 JNIEXPORT ps_err_e JNICALL >> 424 ps_get_thread_area() { >> 425?? print_debug("ps_get_thread_area not implemented\n"); >> 426?? return PS_OK; >> 427 } >> >> ==> linux/native/libsaproc/proc_service.h >> Could you please remove these lines too ? >> ??79 >> ??80 // new libthread_db of NPTL seem to require this symbol >> ??81 JNIEXPORT ps_err_e JNICALL >> ??82 ps_get_thread_area(); >> >> Thanks, >> Jini. >> >> >> >> On 1/9/2019 6:53 AM, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8181313 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.00/ >>> >>> It has passed all tests on submit repo, and serviceability/sa tests on >>> Linux x64. >>> >>> >>> Thanks, >>> >>> Yasumas >>> From jcbeyler at google.com Thu Jan 10 16:58:22 2019 From: jcbeyler at google.com (JC Beyler) Date: Thu, 10 Jan 2019 08:58:22 -0800 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <3281becb646347759cf0a9412524eb1e@jd.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> Message-ID: 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" < > 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 jcbeyler at google.com Thu Jan 10 19:28:08 2019 From: jcbeyler at google.com (JC Beyler) Date: Thu, 10 Jan 2019 11:28:08 -0800 Subject: RFR(S) 8215113: Sampling interval not always correct Message-ID: Hi all, Could I get a review for this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8215113/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215113 This fixes the code to do the right accounting in sampling and get the right sample counts and sampled objects. My error percentage calculation was wrong so the two tests I had added were false positives (my apologies). Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Jan 11 01:28:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 11:28:07 +1000 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> Message-ID: Hi Gary, On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: > SourceDebugExtensionTest was placed on the ProblemList > because of filesystem rename issues on Windows 2012 test systems. > The test does not appear to fail on the current mach5 test systems. > There was some question concerning symbolic links that might have > been problematic at that time. Additional testing in progress... Also note that there are two sets of SDE related tests and two versions of the InstallSDE.java file that both use renameTo. In nsk the testcase seems to be: ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java and AFAICS it is not excluded. So removing the exclusion seems reasonable to me. It was most like a concurrency issue with the virus scanner. Thanks, David > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -838,8 +838,6 @@ > > ?com/sun/jdi/RepStep.java 8043571 generic-all > > -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all > - > ?com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all > From zanglin5 at jd.com Fri Jan 11 02:25:27 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Fri, 11 Jan 2019 02:25:27 +0000 Subject: =?gb2312?B?tPC4tDogW1JGUl04MjE1NjIyOiBBZGQgZHVtcCB0byBmaWxlIHN1cHBvcnQg?= =?gb2312?Q?for_jmap_histo?= In-Reply-To: References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com>, Message-ID: <70826c967ec543df9febd907812d4361@jd.com> 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 ?Chisto. It add the ??file=?? arguments that allow jmap ?Chisto 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 yasuenag at gmail.com Fri Jan 11 02:51:49 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 11 Jan 2019 11:51:49 +0900 Subject: RFR: 8181313: SA: Remove libthread_db dependency on Linux In-Reply-To: <9f8a615d-9caa-936f-f439-e3d47ba313fd@oracle.com> References: <7419f616-31d4-4aef-f982-bc14f09b4ca6@oracle.com> <2efdc891-bd4a-ff13-fedc-fa9ae11e0b8a@gmail.com> <9f8a615d-9caa-936f-f439-e3d47ba313fd@oracle.com> Message-ID: Hi Jini, I removed ps_get_thread_area() in new webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.02/ Diff from webrev.01 is here: http://hg.openjdk.java.net/jdk/submit/rev/691a931ae2ba Thanks, Yasumasa 2019?1?11?(?) 1:05 Jini George : > > Thanks, Yasumasa, but I meant removing the declaration and definition of > ps_get_thread_area() also. I don't think it is needed anymore. > > Thanks, > Jini. > > On 1/10/2019 6:50 PM, Yasumasa Suenaga wrote: > > Hi Jini, > > > > Thank you for your comment. > > I uploaded a new webrev: > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.01/ > > > > It passed tests on submit repo. > > Could you review again? > > > > > > Yasumasa > > > > > > On 2019/01/10 15:10, Jini George wrote: > >> Thank you for implementing this change, Yasumasa. It looks good to me. > >> Just a nit. > >> > >> ==> linux/native/libsaproc/libproc_impl.c > >> Could you please remove these lines ? I don't think these are needed > >> anymore. > >> > >> 421 > >> 422 // new libthread_db of NPTL seem to require this symbol > >> 423 JNIEXPORT ps_err_e JNICALL > >> 424 ps_get_thread_area() { > >> 425 print_debug("ps_get_thread_area not implemented\n"); > >> 426 return PS_OK; > >> 427 } > >> > >> ==> linux/native/libsaproc/proc_service.h > >> Could you please remove these lines too ? > >> 79 > >> 80 // new libthread_db of NPTL seem to require this symbol > >> 81 JNIEXPORT ps_err_e JNICALL > >> 82 ps_get_thread_area(); > >> > >> Thanks, > >> Jini. > >> > >> > >> > >> On 1/9/2019 6:53 AM, Yasumasa Suenaga wrote: > >>> Hi all, > >>> > >>> Please review this change: > >>> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181313 > >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.00/ > >>> > >>> It has passed all tests on submit repo, and serviceability/sa tests on > >>> Linux x64. > >>> > >>> > >>> Thanks, > >>> > >>> Yasumas > >>> From jini.george at oracle.com Fri Jan 11 04:01:24 2019 From: jini.george at oracle.com (Jini George) Date: Fri, 11 Jan 2019 09:31:24 +0530 Subject: RFR: 8181313: SA: Remove libthread_db dependency on Linux In-Reply-To: References: <7419f616-31d4-4aef-f982-bc14f09b4ca6@oracle.com> <2efdc891-bd4a-ff13-fedc-fa9ae11e0b8a@gmail.com> <9f8a615d-9caa-936f-f439-e3d47ba313fd@oracle.com> Message-ID: <2e09d91b-1059-227d-8472-124d830d1d61@oracle.com> Looks good to me, Yasumasa. Thanks! Jini. On 1/11/2019 8:21 AM, Yasumasa Suenaga wrote: > Hi Jini, > > I removed ps_get_thread_area() in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.02/ > > Diff from webrev.01 is here: > > http://hg.openjdk.java.net/jdk/submit/rev/691a931ae2ba > > > Thanks, > > Yasumasa > > > 2019?1?11?(?) 1:05 Jini George : >> >> Thanks, Yasumasa, but I meant removing the declaration and definition of >> ps_get_thread_area() also. I don't think it is needed anymore. >> >> Thanks, >> Jini. >> >> On 1/10/2019 6:50 PM, Yasumasa Suenaga wrote: >>> Hi Jini, >>> >>> Thank you for your comment. >>> I uploaded a new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.01/ >>> >>> It passed tests on submit repo. >>> Could you review again? >>> >>> >>> Yasumasa >>> >>> >>> On 2019/01/10 15:10, Jini George wrote: >>>> Thank you for implementing this change, Yasumasa. It looks good to me. >>>> Just a nit. >>>> >>>> ==> linux/native/libsaproc/libproc_impl.c >>>> Could you please remove these lines ? I don't think these are needed >>>> anymore. >>>> >>>> 421 >>>> 422 // new libthread_db of NPTL seem to require this symbol >>>> 423 JNIEXPORT ps_err_e JNICALL >>>> 424 ps_get_thread_area() { >>>> 425 print_debug("ps_get_thread_area not implemented\n"); >>>> 426 return PS_OK; >>>> 427 } >>>> >>>> ==> linux/native/libsaproc/proc_service.h >>>> Could you please remove these lines too ? >>>> 79 >>>> 80 // new libthread_db of NPTL seem to require this symbol >>>> 81 JNIEXPORT ps_err_e JNICALL >>>> 82 ps_get_thread_area(); >>>> >>>> Thanks, >>>> Jini. >>>> >>>> >>>> >>>> On 1/9/2019 6:53 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181313 >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.00/ >>>>> >>>>> It has passed all tests on submit repo, and serviceability/sa tests on >>>>> Linux x64. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumas >>>>> From jcbeyler at google.com Fri Jan 11 04:08:43 2019 From: jcbeyler at google.com (JC Beyler) Date: Thu, 10 Jan 2019 20:08:43 -0800 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> Message-ID: Hi Jini, Looks good to me now :) Thanks for handling the comments :) Jc On Tue, Jan 8, 2019 at 8:11 PM Jini George wrote: > Thank you very much for the review, JC. My comments inline: > > On 1/8/2019 12:22 AM, JC Beyler wrote: > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html > > + // by appending 'sudo' to it. Check now if sudo > > passes in this > > + // environment with a simple 'echo' command. > > -> Really shouldn't provide implementation details about what is > > being done by that method; if we change that, this comment will rot :-) > > canAddPrivileges is explicit enough in my mind > > Done. I have removed the comment. > > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/test/lib/SA/SATestUtils.java.html > > > > -> You put some System.out.println; are they intended to still be > > there or were they for debug? > > I guess you meant this one: > System.out.println("Adding 'sudo -E' to the command."); > > This one is meant to be there. > > > > > > > 77 for (String val: cmdStringList) { > > 78 outStringList.add(val); > > 79 } > > > > > > Couldn't we use addAll ? > > Done. > The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html > > Thanks, > Jini. > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jini.george at oracle.com Fri Jan 11 04:15:42 2019 From: jini.george at oracle.com (Jini George) Date: Fri, 11 Jan 2019 09:45:42 +0530 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> Message-ID: <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> Thanks again, JC! :-) Folks, Could I please get one more review on this ? -Jini. On 1/11/2019 9:38 AM, JC Beyler wrote: > Hi Jini, > > Looks?good to me now :) Thanks for handling the comments :) > Jc > > > On Tue, Jan 8, 2019 at 8:11 PM Jini George > wrote: > > Thank you very much for the review, JC. My comments inline: > > On 1/8/2019 12:22 AM, JC Beyler wrote: > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html > >? ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check now if sudo > > passes in this > >? ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' command. > >? ? ? ?-> Really shouldn't provide implementation details about > what is > > being done by that method; if we change that, this comment will > rot :-) > > canAddPrivileges is explicit enough in my mind > > Done. I have removed the comment. > > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/test/lib/SA/SATestUtils.java.html > > > > >? ? ? -> You put some System.out.println; are they intended to > still be > > there or were they for debug? > > I guess you meant this one: > System.out.println("Adding 'sudo -E' to the command."); > > This one is meant to be there. > > > > > > >? ? 77? ? ? ? ?for (String val: cmdStringList) { > >? ? 78? ? ? ? ? ? ?outStringList.add(val); > >? ? 79? ? ? ? ?} > > > > > > Couldn't we use addAll ? > > Done. > The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html > > Thanks, > Jini. > > > > > > -- > > Thanks, > Jc From jcbeyler at google.com Fri Jan 11 05:20:54 2019 From: jcbeyler at google.com (JC Beyler) Date: Thu, 10 Jan 2019 21:20:54 -0800 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: <50b8c141-860e-6787-d9d8-e2ab79392ce8@oracle.com> References: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> <50b8c141-860e-6787-d9d8-e2ab79392ce8@oracle.com> Message-ID: Hi David, Fair enough. I looked a bit to doing it anyway and it is self-contained in a lot of cases but a lot of times the work would be greatly simplified if we first factorized utility methods across test suites first and then (or at the same time) moved them to using bools and not doing the explicit tests. So, except if anyone objects, I'm closing this bug as won't fix and I created https://bugs.openjdk.java.net/browse/JDK-8216533 and https://bugs.openjdk.java.net/browse/JDK-8216534 for the events/hotswap tests which were the most cases of this anyway. Thanks for the hold up David :-), Jc On Tue, Jan 8, 2019 at 11:14 PM David Holmes wrote: > On 9/01/2019 4:43 pm, JC Beyler wrote: > > Hi David, > > > > I was not planning on doing it but we could. This change came from a > > request to remove the booleans from tests for a prior webrev change. > > I've seen previous conversations about wanting to test explicitly > > against JNI_TRUE but thought this was a slightly different case. > > The basic hotspot style rule is "avoid implicit booleans". > > > Basically, from your comment, it seems I could go three ways for this > > change: > > 1) Not do it and close the bug as won't fix :-) > > Certainly the path of least resistance. :) > > > 2) Go the extra step and change the various variables being tested to > > bool > > > > My preference is to do (2) as much as possible; any case that cannot be > > put in a boolean form without having major changes to the code base, I'd > > leave as is. And then call it a day for this subject. > > > > What do you think (ie in cases where the variable can be set to a bool, > > do it and then have the test be an implicit test)? > > It's really up to you. It seems a lot of work and I don't know if you > can actually push this all the way through without needing some > int<->bool conversion somewhere anyway. > > Cheers, > David > > > Thanks! > > Jc > > > > On Tue, Jan 8, 2019 at 10:31 PM David Holmes > > wrote: > > > > Hi Jc, > > > > On 9/01/2019 4:12 pm, JC Beyler wrote: > > > Hi all, > > > > > > Fixing up the tests in vmTestbase to not be testing explicitly > > against > > > NSK_TRUE/NSK_FALSE. Here is the webrev to do that: > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ > > > > Hold up! We don't do explicit tests when the variable is a > bool/boolean > > but when it is an int, as here, we do. > > > > Are you planning on converting everything to use bool? > > > > Cheers, > > David > > > > > Thanks, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Jan 11 05:34:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 15:34:23 +1000 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: References: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> <50b8c141-860e-6787-d9d8-e2ab79392ce8@oracle.com> Message-ID: On 11/01/2019 3:20 pm, JC Beyler wrote: > Hi David, > > Fair enough. I looked a bit to doing it anyway? and it is self-contained > in a lot of cases but a lot of times the work would be greatly > simplified if we first factorized utility methods across test suites > first and then (or at the same time) moved them to using bools and not > doing the explicit tests. > > So, except if? anyone? objects, I'm closing this bug as won't fix and I > created https://bugs.openjdk.java.net/browse/JDK-8216533 and > https://bugs.openjdk.java.net/browse/JDK-8216534?for the events/hotswap > tests which were the most cases of this anyway. Okay. > Thanks for the hold up David :-), Any time :) Cheers, David > Jc > > On Tue, Jan 8, 2019 at 11:14 PM David Holmes > wrote: > > On 9/01/2019 4:43 pm, JC Beyler wrote: > > Hi David, > > > > I was not planning on doing it but we could. This change came from a > > request to remove the booleans from tests for a prior webrev change. > > I've seen previous conversations about wanting to test explicitly > > against JNI_TRUE but thought this was a slightly different case. > > The basic hotspot style rule is "avoid implicit booleans". > > > Basically, from your comment, it seems I could go three ways for > this > > change: > >? ? 1) Not do it and close the bug as won't fix :-) > > Certainly the path of least resistance. :) > > >? ? 2) Go the extra step and change the various variables being > tested to > > bool > > > > My preference is to do (2) as much as possible; any case that > cannot be > > put in a boolean form without having major changes to the code > base, I'd > > leave as is. And then call it a day for this subject. > > > > What do you think (ie in cases where the variable can be set to a > bool, > > do it and then have the test be an implicit test)? > > It's really up to you. It seems a lot of work and I don't know if you > can actually push this all the way through without needing some > int<->bool conversion somewhere anyway. > > Cheers, > David > > > Thanks! > > Jc > > > > On Tue, Jan 8, 2019 at 10:31 PM David Holmes > > > >> wrote: > > > >? ? ?Hi Jc, > > > >? ? ?On 9/01/2019 4:12 pm, JC Beyler wrote: > >? ? ? > Hi all, > >? ? ? > > >? ? ? > Fixing up the tests in vmTestbase to not be testing explicitly > >? ? ?against > >? ? ? > NSK_TRUE/NSK_FALSE. Here is the webrev to do that: > >? ? ? > > >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 > >? ? ? > Webrev: > http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ > > > >? ? ?Hold up! We don't do explicit tests when the variable is a > bool/boolean > >? ? ?but when it is an int, as here, we do. > > > >? ? ?Are you planning on converting everything to use bool? > > > >? ? ?Cheers, > >? ? ?David > > > >? ? ? > Thanks, > >? ? ? > Jc > > > > > > > > -- > > > > Thanks, > > Jc > > > > -- > > Thanks, > Jc From zanglin5 at jd.com Fri Jan 11 09:38:25 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Fri, 11 Jan 2019 09:38:25 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <70826c967ec543df9febd907812d4361@jd.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com>, , <70826c967ec543df9febd907812d4361@jd.com> Message-ID: 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 ?Chisto. It add the ??file=?? arguments that allow jmap ?Chisto 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 Fri Jan 11 11:22:46 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Fri, 11 Jan 2019 06:22:46 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> Message-ID: After ~1000 testruns I hit a failure in MangleTest and a jtreg agent communication issue with SourceDebugExtension. https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* at InstallSDE.install(InstallSDE.java:40) at MangleTest.testSetUp(MangleTest.java:38) at MangleTest.main(MangleTest.java:31) result: Error. Agent communication error: java.io.IOException:*Agent: unexpected op: 71;* check console log for any additional details I added some additional print outs for the rename issue and have run ~2000 additional testruns with no test failures repeated, yet. But there were 2 mach5 reported errors: TimeoutException in CLEANUP. I'll do some more investigation with making the rename operation more robust before removing SourceDebugExtensionTest from the problem list. On 1/10/19 8:28 PM, David Holmes wrote: > Hi Gary, > > On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >> SourceDebugExtensionTest was placed on the ProblemList >> because of filesystem rename issues on Windows 2012 test systems. >> The test does not appear to fail on the current mach5 test systems. >> There was some question concerning symbolic links that might have >> been problematic at that time. Additional testing in progress... > > Also note that there are two sets of SDE related tests and two > versions of the InstallSDE.java file that both use renameTo. In nsk > the testcase seems to be: > > ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java > > and AFAICS it is not excluded. So removing the exclusion seems > reasonable to me. It was most like a concurrency issue with the virus > scanner. > > Thanks, > David > > >> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >> >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -838,8 +838,6 @@ >> >> ??com/sun/jdi/RepStep.java 8043571 generic-all >> >> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >> - >> ??com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Jan 11 12:40:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 22:40:40 +1000 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> Message-ID: <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> Hi Gary, On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: > After ~1000 testruns I hit a failure in MangleTest and a jtreg agent > communication issue with SourceDebugExtension. > > https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid > > > *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* > at InstallSDE.install(InstallSDE.java:40) > at MangleTest.testSetUp(MangleTest.java:38) > at MangleTest.main(MangleTest.java:31) You might want to add some code in: ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 that checks the result of _wrename to see what error is occurring. I suspect it will be EACCES which won't be that helpful: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 but it would be good to confirm. > > result: Error. Agent communication error: java.io.IOException:*Agent: unexpected op: 71;* check console log for any additional details > > I added some additional print outs for the rename issue and have run > ~2000 additional > testruns with no test failures repeated, yet. But there were 2 mach5 > reported errors: > > TimeoutException in CLEANUP. That's a mach5 issue. David > > I'll do some more investigation with making the rename operation more robust > before removing SourceDebugExtensionTest from the problem list. > > On 1/10/19 8:28 PM, David Holmes wrote: >> Hi Gary, >> >> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>> SourceDebugExtensionTest was placed on the ProblemList >>> because of filesystem rename issues on Windows 2012 test systems. >>> The test does not appear to fail on the current mach5 test systems. >>> There was some question concerning symbolic links that might have >>> been problematic at that time. Additional testing in progress... >> >> Also note that there are two sets of SDE related tests and two >> versions of the InstallSDE.java file that both use renameTo. In nsk >> the testcase seems to be: >> >> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >> >> and AFAICS it is not excluded. So removing the exclusion seems >> reasonable to me. It was most like a concurrency issue with the virus >> scanner. >> >> Thanks, >> David >> >> >>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>> >>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt >>> +++ b/test/jdk/ProblemList.txt >>> @@ -838,8 +838,6 @@ >>> >>> ??com/sun/jdi/RepStep.java 8043571 generic-all >>> >>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>> - >>> ??com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>> > From gary.adams at oracle.com Fri Jan 11 16:01:33 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 11 Jan 2019 11:01:33 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> Message-ID: <5C38BDDD.80602@oracle.com> I've been reading recently that Windows delete file operations can be delayed, if there are open handles against the file. Others have reported virus checkers or other indexing programs may hold a handle on a file preventing the deletion being completed. The basic logic in InstallSDE is A + B = C delete A rename C to A I think we can work around the issue with rename A to A1 A1 + B = C delete A1 rename C to A diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java b/test/jdk/com/sun/jdi/sde/InstallSDE.java --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java @@ -31,9 +31,17 @@ } static void install(File inOutClassFile, File attrFile) throws IOException { - File tmpFile = new File(inOutClassFile.getPath() + "tmp"); - new InstallSDE(inOutClassFile, attrFile, tmpFile); - if (!inOutClassFile.delete()) { + File tmpFile = new File(inOutClassFile.getPath() + "tmp-out"); + File tmpInOutClassFile = new File(inOutClassFile.getPath() + "tmp-in"); + + // Workaround delayed file deletes on Windows using a tmp file name + if (!inOutClassFile.renameTo(tmpInOutClassFile)) { + throw new IOException("tmp copy of inOutClassFile failed"); + } + + new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); + + if (!tmpInOutClassFile.delete()) { throw new IOException("inOutClassFile.delete() failed"); } if (!tmpFile.renameTo(inOutClassFile)) { Testing in progress ... On 1/11/19, 7:40 AM, David Holmes wrote: > Hi Gary, > > On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >> After ~1000 testruns I hit a failure in MangleTest and a jtreg agent >> communication issue with SourceDebugExtension. >> >> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >> >> >> >> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >> at InstallSDE.install(InstallSDE.java:40) >> at MangleTest.testSetUp(MangleTest.java:38) >> at MangleTest.main(MangleTest.java:31) > > You might want to add some code in: > > ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 > > > that checks the result of _wrename to see what error is occurring. I > suspect it will be EACCES which won't be that helpful: > > https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 > > > but it would be good to confirm. > >> >> result: Error. Agent communication error: java.io.IOException:*Agent: >> unexpected op: 71;* check console log for any additional details >> >> I added some additional print outs for the rename issue and have run >> ~2000 additional >> testruns with no test failures repeated, yet. But there were 2 mach5 >> reported errors: >> >> TimeoutException in CLEANUP. > > That's a mach5 issue. > > David > >> >> I'll do some more investigation with making the rename operation more >> robust >> before removing SourceDebugExtensionTest from the problem list. >> >> On 1/10/19 8:28 PM, David Holmes wrote: >>> Hi Gary, >>> >>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>> SourceDebugExtensionTest was placed on the ProblemList >>>> because of filesystem rename issues on Windows 2012 test systems. >>>> The test does not appear to fail on the current mach5 test systems. >>>> There was some question concerning symbolic links that might have >>>> been problematic at that time. Additional testing in progress... >>> >>> Also note that there are two sets of SDE related tests and two >>> versions of the InstallSDE.java file that both use renameTo. In nsk >>> the testcase seems to be: >>> >>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>> >>> and AFAICS it is not excluded. So removing the exclusion seems >>> reasonable to me. It was most like a concurrency issue with the >>> virus scanner. >>> >>> Thanks, >>> David >>> >>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>> >>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>> --- a/test/jdk/ProblemList.txt >>>> +++ b/test/jdk/ProblemList.txt >>>> @@ -838,8 +838,6 @@ >>>> >>>> com/sun/jdi/RepStep.java 8043571 generic-all >>>> >>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>> - >>>> com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>> >> From gary.adams at oracle.com Fri Jan 11 18:53:12 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 11 Jan 2019 13:53:12 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <5C38BDDD.80602@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> Message-ID: <5C38E618.3020904@oracle.com> Here's a webrev for review purposes. No failures after ~1000 testruns. Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 On 1/11/19, 11:01 AM, Gary Adams wrote: > I've been reading recently that Windows delete file operations > can be delayed, if there are open handles against the file. > Others have reported virus checkers or other indexing > programs may hold a handle on a file preventing the > deletion being completed. > > The basic logic in InstallSDE is > A + B = C > delete A > rename C to A > > I think we can work around the issue with > rename A to A1 > A1 + B = C > delete A1 > rename C to A > > diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java > b/test/jdk/com/sun/jdi/sde/InstallSDE.java > --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java > +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java > @@ -31,9 +31,17 @@ > } > > static void install(File inOutClassFile, File attrFile) throws > IOException { > - File tmpFile = new File(inOutClassFile.getPath() + "tmp"); > - new InstallSDE(inOutClassFile, attrFile, tmpFile); > - if (!inOutClassFile.delete()) { > + File tmpFile = new File(inOutClassFile.getPath() + "tmp-out"); > + File tmpInOutClassFile = new File(inOutClassFile.getPath() + > "tmp-in"); > + > + // Workaround delayed file deletes on Windows using a tmp > file name > + if (!inOutClassFile.renameTo(tmpInOutClassFile)) { > + throw new IOException("tmp copy of inOutClassFile failed"); > + } > + > + new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); > + > + if (!tmpInOutClassFile.delete()) { > throw new IOException("inOutClassFile.delete() failed"); > } > if (!tmpFile.renameTo(inOutClassFile)) { > > > Testing in progress ... > > On 1/11/19, 7:40 AM, David Holmes wrote: >> Hi Gary, >> >> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>> After ~1000 testruns I hit a failure in MangleTest and a jtreg agent >>> communication issue with SourceDebugExtension. >>> >>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>> >>> >>> >>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>> at InstallSDE.install(InstallSDE.java:40) >>> at MangleTest.testSetUp(MangleTest.java:38) >>> at MangleTest.main(MangleTest.java:31) >> >> You might want to add some code in: >> >> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >> >> >> that checks the result of _wrename to see what error is occurring. I >> suspect it will be EACCES which won't be that helpful: >> >> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >> >> >> but it would be good to confirm. >> >>> >>> result: Error. Agent communication error: >>> java.io.IOException:*Agent: unexpected op: 71;* check console log >>> for any additional details >>> >>> I added some additional print outs for the rename issue and have run >>> ~2000 additional >>> testruns with no test failures repeated, yet. But there were 2 mach5 >>> reported errors: >>> >>> TimeoutException in CLEANUP. >> >> That's a mach5 issue. >> >> David >> >>> >>> I'll do some more investigation with making the rename operation >>> more robust >>> before removing SourceDebugExtensionTest from the problem list. >>> >>> On 1/10/19 8:28 PM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>> The test does not appear to fail on the current mach5 test systems. >>>>> There was some question concerning symbolic links that might have >>>>> been problematic at that time. Additional testing in progress... >>>> >>>> Also note that there are two sets of SDE related tests and two >>>> versions of the InstallSDE.java file that both use renameTo. In nsk >>>> the testcase seems to be: >>>> >>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>> >>>> and AFAICS it is not excluded. So removing the exclusion seems >>>> reasonable to me. It was most like a concurrency issue with the >>>> virus scanner. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>> >>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>> --- a/test/jdk/ProblemList.txt >>>>> +++ b/test/jdk/ProblemList.txt >>>>> @@ -838,8 +838,6 @@ >>>>> >>>>> com/sun/jdi/RepStep.java 8043571 generic-all >>>>> >>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>>> - >>>>> com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>> >>> > From david.holmes at oracle.com Fri Jan 11 23:14:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Jan 2019 09:14:58 +1000 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <5C38E618.3020904@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <5C38E618.3020904@oracle.com> Message-ID: Hi Gary, As I mentioned earlier there are two versions of InstallSDE.java in the tests, so both should be updated. Your strategy to avoid the windows delete issue seems reasonable. David On 12/01/2019 4:53 am, Gary Adams wrote: > Here's a webrev for review purposes. > No failures after ~1000 testruns. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 > > On 1/11/19, 11:01 AM, Gary Adams wrote: >> I've been reading recently that Windows delete file operations >> can be delayed, if there are open handles against the file. >> Others have reported virus checkers or other indexing >> programs may hold a handle on a file preventing the >> deletion being completed. >> >> The basic logic in InstallSDE is >> ?? A + B = C >> ?? delete A >> ?? rename C to A >> >> I think we can work around the issue with >> ? rename A to A1 >> ? A1 + B = C >> ? delete A1 >> ? rename C to A >> >> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >> @@ -31,9 +31,17 @@ >> ???? } >> >> ???? static void install(File inOutClassFile, File attrFile) throws >> IOException { >> -??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >> -??????? new InstallSDE(inOutClassFile, attrFile, tmpFile); >> -??????? if (!inOutClassFile.delete()) { >> +??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp-out"); >> +??????? File tmpInOutClassFile = new File(inOutClassFile.getPath() + >> "tmp-in"); >> + >> +??????? // Workaround delayed file deletes on Windows using a tmp >> file name >> +??????? if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >> +??????????? throw new IOException("tmp copy of inOutClassFile failed"); >> +??????? } >> + >> +??????? new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >> + >> +??????? if (!tmpInOutClassFile.delete()) { >> ???????????? throw new IOException("inOutClassFile.delete() failed"); >> ???????? } >> ???????? if (!tmpFile.renameTo(inOutClassFile)) { >> >> >> Testing in progress ... >> >> On 1/11/19, 7:40 AM, David Holmes wrote: >>> Hi Gary, >>> >>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg agent >>>> communication issue with SourceDebugExtension. >>>> >>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>> >>>> >>>> >>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>> ??? at InstallSDE.install(InstallSDE.java:40) >>>> ??? at MangleTest.testSetUp(MangleTest.java:38) >>>> ??? at MangleTest.main(MangleTest.java:31) >>> >>> You might want to add some code in: >>> >>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>> >>> >>> that checks the result of _wrename to see what error is occurring. I >>> suspect it will be EACCES which won't be that helpful: >>> >>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>> >>> >>> but it would be good to confirm. >>> >>>> >>>> result: Error. Agent communication error: >>>> java.io.IOException:*Agent: unexpected op: 71;*? check console log >>>> for any additional details >>>> >>>> I added some additional print outs for the rename issue and have run >>>> ~2000 additional >>>> testruns with no test failures repeated, yet. But there were 2 mach5 >>>> reported errors: >>>> >>>> ??? TimeoutException in CLEANUP. >>> >>> That's a mach5 issue. >>> >>> David >>> >>>> >>>> I'll do some more investigation with making the rename operation >>>> more robust >>>> before removing SourceDebugExtensionTest from the problem list. >>>> >>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>> Hi Gary, >>>>> >>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>>> The test does not appear to fail on the current mach5 test systems. >>>>>> There was some question concerning symbolic links that might have >>>>>> been problematic at that time. Additional testing in progress... >>>>> >>>>> Also note that there are two sets of SDE related tests and two >>>>> versions of the InstallSDE.java file that both use renameTo. In nsk >>>>> the testcase seems to be: >>>>> >>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>> >>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>> reasonable to me. It was most like a concurrency issue with the >>>>> virus scanner. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>> >>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>> --- a/test/jdk/ProblemList.txt >>>>>> +++ b/test/jdk/ProblemList.txt >>>>>> @@ -838,8 +838,6 @@ >>>>>> >>>>>> ? com/sun/jdi/RepStep.java 8043571 generic-all >>>>>> >>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>>>> - >>>>>> ? com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>> >>>> >> > From hohensee at amazon.com Sat Jan 12 00:11:51 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Sat, 12 Jan 2019 00:11:51 +0000 Subject: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 Message-ID: <2F096216-56CA-4092-9B64-2E42FDE5D2D5@amazon.com> A more generic approach that doesn?t check for a specific platform in ClhsdbLauncher.java would be nice, e.g., add a checkForPrivileges() method to Platform, but if OSX is the only platform that needs the check, I'm ok with this patch. Thanks, Paul ?On 1/10/19, 8:16 PM, "serviceability-dev on behalf of Jini George" wrote: Thanks again, JC! :-) Folks, Could I please get one more review on this ? -Jini. On 1/11/2019 9:38 AM, JC Beyler wrote: > Hi Jini, > > Looks good to me now :) Thanks for handling the comments :) > Jc > > > On Tue, Jan 8, 2019 at 8:11 PM Jini George > wrote: > > Thank you very much for the review, JC. My comments inline: > > On 1/8/2019 12:22 AM, JC Beyler wrote: > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html > > + // by appending 'sudo' to it. Check now if sudo > > passes in this > > + // environment with a simple 'echo' command. > > -> Really shouldn't provide implementation details about > what is > > being done by that method; if we change that, this comment will > rot :-) > > canAddPrivileges is explicit enough in my mind > > Done. I have removed the comment. > > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/test/lib/SA/SATestUtils.java.html > > > > > -> You put some System.out.println; are they intended to > still be > > there or were they for debug? > > I guess you meant this one: > System.out.println("Adding 'sudo -E' to the command."); > > This one is meant to be there. > > > > > > > 77 for (String val: cmdStringList) { > > 78 outStringList.add(val); > > 79 } > > > > > > Couldn't we use addAll ? > > Done. > The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html > > Thanks, > Jini. > > > > > > -- > > Thanks, > Jc From hohensee at amazon.com Sat Jan 12 01:07:21 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Sat, 12 Jan 2019 01:07:21 +0000 Subject: RFR(S) 8215113: Sampling interval not always correct In-Reply-To: References: Message-ID: <45A5FFFC-729A-4E50-877E-955CE17BF9FA@amazon.com> Nits: memAllocator.cpp: Copyright line should read * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. The comment // Tell tlab to forget the bytes_since if we passed it to the heap sampler. would be clearer if it read // Tell tlab to forget bytes_since_last if we passed it to the heap sampler. Same copyright line comment for HeapMonitor.java, HeapMonitorArrayAllSampledTest.java and HeapMonitorStatArrayCorrectnessTest.java as for memAllocator.cpp. Otherwise lgtm, no need for another webrev on my account. Thanks, Paul From: serviceability-dev on behalf of JC Beyler Date: Thursday, January 10, 2019 at 11:28 AM To: OpenJDK Serviceability Subject: RFR(S) 8215113: Sampling interval not always correct Hi all, Could I get a review for this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8215113/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215113 This fixes the code to do the right accounting in sampling and get the right sample counts and sampled objects. My error percentage calculation was wrong so the two tests I had added were false positives (my apologies). Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Sat Jan 12 02:54:59 2019 From: jcbeyler at google.com (JC Beyler) Date: Fri, 11 Jan 2019 18:54:59 -0800 Subject: RFR(S) 8215113: Sampling interval not always correct In-Reply-To: <45A5FFFC-729A-4E50-877E-955CE17BF9FA@amazon.com> References: <45A5FFFC-729A-4E50-877E-955CE17BF9FA@amazon.com> Message-ID: Hi Paul, Thanks, fixed all of the above in my local branch :-), Jc On Fri, Jan 11, 2019 at 5:07 PM Hohensee, Paul wrote: > Nits: > > > > memAllocator.cpp: > > > > Copyright line should read > > > > * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights > reserved. > > > > The comment > > > > // Tell tlab to forget the bytes_since if we passed it to the heap sampler. > > > > would be clearer if it read > > > > // Tell tlab to forget bytes_since_last if we passed it to the heap sampler. > > Same copyright line comment for HeapMonitor.java, > HeapMonitorArrayAllSampledTest.java and HeapMonitorStatArrayCorrectnessTest.java > as for memAllocator.cpp. > > Otherwise lgtm, no need for another webrev on my account. > > > Thanks, > > > > Paul > > > > *From: *serviceability-dev > on behalf of JC Beyler > *Date: *Thursday, January 10, 2019 at 11:28 AM > *To: *OpenJDK Serviceability > *Subject: *RFR(S) 8215113: Sampling interval not always correct > > > > Hi all, > > > > Could I get a review for this: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8215113/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215113 > > > > This fixes the code to do the right accounting in sampling and get the > right sample counts and sampled objects. My error percentage calculation > was wrong so the two tests I had added were false positives (my apologies). > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Sat Jan 12 10:08:30 2019 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sat, 12 Jan 2019 02:08:30 -0800 (PST) Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> Message-ID: <2b441c90-c926-4286-9ca7-889f1fc0b4b6@default> Hi Jini, ClhsdbLauncher.java 1. Is the platform check not required in case of core files ? - if (!Platform.shouldSAAttach()) { - // Silently skip the test if we don't have enough permissions to attach - System.out.println("SA attach not expected to work - test skipped."); - return null; - } - 2. Nit: extra line at 135 Thanks, Sharath -----Original Message----- From: Jini George Sent: Friday, January 11, 2019 9:46 AM To: JC Beyler; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 Thanks again, JC! :-) Folks, Could I please get one more review on this ? -Jini. On 1/11/2019 9:38 AM, JC Beyler wrote: > Hi Jini, > > Looks?good to me now :) Thanks for handling the comments :) Jc > > > On Tue, Jan 8, 2019 at 8:11 PM Jini George > wrote: > > Thank you very much for the review, JC. My comments inline: > > On 1/8/2019 12:22 AM, JC Beyler wrote: > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html > >? ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check now if sudo > > passes in this > >? ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' command. > >? ? ? ?-> Really shouldn't provide implementation details about > what is > > being done by that method; if we change that, this comment will > rot :-) > > canAddPrivileges is explicit enough in my mind > > Done. I have removed the comment. > > > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/tes > t/lib/SA/SATestUtils.java.html > > > > >? ? ? -> You put some System.out.println; are they intended to > still be > > there or were they for debug? > > I guess you meant this one: > System.out.println("Adding 'sudo -E' to the command."); > > This one is meant to be there. > > > > > > >? ? 77? ? ? ? ?for (String val: cmdStringList) { > >? ? 78? ? ? ? ? ? ?outStringList.add(val); > >? ? 79? ? ? ? ?} > > > > > > Couldn't we use addAll ? > > Done. > The modified webrev is at: > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html > > Thanks, > Jini. > > > > > > -- > > Thanks, > Jc From chris.plummer at oracle.com Sat Jan 12 22:33:48 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 12 Jan 2019 14:33:48 -0800 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: References: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> <50b8c141-860e-6787-d9d8-e2ab79392ce8@oracle.com> Message-ID: <3b1791e4-8835-5b6a-21d8-0c7ca8beb68c@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sun Jan 13 12:14:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 13 Jan 2019 22:14:01 +1000 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: <3b1791e4-8835-5b6a-21d8-0c7ca8beb68c@oracle.com> References: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> <50b8c141-860e-6787-d9d8-e2ab79392ce8@oracle.com> <3b1791e4-8835-5b6a-21d8-0c7ca8beb68c@oracle.com> Message-ID: <6b05387e-ed15-4c24-45f4-30f1bb638cbc@oracle.com> On 13/01/2019 8:33 am, Chris Plummer wrote: > Hi JC and David, > > Sorry I'm late here. Was out most of the week. I assume by "implicit > boolean" that David means treating an int as a boolean when the the int > could potentially contain a value other than 0 or 1? So if we have: The style guide [1] states: "Do not use ints or pointers as booleans with &&, ||, if, while. Instead, compare explicitly != 0 or != NULL, etc. (See #8 above.)" > > ????? int success; > ??? ... > ????? if (success != NSK_TRUE) { > > You feel the check against NSK_TRUE is needed, and using !success would > potentially yield an incorrect evaluation of the "boolean". No it isn't a correctness issue (though obviously you can use an int incorrectly in such a context) it's a style issue. We regularly eradicate implicit booleans so it is inappropriate to introduce them here. David ----- [1] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide Well, if > success is not 0 or 1, then let's say it is 2. You end up with 2 != > NSK_TRUE, which evaluations true. Compared with !2 which evaluations > false. So clearly there is a difference, but which would you consider > correct in this case? I'd consider the false evaluation correct. If > success is not 0, we want !success to be false. But if you compare > against NSK_TRUE, the evaluation only ends up being false when success > == 1. This doesn't seem right to me, so I would argue that "success != > NSK_TRUE" is not only clumsy coding, but also gives the wrong result for > values other than 0 or 1. In order to correct it,? you would use > "success == NSK_FALSE". But I don't understand the implicit boolean > concern with !success when the value is suppose to always be 0 or 1. > Where I would object to do something like this is with pointer types. > Using !ptr is bad. "ptr == NULL" should be used. > > That being said, if JC prefers to clean this up at a later date as part > of changing success to a bool, that's fine by mean also. > > thanks, > > Chris > > > On 1/10/19 9:20 PM, JC Beyler wrote: >> Hi David, >> >> Fair enough. I looked a bit to doing it anyway? and it is >> self-contained in a lot of cases but a lot of times the work would be >> greatly simplified if we first factorized utility methods across test >> suites first and then (or at the same time) moved them to using bools >> and not doing the explicit tests. >> >> So, except if? anyone? objects, I'm closing this bug as won't fix and >> I created https://bugs.openjdk.java.net/browse/JDK-8216533 and >> https://bugs.openjdk.java.net/browse/JDK-8216534?for the >> events/hotswap tests which were the most cases of this anyway. >> >> Thanks for the hold up David :-), >> Jc >> >> On Tue, Jan 8, 2019 at 11:14 PM David Holmes > > wrote: >> >> On 9/01/2019 4:43 pm, JC Beyler wrote: >> > Hi David, >> > >> > I was not planning on doing it but we could. This change came >> from a >> > request to remove the booleans from tests for a prior webrev >> change. >> > I've seen previous conversations about wanting to test explicitly >> > against JNI_TRUE but thought this was a slightly different case. >> >> The basic hotspot style rule is "avoid implicit booleans". >> >> > Basically, from your comment, it seems I could go three ways for >> this >> > change: >> >? ? 1) Not do it and close the bug as won't fix :-) >> >> Certainly the path of least resistance. :) >> >> >? ? 2) Go the extra step and change the various variables being >> tested to >> > bool >> > >> > My preference is to do (2) as much as possible; any case that >> cannot be >> > put in a boolean form without having major changes to the code >> base, I'd >> > leave as is. And then call it a day for this subject. >> > >> > What do you think (ie in cases where the variable can be set to >> a bool, >> > do it and then have the test be an implicit test)? >> >> It's really up to you. It seems a lot of work and I don't know if you >> can actually push this all the way through without needing some >> int<->bool conversion somewhere anyway. >> >> Cheers, >> David >> >> > Thanks! >> > Jc >> > >> > On Tue, Jan 8, 2019 at 10:31 PM David Holmes >> >> > > >> wrote: >> > >> >? ? ?Hi Jc, >> > >> >? ? ?On 9/01/2019 4:12 pm, JC Beyler wrote: >> >? ? ? > Hi all, >> >? ? ? > >> >? ? ? > Fixing up the tests in vmTestbase to not be testing >> explicitly >> >? ? ?against >> >? ? ? > NSK_TRUE/NSK_FALSE. Here is the webrev to do that: >> >? ? ? > >> >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 >> >? ? ? > Webrev: >> http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ >> > >> >? ? ?Hold up! We don't do explicit tests when the variable is a >> bool/boolean >> >? ? ?but when it is an int, as here, we do. >> > >> >? ? ?Are you planning on converting everything to use bool? >> > >> >? ? ?Cheers, >> >? ? ?David >> > >> >? ? ? > Thanks, >> >? ? ? > Jc >> > >> > >> > >> > -- >> > >> > Thanks, >> > Jc >> >> >> >> -- >> >> Thanks, >> Jc > > From chris.plummer at oracle.com Sun Jan 13 19:28:38 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Sun, 13 Jan 2019 11:28:38 -0800 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: <6b05387e-ed15-4c24-45f4-30f1bb638cbc@oracle.com> References: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> <50b8c141-860e-6787-d9d8-e2ab79392ce8@oracle.com> <3b1791e4-8835-5b6a-21d8-0c7ca8beb68c@oracle.com> <6b05387e-ed15-4c24-45f4-30f1bb638cbc@oracle.com> Message-ID: <04e37dc2-a56d-a68d-1bb6-39fcf99aead8@oracle.com> On 1/13/19 4:14 AM, David Holmes wrote: > On 13/01/2019 8:33 am, Chris Plummer wrote: >> Hi JC and David, >> >> Sorry I'm late here. Was out most of the week. I assume by "implicit >> boolean" that David means treating an int as a boolean when the the >> int could potentially contain a value other than 0 or 1? So if we have: > > The style guide [1] states: > > "Do not use ints or pointers as booleans with &&, ||, if, while. > Instead, compare explicitly != 0 or != NULL, etc. (See #8 above.)" > >> >> ?????? int success; >> ???? ... >> ?????? if (success != NSK_TRUE) { >> >> You feel the check against NSK_TRUE is needed, and using !success >> would potentially yield an incorrect evaluation of the "boolean". > > No it isn't a correctness issue (though obviously you can use an int > incorrectly in such a context) it's a style issue. We regularly > eradicate implicit booleans so it is inappropriate to introduce them > here. Ok, but the above code is still incorrect. At least !success would have always have given you the right result, so in this case the rule to add an explicit comparison has lead to a bug (although in reality it a bug that is never exposed). It should be "success == NSK_FALSE". Chris > > David > ----- > > [1] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > > ?Well, if >> success is not 0 or 1, then let's say it is 2. You end up with 2 != >> NSK_TRUE, which evaluations true. Compared with !2 which evaluations >> false. So clearly there is a difference, but which would you consider >> correct in this case? I'd consider the false evaluation correct. If >> success is not 0, we want !success to be false. But if you compare >> against NSK_TRUE, the evaluation only ends up being false when >> success == 1. This doesn't seem right to me, so I would argue that >> "success != NSK_TRUE" is not only clumsy coding, but also gives the >> wrong result for values other than 0 or 1. In order to correct it,? >> you would use "success == NSK_FALSE". But I don't understand the >> implicit boolean concern with !success when the value is suppose to >> always be 0 or 1. Where I would object to do something like this is >> with pointer types. Using !ptr is bad. "ptr == NULL" should be used. >> >> That being said, if JC prefers to clean this up at a later date as >> part of changing success to a bool, that's fine by mean also. >> >> thanks, >> >> Chris >> >> >> On 1/10/19 9:20 PM, JC Beyler wrote: >>> Hi David, >>> >>> Fair enough. I looked a bit to doing it anyway? and it is >>> self-contained in a lot of cases but a lot of times the work would >>> be greatly simplified if we first factorized utility methods across >>> test suites first and then (or at the same time) moved them to using >>> bools and not doing the explicit tests. >>> >>> So, except if? anyone? objects, I'm closing this bug as won't fix >>> and I created https://bugs.openjdk.java.net/browse/JDK-8216533 and >>> https://bugs.openjdk.java.net/browse/JDK-8216534?for the >>> events/hotswap tests which were the most cases of this anyway. >>> >>> Thanks for the hold up David :-), >>> Jc >>> >>> On Tue, Jan 8, 2019 at 11:14 PM David Holmes >>> > wrote: >>> >>> ??? On 9/01/2019 4:43 pm, JC Beyler wrote: >>> ??? > Hi David, >>> ??? > >>> ??? > I was not planning on doing it but we could. This change came >>> ??? from a >>> ??? > request to remove the booleans from tests for a prior webrev >>> ??? change. >>> ??? > I've seen previous conversations about wanting to test explicitly >>> ??? > against JNI_TRUE but thought this was a slightly different case. >>> >>> ??? The basic hotspot style rule is "avoid implicit booleans". >>> >>> ??? > Basically, from your comment, it seems I could go three ways for >>> ??? this >>> ??? > change: >>> ??? >? ? 1) Not do it and close the bug as won't fix :-) >>> >>> ??? Certainly the path of least resistance. :) >>> >>> ??? >? ? 2) Go the extra step and change the various variables being >>> ??? tested to >>> ??? > bool >>> ??? > >>> ??? > My preference is to do (2) as much as possible; any case that >>> ??? cannot be >>> ??? > put in a boolean form without having major changes to the code >>> ??? base, I'd >>> ??? > leave as is. And then call it a day for this subject. >>> ??? > >>> ??? > What do you think (ie in cases where the variable can be set to >>> ??? a bool, >>> ??? > do it and then have the test be an implicit test)? >>> >>> ??? It's really up to you. It seems a lot of work and I don't know >>> if you >>> ??? can actually push this all the way through without needing some >>> ??? int<->bool conversion somewhere anyway. >>> >>> ??? Cheers, >>> ??? David >>> >>> ??? > Thanks! >>> ??? > Jc >>> ??? > >>> ??? > On Tue, Jan 8, 2019 at 10:31 PM David Holmes >>> ??? >>> ??? > >> ??? >> wrote: >>> ??? > >>> ??? >? ? ?Hi Jc, >>> ??? > >>> ??? >? ? ?On 9/01/2019 4:12 pm, JC Beyler wrote: >>> ??? >? ? ? > Hi all, >>> ??? >? ? ? > >>> ??? >? ? ? > Fixing up the tests in vmTestbase to not be testing >>> ??? explicitly >>> ??? >? ? ?against >>> ??? >? ? ? > NSK_TRUE/NSK_FALSE. Here is the webrev to do that: >>> ??? >? ? ? > >>> ??? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 >>> ??? >? ? ? > Webrev: >>> ??? http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ >>> ??? > >>> ??? >? ? ?Hold up! We don't do explicit tests when the variable is a >>> ??? bool/boolean >>> ??? >? ? ?but when it is an int, as here, we do. >>> ??? > >>> ??? >? ? ?Are you planning on converting everything to use bool? >>> ??? > >>> ??? >? ? ?Cheers, >>> ??? >? ? ?David >>> ??? > >>> ??? >? ? ? > Thanks, >>> ??? >? ? ? > Jc >>> ??? > >>> ??? > >>> ??? > >>> ??? > -- >>> ??? > >>> ??? > Thanks, >>> ??? > Jc >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> >> From david.holmes at oracle.com Sun Jan 13 21:06:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2019 07:06:01 +1000 Subject: RFR (M) 8212959: Remove booleans from tests in vmTestbase In-Reply-To: <04e37dc2-a56d-a68d-1bb6-39fcf99aead8@oracle.com> References: <73d7bd20-c260-b2d2-efc1-58d97f2f4bf1@oracle.com> <50b8c141-860e-6787-d9d8-e2ab79392ce8@oracle.com> <3b1791e4-8835-5b6a-21d8-0c7ca8beb68c@oracle.com> <6b05387e-ed15-4c24-45f4-30f1bb638cbc@oracle.com> <04e37dc2-a56d-a68d-1bb6-39fcf99aead8@oracle.com> Message-ID: <60fd5819-5c47-1dfe-5481-3e152b987ce6@oracle.com> On 14/01/2019 5:28 am, Chris Plummer wrote: > On 1/13/19 4:14 AM, David Holmes wrote: >> On 13/01/2019 8:33 am, Chris Plummer wrote: >>> Hi JC and David, >>> >>> Sorry I'm late here. Was out most of the week. I assume by "implicit >>> boolean" that David means treating an int as a boolean when the the >>> int could potentially contain a value other than 0 or 1? So if we have: >> >> The style guide [1] states: >> >> "Do not use ints or pointers as booleans with &&, ||, if, while. >> Instead, compare explicitly != 0 or != NULL, etc. (See #8 above.)" >> >>> >>> ?????? int success; >>> ???? ... >>> ?????? if (success != NSK_TRUE) { >>> >>> You feel the check against NSK_TRUE is needed, and using !success >>> would potentially yield an incorrect evaluation of the "boolean". >> >> No it isn't a correctness issue (though obviously you can use an int >> incorrectly in such a context) it's a style issue. We regularly >> eradicate implicit booleans so it is inappropriate to introduce them >> here. > > Ok, but the above code is still incorrect. At least !success would have > always have given you the right result, so in this case the rule to add > an explicit comparison has lead to a bug (although in reality it a bug > that is never exposed). It should be "success == NSK_FALSE". That's a weird attempted justification. If "success" is not initialized or can take on any value other than NSK_TRUE or NSK_FALSE then that is a logic bug pure and simple and its irrelevant how success is tested in a condition. Not that these tests would have been written to the hotspot style guide in the first place. This all goes back to these basically being C-style tests with no C++ bool used. David > > Chris > >> >> David >> ----- >> >> [1] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >> >> ?Well, if >>> success is not 0 or 1, then let's say it is 2. You end up with 2 != >>> NSK_TRUE, which evaluations true. Compared with !2 which evaluations >>> false. So clearly there is a difference, but which would you consider >>> correct in this case? I'd consider the false evaluation correct. If >>> success is not 0, we want !success to be false. But if you compare >>> against NSK_TRUE, the evaluation only ends up being false when >>> success == 1. This doesn't seem right to me, so I would argue that >>> "success != NSK_TRUE" is not only clumsy coding, but also gives the >>> wrong result for values other than 0 or 1. In order to correct it, >>> you would use "success == NSK_FALSE". But I don't understand the >>> implicit boolean concern with !success when the value is suppose to >>> always be 0 or 1. Where I would object to do something like this is >>> with pointer types. Using !ptr is bad. "ptr == NULL" should be used. >>> >>> That being said, if JC prefers to clean this up at a later date as >>> part of changing success to a bool, that's fine by mean also. >>> >>> thanks, >>> >>> Chris >>> >>> >>> On 1/10/19 9:20 PM, JC Beyler wrote: >>>> Hi David, >>>> >>>> Fair enough. I looked a bit to doing it anyway? and it is >>>> self-contained in a lot of cases but a lot of times the work would >>>> be greatly simplified if we first factorized utility methods across >>>> test suites first and then (or at the same time) moved them to using >>>> bools and not doing the explicit tests. >>>> >>>> So, except if? anyone? objects, I'm closing this bug as won't fix >>>> and I created https://bugs.openjdk.java.net/browse/JDK-8216533 and >>>> https://bugs.openjdk.java.net/browse/JDK-8216534?for the >>>> events/hotswap tests which were the most cases of this anyway. >>>> >>>> Thanks for the hold up David :-), >>>> Jc >>>> >>>> On Tue, Jan 8, 2019 at 11:14 PM David Holmes >>>> > wrote: >>>> >>>> ??? On 9/01/2019 4:43 pm, JC Beyler wrote: >>>> ??? > Hi David, >>>> ??? > >>>> ??? > I was not planning on doing it but we could. This change came >>>> ??? from a >>>> ??? > request to remove the booleans from tests for a prior webrev >>>> ??? change. >>>> ??? > I've seen previous conversations about wanting to test explicitly >>>> ??? > against JNI_TRUE but thought this was a slightly different case. >>>> >>>> ??? The basic hotspot style rule is "avoid implicit booleans". >>>> >>>> ??? > Basically, from your comment, it seems I could go three ways for >>>> ??? this >>>> ??? > change: >>>> ??? >? ? 1) Not do it and close the bug as won't fix :-) >>>> >>>> ??? Certainly the path of least resistance. :) >>>> >>>> ??? >? ? 2) Go the extra step and change the various variables being >>>> ??? tested to >>>> ??? > bool >>>> ??? > >>>> ??? > My preference is to do (2) as much as possible; any case that >>>> ??? cannot be >>>> ??? > put in a boolean form without having major changes to the code >>>> ??? base, I'd >>>> ??? > leave as is. And then call it a day for this subject. >>>> ??? > >>>> ??? > What do you think (ie in cases where the variable can be set to >>>> ??? a bool, >>>> ??? > do it and then have the test be an implicit test)? >>>> >>>> ??? It's really up to you. It seems a lot of work and I don't know >>>> if you >>>> ??? can actually push this all the way through without needing some >>>> ??? int<->bool conversion somewhere anyway. >>>> >>>> ??? Cheers, >>>> ??? David >>>> >>>> ??? > Thanks! >>>> ??? > Jc >>>> ??? > >>>> ??? > On Tue, Jan 8, 2019 at 10:31 PM David Holmes >>>> ??? >>>> ??? > >>> ??? >> wrote: >>>> ??? > >>>> ??? >? ? ?Hi Jc, >>>> ??? > >>>> ??? >? ? ?On 9/01/2019 4:12 pm, JC Beyler wrote: >>>> ??? >? ? ? > Hi all, >>>> ??? >? ? ? > >>>> ??? >? ? ? > Fixing up the tests in vmTestbase to not be testing >>>> ??? explicitly >>>> ??? >? ? ?against >>>> ??? >? ? ? > NSK_TRUE/NSK_FALSE. Here is the webrev to do that: >>>> ??? >? ? ? > >>>> ??? >? ? ? > Bug: https://bugs.openjdk.java.net/browse/JDK-8212959 >>>> ??? >? ? ? > Webrev: >>>> ??? http://cr.openjdk.java.net/~jcbeyler/8212959/webrev.00/ >>>> ??? > >>>> ??? >? ? ?Hold up! We don't do explicit tests when the variable is a >>>> ??? bool/boolean >>>> ??? >? ? ?but when it is an int, as here, we do. >>>> ??? > >>>> ??? >? ? ?Are you planning on converting everything to use bool? >>>> ??? > >>>> ??? >? ? ?Cheers, >>>> ??? >? ? ?David >>>> ??? > >>>> ??? >? ? ? > Thanks, >>>> ??? >? ? ? > Jc >>>> ??? > >>>> ??? > >>>> ??? > >>>> ??? > -- >>>> ??? > >>>> ??? > Thanks, >>>> ??? > Jc >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >>> > > From jini.george at oracle.com Mon Jan 14 05:06:38 2019 From: jini.george at oracle.com (Jini George) Date: Mon, 14 Jan 2019 10:36:38 +0530 Subject: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: <2F096216-56CA-4092-9B64-2E42FDE5D2D5@amazon.com> References: <2F096216-56CA-4092-9B64-2E42FDE5D2D5@amazon.com> Message-ID: <9c6aab57-260f-d551-4314-c3c33d45bd29@oracle.com> Thank you very much, Paul for the review. Yes, this is only needed for OSX. Thanks, Jini. On 1/12/2019 5:41 AM, Hohensee, Paul wrote: > A more generic approach that doesn?t check for a specific platform in ClhsdbLauncher.java would be nice, e.g., add a checkForPrivileges() method to Platform, but if OSX is the only platform that needs the check, I'm ok with this patch. > > Thanks, > > Paul > > ?On 1/10/19, 8:16 PM, "serviceability-dev on behalf of Jini George" wrote: > > Thanks again, JC! :-) > > Folks, Could I please get one more review on this ? > > -Jini. > > On 1/11/2019 9:38 AM, JC Beyler wrote: > > Hi Jini, > > > > Looks good to me now :) Thanks for handling the comments :) > > Jc > > > > > > On Tue, Jan 8, 2019 at 8:11 PM Jini George > > wrote: > > > > Thank you very much for the review, JC. My comments inline: > > > > On 1/8/2019 12:22 AM, JC Beyler wrote: > > > > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html > > > + // by appending 'sudo' to it. Check now if sudo > > > passes in this > > > + // environment with a simple 'echo' command. > > > -> Really shouldn't provide implementation details about > > what is > > > being done by that method; if we change that, this comment will > > rot :-) > > > canAddPrivileges is explicit enough in my mind > > > > Done. I have removed the comment. > > > > > > > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/test/lib/SA/SATestUtils.java.html > > > > > > > > -> You put some System.out.println; are they intended to > > still be > > > there or were they for debug? > > > > I guess you meant this one: > > System.out.println("Adding 'sudo -E' to the command."); > > > > This one is meant to be there. > > > > > > > > > > > 77 for (String val: cmdStringList) { > > > 78 outStringList.add(val); > > > 79 } > > > > > > > > > Couldn't we use addAll ? > > > > Done. > > The modified webrev is at: > > > > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html > > > > Thanks, > > Jini. > > > > > > > > > > > > -- > > > > Thanks, > > Jc > > From sharath.ballal at oracle.com Mon Jan 14 05:09:20 2019 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Sun, 13 Jan 2019 21:09:20 -0800 (PST) Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> <2b441c90-c926-4286-9ca7-889f1fc0b4b6@default> Message-ID: <352700a5-6e1b-4c72-9ff1-a9710fb5170e@default> Thanks for the clarification Jini. Thanks, Sharath -----Original Message----- From: Jini George Sent: Monday, January 14, 2019 10:38 AM To: Sharath Ballal; JC Beyler; serviceability-dev at openjdk.java.net Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 Thank you very much, Sharath, for the review. My comments inline. On 1/12/2019 3:38 PM, Sharath Ballal wrote: > Hi Jini, > > ClhsdbLauncher.java > 1. Is the platform check not required in case of core files ? No, it is not needed. The permission issues don't exist. > - if (!Platform.shouldSAAttach()) { > - // Silently skip the test if we don't have enough permissions to attach > - System.out.println("SA attach not expected to work - test skipped."); > - return null; > - } > - > > 2. Nit: extra line at 135 Done. Thanks, Jini. > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Friday, January 11, 2019 9:46 AM > To: JC Beyler; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo > privileges to enable MacOS tests on Mach5 > > Thanks again, JC! :-) > > Folks, Could I please get one more review on this ? > > -Jini. > > On 1/11/2019 9:38 AM, JC Beyler wrote: >> Hi Jini, >> >> Looks?good to me now :) Thanks for handling the comments :) Jc >> >> >> On Tue, Jan 8, 2019 at 8:11 PM Jini George > > wrote: >> >> Thank you very much for the review, JC. My comments inline: >> >> On 1/8/2019 12:22 AM, JC Beyler wrote: >> > >> > >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html >> >? ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check now if sudo >> > passes in this >> >? ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' command. >> >? ? ? ?-> Really shouldn't provide implementation details about >> what is >> > being done by that method; if we change that, this comment will >> rot :-) >> > canAddPrivileges is explicit enough in my mind >> >> Done. I have removed the comment. >> >> > >> > >> >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/te >> s >> t/lib/SA/SATestUtils.java.html >> >> > >> >? ? ? -> You put some System.out.println; are they intended to >> still be >> > there or were they for debug? >> >> I guess you meant this one: >> System.out.println("Adding 'sudo -E' to the command."); >> >> This one is meant to be there. >> >> > >> > >> >? ? 77? ? ? ? ?for (String val: cmdStringList) { >> >? ? 78? ? ? ? ? ? ?outStringList.add(val); >> >? ? 79? ? ? ? ?} >> > >> > >> > Couldn't we use addAll ? >> >> Done. >> The modified webrev is at: >> >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html >> >> Thanks, >> Jini. >> >> >> >> >> >> -- >> >> Thanks, >> Jc From jini.george at oracle.com Mon Jan 14 05:08:04 2019 From: jini.george at oracle.com (Jini George) Date: Mon, 14 Jan 2019 10:38:04 +0530 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: <2b441c90-c926-4286-9ca7-889f1fc0b4b6@default> References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> <2b441c90-c926-4286-9ca7-889f1fc0b4b6@default> Message-ID: Thank you very much, Sharath, for the review. My comments inline. On 1/12/2019 3:38 PM, Sharath Ballal wrote: > Hi Jini, > > ClhsdbLauncher.java > 1. Is the platform check not required in case of core files ? No, it is not needed. The permission issues don't exist. > - if (!Platform.shouldSAAttach()) { > - // Silently skip the test if we don't have enough permissions to attach > - System.out.println("SA attach not expected to work - test skipped."); > - return null; > - } > - > > 2. Nit: extra line at 135 Done. Thanks, Jini. > > > Thanks, > Sharath > > > -----Original Message----- > From: Jini George > Sent: Friday, January 11, 2019 9:46 AM > To: JC Beyler; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 > > Thanks again, JC! :-) > > Folks, Could I please get one more review on this ? > > -Jini. > > On 1/11/2019 9:38 AM, JC Beyler wrote: >> Hi Jini, >> >> Looks?good to me now :) Thanks for handling the comments :) Jc >> >> >> On Tue, Jan 8, 2019 at 8:11 PM Jini George > > wrote: >> >> Thank you very much for the review, JC. My comments inline: >> >> On 1/8/2019 12:22 AM, JC Beyler wrote: >> > >> > >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java.udiff.html >> >? ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check now if sudo >> > passes in this >> >? ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' command. >> >? ? ? ?-> Really shouldn't provide implementation details about >> what is >> > being done by that method; if we change that, this comment will >> rot :-) >> > canAddPrivileges is explicit enough in my mind >> >> Done. I have removed the comment. >> >> > >> > >> >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/tes >> t/lib/SA/SATestUtils.java.html >> >> > >> >? ? ? -> You put some System.out.println; are they intended to >> still be >> > there or were they for debug? >> >> I guess you meant this one: >> System.out.println("Adding 'sudo -E' to the command."); >> >> This one is meant to be there. >> >> > >> > >> >? ? 77? ? ? ? ?for (String val: cmdStringList) { >> >? ? 78? ? ? ? ? ? ?outStringList.add(val); >> >? ? 79? ? ? ? ?} >> > >> > >> > Couldn't we use addAll ? >> >> Done. >> The modified webrev is at: >> >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html >> >> Thanks, >> Jini. >> >> >> >> >> >> -- >> >> Thanks, >> Jc From gunter.haug at sap.com Mon Jan 14 15:58:49 2019 From: gunter.haug at sap.com (Haug, Gunter) Date: Mon, 14 Jan 2019 15:58:49 +0000 Subject: [RFR]: Per thread IO statistics in JFR Message-ID: Hi All, Could I please have a review and possibly some opinions on the following enhancement to JFR and the JDK? At SAP we have a per thread IO statistic among our supportability enhancements which proved to be very helpful for our support engineers. It might be beneficial for JFR as well and would certainly help us to drive adoption of OpenJDK. The basic idea is simple, we have added fields to the thread class where the number of bytes read and written from/to file and network are counted in. The newly created JFR events are written periodically as for example the ThreadAllocationStatistics event already is. In order to collect the data, we have added hooks to the JDK C coding calling back into the VM. I have opened a bug here: https://bugs.openjdk.java.net/browse/JDK-8216981 Here is a webrev: http://cr.openjdk.java.net/~ghaug/webrevs/8216981 There are no tests yet and the code be a bit nicer in places. We will work on this if/when this feature is deemed acceptable. Finally, we have an API in our SAP version of the JDK to access this data from a Java application. This is used by many SAP applications and I think we could add an MXBean in a second step, to provide similar functionality. Thanks in advance, Gunter From sgehwolf at redhat.com Mon Jan 14 18:37:24 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 14 Jan 2019 19:37:24 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: <1e00465492be30d392743973165341ae6e77bcd9.camel@redhat.com> cc-ing hotspot-jfr-dev On Mon, 2019-01-14 at 15:58 +0000, Haug, Gunter wrote: > Hi All, > > Could I please have a review and possibly some opinions on the > following enhancement to JFR and the JDK? > > At SAP we have a per thread IO statistic among our supportability > enhancements which proved to be very helpful for our support > engineers. It might be beneficial for JFR as well and would certainly > help us to drive adoption of OpenJDK. > > The basic idea is simple, we have added fields to the thread class > where the number of bytes read and written from/to file and network > are counted in. The newly created JFR events are written periodically > as for example the ThreadAllocationStatistics event already is. > > In order to collect the data, we have added hooks to the JDK C coding > calling back into the VM. > > I have opened a bug here: > https://bugs.openjdk.java.net/browse/JDK-8216981 > > Here is a webrev: > http://cr.openjdk.java.net/~ghaug/webrevs/8216981 > > There are no tests yet and the code be a bit nicer in places. We will > work on this if/when this feature is deemed acceptable. > > Finally, we have an API in our SAP version of the JDK to access this > data from a Java application. This is used by many SAP applications > and I think we could add an MXBean in a second step, to provide > similar functionality. > > Thanks in advance, > Gunter > > > > From erik.gahlin at oracle.com Mon Jan 14 21:31:46 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Mon, 14 Jan 2019 22:31:46 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: Hi Gunter, Sounds like a useful enhancement! Do you have an idea of what the overhead might be? Does it work on Mac OS X? I haven't done a proper review, but you could change the contentType to "bits-per-second?. That is what we use for the Network Utilization event which reports statistics per interface. Thanks Erik > Hi All, > > Could I please have a review and possibly some opinions on the following enhancement to JFR and the JDK? > > At SAP we have a per thread IO statistic among our supportability enhancements which proved to be very helpful for our support engineers. It might be beneficial for JFR as well and would certainly help us to drive adoption of OpenJDK. > > The basic idea is simple, we have added fields to the thread class where the number of bytes read and written from/to file and network are counted in. The newly created JFR events are written periodically as for example the ThreadAllocationStatistics event already is. > > In order to collect the data, we have added hooks to the JDK C coding calling back into the VM. > > I have opened a bug here: > https://bugs.openjdk.java.net/browse/JDK-8216981 > > Here is a webrev: > http://cr.openjdk.java.net/~ghaug/webrevs/8216981 > > There are no tests yet and the code be a bit nicer in places. We will work on this if/when this feature is deemed acceptable. > > Finally, we have an API in our SAP version of the JDK to access this data from a Java application. This is used by many SAP applications and I think we could add an MXBean in a second step, to provide similar functionality. > > Thanks in advance, > Gunter > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon Jan 14 21:56:16 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 14 Jan 2019 13:56:16 -0800 Subject: RFR (S) 8212824: Remove unnecessary spaces before/after comparison in vmTestbase In-Reply-To: References: Message-ID: Looks good --alex On 01/08/2019 18:59, JC Beyler wrote: > Hi all, > > Could I get a review for a small-ish webrev that only changes > white-spaces (or removes unnecessary new lines): > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212824 > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212824/webrev.00/ > > Thanks, > Jc From hohensee at amazon.com Mon Jan 14 23:03:57 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Mon, 14 Jan 2019 23:03:57 +0000 Subject: RFR (S) 8212824: Remove unnecessary spaces before/after comparison in vmTestbase In-Reply-To: References: Message-ID: +1. Paul ?On 1/14/19, 1:56 PM, "serviceability-dev on behalf of Alex Menkov" wrote: Looks good --alex On 01/08/2019 18:59, JC Beyler wrote: > Hi all, > > Could I get a review for a small-ish webrev that only changes > white-spaces (or removes unnecessary new lines): > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212824 > Webrev: http://cr.openjdk.java.net/~jcbeyler/8212824/webrev.00/ > > Thanks, > Jc From gunter.haug at sap.com Tue Jan 15 10:12:03 2019 From: gunter.haug at sap.com (Haug, Gunter) Date: Tue, 15 Jan 2019 10:12:03 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: Hi Erik, the overhead is very small. In fact, I wasn?t able to measure it in a reproduceable way. And yes, it works on Mac OS, I use a Mac. > could change the contentType to "bits-per-second?. That is what we use for the Network Utilization event which reports statistics per interface. Yes, I can do that. Only for the network IO or for file IO as well? Thanks for looking into this, Gunter From: serviceability-dev on behalf of Erik Gahlin Date: Monday, 14. January 2019 at 22:32 To: "serviceability-dev at openjdk.java.net" , "hotspot-jfr-dev at openjdk.java.net" Subject: Re: [RFR]: Per thread IO statistics in JFR Hi Gunter, Sounds like a useful enhancement! Do you have an idea of what the overhead might be?? Does it work on Mac OS X? I haven't done a proper review, but you could change the contentType to "bits-per-second?. That is what we use for the Network Utilization event which reports statistics per interface. Thanks Erik Hi All, Could I please have a review and possibly some opinions on the following enhancement to JFR and the JDK? At SAP we have a per thread IO statistic among our supportability enhancements which proved to be very helpful for our support engineers. It might be beneficial for JFR as well and would certainly help us to drive adoption of OpenJDK. The basic idea is simple, we have added fields to the thread class where the number of bytes read and written from/to file and network are counted in. The newly created JFR events are written periodically as for example the ThreadAllocationStatistics event already is. In order to collect the data, we have added hooks to the JDK C coding calling back into the VM. I have opened a bug here: https://bugs.openjdk.java.net/browse/JDK-8216981 Here is a webrev: http://cr.openjdk.java.net/~ghaug/webrevs/8216981 There are no tests yet and the code be a bit nicer in places. We will work on this if/when this feature is deemed acceptable. Finally, we have an API in our SAP version of the JDK to access this data from a Java application. This is used by many SAP applications and I think we could add an MXBean in a second step, to provide similar functionality. Thanks in advance, Gunter From yasuenag at gmail.com Tue Jan 15 12:04:42 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 15 Jan 2019 21:04:42 +0900 Subject: PING: RFR: 8181313: SA: Remove libthread_db dependency on Linux In-Reply-To: References: <7419f616-31d4-4aef-f982-bc14f09b4ca6@oracle.com> <2efdc891-bd4a-ff13-fedc-fa9ae11e0b8a@gmail.com> <9f8a615d-9caa-936f-f439-e3d47ba313fd@oracle.com> Message-ID: <6e245a2c-a308-1ee5-b0ca-f8fa2f91411b@gmail.com> PING: Could you review it? We need one more reviewer. > http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.02/ Thanks, Yasumasa On 2019/01/11 11:51, Yasumasa Suenaga wrote: > Hi Jini, > > I removed ps_get_thread_area() in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.02/ > > Diff from webrev.01 is here: > > http://hg.openjdk.java.net/jdk/submit/rev/691a931ae2ba > > > Thanks, > > Yasumasa > > > 2019?1?11?(?) 1:05 Jini George : >> >> Thanks, Yasumasa, but I meant removing the declaration and definition of >> ps_get_thread_area() also. I don't think it is needed anymore. >> >> Thanks, >> Jini. >> >> On 1/10/2019 6:50 PM, Yasumasa Suenaga wrote: >>> Hi Jini, >>> >>> Thank you for your comment. >>> I uploaded a new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.01/ >>> >>> It passed tests on submit repo. >>> Could you review again? >>> >>> >>> Yasumasa >>> >>> >>> On 2019/01/10 15:10, Jini George wrote: >>>> Thank you for implementing this change, Yasumasa. It looks good to me. >>>> Just a nit. >>>> >>>> ==> linux/native/libsaproc/libproc_impl.c >>>> Could you please remove these lines ? I don't think these are needed >>>> anymore. >>>> >>>> 421 >>>> 422 // new libthread_db of NPTL seem to require this symbol >>>> 423 JNIEXPORT ps_err_e JNICALL >>>> 424 ps_get_thread_area() { >>>> 425 print_debug("ps_get_thread_area not implemented\n"); >>>> 426 return PS_OK; >>>> 427 } >>>> >>>> ==> linux/native/libsaproc/proc_service.h >>>> Could you please remove these lines too ? >>>> 79 >>>> 80 // new libthread_db of NPTL seem to require this symbol >>>> 81 JNIEXPORT ps_err_e JNICALL >>>> 82 ps_get_thread_area(); >>>> >>>> Thanks, >>>> Jini. >>>> >>>> >>>> >>>> On 1/9/2019 6:53 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181313 >>>>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.00/ >>>>> >>>>> It has passed all tests on submit repo, and serviceability/sa tests on >>>>> Linux x64. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumas >>>>> From jini.george at oracle.com Wed Jan 16 04:29:51 2019 From: jini.george at oracle.com (Jini George) Date: Wed, 16 Jan 2019 09:59:51 +0530 Subject: RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher In-Reply-To: References: <92017316-89fd-a3bf-3b2e-5c76c443c62a@oracle.com> <6d32da60-8042-55c4-3fca-14b003b84097@oracle.com> Message-ID: <2744c4d7-a75b-a916-9b6a-e746cc6c3e50@oracle.com> 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 Wed Jan 16 15:48:53 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 16 Jan 2019 10:48:53 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <5C38E618.3020904@oracle.com> Message-ID: <5C3F5265.2090709@oracle.com> Looking through the test history for the vm/mlvm version of InstallSDE.java there has never been a reported problem with the renameTo operation. I'm inclined to not apply the change made to the com/sun/jdi/sde test until the failure is observed. I'm satisfied with the testing at this point and could use another reviewer before pushing. On 1/11/19, 6:14 PM, David Holmes wrote: > Hi Gary, > > As I mentioned earlier there are two versions of InstallSDE.java in > the tests, so both should be updated. > > Your strategy to avoid the windows delete issue seems reasonable. > > David > > On 12/01/2019 4:53 am, Gary Adams wrote: >> Here's a webrev for review purposes. >> No failures after ~1000 testruns. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >> >> On 1/11/19, 11:01 AM, Gary Adams wrote: >>> I've been reading recently that Windows delete file operations >>> can be delayed, if there are open handles against the file. >>> Others have reported virus checkers or other indexing >>> programs may hold a handle on a file preventing the >>> deletion being completed. >>> >>> The basic logic in InstallSDE is >>> A + B = C >>> delete A >>> rename C to A >>> >>> I think we can work around the issue with >>> rename A to A1 >>> A1 + B = C >>> delete A1 >>> rename C to A >>> >>> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>> @@ -31,9 +31,17 @@ >>> } >>> >>> static void install(File inOutClassFile, File attrFile) throws >>> IOException { >>> - File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >>> - new InstallSDE(inOutClassFile, attrFile, tmpFile); >>> - if (!inOutClassFile.delete()) { >>> + File tmpFile = new File(inOutClassFile.getPath() + "tmp-out"); >>> + File tmpInOutClassFile = new File(inOutClassFile.getPath() >>> + "tmp-in"); >>> + >>> + // Workaround delayed file deletes on Windows using a tmp >>> file name >>> + if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >>> + throw new IOException("tmp copy of inOutClassFile >>> failed"); >>> + } >>> + >>> + new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >>> + >>> + if (!tmpInOutClassFile.delete()) { >>> throw new IOException("inOutClassFile.delete() failed"); >>> } >>> if (!tmpFile.renameTo(inOutClassFile)) { >>> >>> >>> Testing in progress ... >>> >>> On 1/11/19, 7:40 AM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg >>>>> agent communication issue with SourceDebugExtension. >>>>> >>>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>> >>>>> >>>>> >>>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>>> at InstallSDE.install(InstallSDE.java:40) >>>>> at MangleTest.testSetUp(MangleTest.java:38) >>>>> at MangleTest.main(MangleTest.java:31) >>>> >>>> You might want to add some code in: >>>> >>>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>>> >>>> >>>> that checks the result of _wrename to see what error is occurring. >>>> I suspect it will be EACCES which won't be that helpful: >>>> >>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>>> >>>> >>>> but it would be good to confirm. >>>> >>>>> >>>>> result: Error. Agent communication error: >>>>> java.io.IOException:*Agent: unexpected op: 71;* check console log >>>>> for any additional details >>>>> >>>>> I added some additional print outs for the rename issue and have >>>>> run ~2000 additional >>>>> testruns with no test failures repeated, yet. But there were 2 >>>>> mach5 reported errors: >>>>> >>>>> TimeoutException in CLEANUP. >>>> >>>> That's a mach5 issue. >>>> >>>> David >>>> >>>>> >>>>> I'll do some more investigation with making the rename operation >>>>> more robust >>>>> before removing SourceDebugExtensionTest from the problem list. >>>>> >>>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>>> Hi Gary, >>>>>> >>>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>>>> The test does not appear to fail on the current mach5 test systems. >>>>>>> There was some question concerning symbolic links that might have >>>>>>> been problematic at that time. Additional testing in progress... >>>>>> >>>>>> Also note that there are two sets of SDE related tests and two >>>>>> versions of the InstallSDE.java file that both use renameTo. In >>>>>> nsk the testcase seems to be: >>>>>> >>>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>>> >>>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>>> reasonable to me. It was most like a concurrency issue with the >>>>>> virus scanner. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>>> >>>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>>> --- a/test/jdk/ProblemList.txt >>>>>>> +++ b/test/jdk/ProblemList.txt >>>>>>> @@ -838,8 +838,6 @@ >>>>>>> >>>>>>> com/sun/jdi/RepStep.java 8043571 generic-all >>>>>>> >>>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>>>>> - >>>>>>> com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>>> >>>>> >>> >> From martin.doerr at sap.com Wed Jan 16 15:57:59 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Jan 2019 15:57:59 +0000 Subject: getPCDescNearDbg returns incorrect PCDesc In-Reply-To: References: Message-ID: <1ed2e1d3cc6943e3be9bcc9551af5fe3@sap.com> Hi David, re-posting to serviceability mailing list since you're referring to a method from https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of David Griffiths Sent: Mittwoch, 16. Januar 2019 12:08 To: hotspot-dev at openjdk.java.net Subject: getPCDescNearDbg returns incorrect PCDesc Hi, I'd like some help please understanding what appears to be a bug in getPCDescNearDbg. The problem is caused by the fact that the _pc_offset value stored in a PcDesc is actually the offset of the code contained in the _next_ PcDesc rather than the current one. I assume it's done like this so that obtaining stack traces works correctly. At least on x86, the last instruction in a PcDesc chunk is the callq which means that the return address pc points to the next PcDesc. Therefore associating the PcDesc containing the callq with the address of the next PcDesc chunk means that the matching works in getPCDescAt. But this causes "off by one" errors in getPCDescNearDbg which appears to expect the PcDesc getRealPC address to be that of the PcDesc itself rather than the following one. So you sometimes see incorrect top of stack line numbers when debugging. (And this would presumably also affect profilers). I can fix the top of stack issue by changing distance to: long distance = pcDesc.getRealPC(this).minus(pc) - 1 but this then messes up the line numbers further down the stack because they are trying to match against return pcs. Anybody come across this before, is my analysis correct? Cheers, David From daniel.daugherty at oracle.com Wed Jan 16 16:24:32 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 16 Jan 2019 11:24:32 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <5C38BDDD.80602@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> Message-ID: <52c92281-8687-1367-711a-dcafed7fe106@oracle.com> > rename A to A1 I believe the virus scanner will also mess with file renames on Win* so you may see intermittent failures for this operation. Dan On 1/11/19 11:01 AM, Gary Adams wrote: > I've been reading recently that Windows delete file operations > can be delayed, if there are open handles against the file. > Others have reported virus checkers or other indexing > programs may hold a handle on a file preventing the > deletion being completed. > > The basic logic in InstallSDE is > ?? A + B = C > ?? delete A > ?? rename C to A > > I think we can work around the issue with > ? rename A to A1 > ? A1 + B = C > ? delete A1 > ? rename C to A > > diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java > b/test/jdk/com/sun/jdi/sde/InstallSDE.java > --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java > +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java > @@ -31,9 +31,17 @@ > ???? } > > ???? static void install(File inOutClassFile, File attrFile) throws > IOException { > -??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp"); > -??????? new InstallSDE(inOutClassFile, attrFile, tmpFile); > -??????? if (!inOutClassFile.delete()) { > +??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp-out"); > +??????? File tmpInOutClassFile = new File(inOutClassFile.getPath() + > "tmp-in"); > + > +??????? // Workaround delayed file deletes on Windows using a tmp > file name > +??????? if (!inOutClassFile.renameTo(tmpInOutClassFile)) { > +??????????? throw new IOException("tmp copy of inOutClassFile failed"); > +??????? } > + > +??????? new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); > + > +??????? if (!tmpInOutClassFile.delete()) { > ???????????? throw new IOException("inOutClassFile.delete() failed"); > ???????? } > ???????? if (!tmpFile.renameTo(inOutClassFile)) { > > > Testing in progress ... > > On 1/11/19, 7:40 AM, David Holmes wrote: >> Hi Gary, >> >> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>> After ~1000 testruns I hit a failure in MangleTest and a jtreg agent >>> communication issue with SourceDebugExtension. >>> >>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>> >>> >>> >>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>> ??? at InstallSDE.install(InstallSDE.java:40) >>> ??? at MangleTest.testSetUp(MangleTest.java:38) >>> ??? at MangleTest.main(MangleTest.java:31) >> >> You might want to add some code in: >> >> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >> >> >> that checks the result of _wrename to see what error is occurring. I >> suspect it will be EACCES which won't be that helpful: >> >> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >> >> >> but it would be good to confirm. >> >>> >>> result: Error. Agent communication error: >>> java.io.IOException:*Agent: unexpected op: 71;*? check console log >>> for any additional details >>> >>> I added some additional print outs for the rename issue and have run >>> ~2000 additional >>> testruns with no test failures repeated, yet. But there were 2 mach5 >>> reported errors: >>> >>> ??? TimeoutException in CLEANUP. >> >> That's a mach5 issue. >> >> David >> >>> >>> I'll do some more investigation with making the rename operation >>> more robust >>> before removing SourceDebugExtensionTest from the problem list. >>> >>> On 1/10/19 8:28 PM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>> The test does not appear to fail on the current mach5 test systems. >>>>> There was some question concerning symbolic links that might have >>>>> been problematic at that time. Additional testing in progress... >>>> >>>> Also note that there are two sets of SDE related tests and two >>>> versions of the InstallSDE.java file that both use renameTo. In nsk >>>> the testcase seems to be: >>>> >>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>> >>>> and AFAICS it is not excluded. So removing the exclusion seems >>>> reasonable to me. It was most like a concurrency issue with the >>>> virus scanner. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>> >>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>> --- a/test/jdk/ProblemList.txt >>>>> +++ b/test/jdk/ProblemList.txt >>>>> @@ -838,8 +838,6 @@ >>>>> >>>>> ? com/sun/jdi/RepStep.java 8043571 generic-all >>>>> >>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>>> - >>>>> ? com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>> >>> > From gary.adams at oracle.com Wed Jan 16 16:59:00 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 16 Jan 2019 11:59:00 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <52c92281-8687-1367-711a-dcafed7fe106@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <52c92281-8687-1367-711a-dcafed7fe106@oracle.com> Message-ID: <5C3F62D4.7010806@oracle.com> The interference of a virus scanner for delete A rename C to A makes sense, if the original A is not completely deleted when the rename is requested. For the suggested replacement rename A to A1 The file A1 does not exist so there is no collision taking place. If a virus scanner was holding a reference to A1, it would not collide with the rename C to A There were no failures during testing with the fix in place. Do you have any specific references to "renames on Windows" restrictions? Should we hold back on the "rename A to A1" workaround? Another possibility is to use the newer Windows MoveFile function... On 1/16/19, 11:24 AM, Daniel D. Daugherty wrote: > > rename A to A1 > > I believe the virus scanner will also mess with file renames on Win* > so you may see intermittent failures for this operation. > > Dan > > > On 1/11/19 11:01 AM, Gary Adams wrote: >> I've been reading recently that Windows delete file operations >> can be delayed, if there are open handles against the file. >> Others have reported virus checkers or other indexing >> programs may hold a handle on a file preventing the >> deletion being completed. >> >> The basic logic in InstallSDE is >> A + B = C >> delete A >> rename C to A >> >> I think we can work around the issue with >> rename A to A1 >> A1 + B = C >> delete A1 >> rename C to A >> >> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >> @@ -31,9 +31,17 @@ >> } >> >> static void install(File inOutClassFile, File attrFile) throws >> IOException { >> - File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >> - new InstallSDE(inOutClassFile, attrFile, tmpFile); >> - if (!inOutClassFile.delete()) { >> + File tmpFile = new File(inOutClassFile.getPath() + "tmp-out"); >> + File tmpInOutClassFile = new File(inOutClassFile.getPath() + >> "tmp-in"); >> + >> + // Workaround delayed file deletes on Windows using a tmp >> file name >> + if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >> + throw new IOException("tmp copy of inOutClassFile failed"); >> + } >> + >> + new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >> + >> + if (!tmpInOutClassFile.delete()) { >> throw new IOException("inOutClassFile.delete() failed"); >> } >> if (!tmpFile.renameTo(inOutClassFile)) { >> >> >> Testing in progress ... >> >> On 1/11/19, 7:40 AM, David Holmes wrote: >>> Hi Gary, >>> >>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg >>>> agent communication issue with SourceDebugExtension. >>>> >>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>> >>>> >>>> >>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>> at InstallSDE.install(InstallSDE.java:40) >>>> at MangleTest.testSetUp(MangleTest.java:38) >>>> at MangleTest.main(MangleTest.java:31) >>> >>> You might want to add some code in: >>> >>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>> >>> >>> that checks the result of _wrename to see what error is occurring. I >>> suspect it will be EACCES which won't be that helpful: >>> >>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>> >>> >>> but it would be good to confirm. >>> >>>> >>>> result: Error. Agent communication error: >>>> java.io.IOException:*Agent: unexpected op: 71;* check console log >>>> for any additional details >>>> >>>> I added some additional print outs for the rename issue and have >>>> run ~2000 additional >>>> testruns with no test failures repeated, yet. But there were 2 >>>> mach5 reported errors: >>>> >>>> TimeoutException in CLEANUP. >>> >>> That's a mach5 issue. >>> >>> David >>> >>>> >>>> I'll do some more investigation with making the rename operation >>>> more robust >>>> before removing SourceDebugExtensionTest from the problem list. >>>> >>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>> Hi Gary, >>>>> >>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>>> The test does not appear to fail on the current mach5 test systems. >>>>>> There was some question concerning symbolic links that might have >>>>>> been problematic at that time. Additional testing in progress... >>>>> >>>>> Also note that there are two sets of SDE related tests and two >>>>> versions of the InstallSDE.java file that both use renameTo. In >>>>> nsk the testcase seems to be: >>>>> >>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>> >>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>> reasonable to me. It was most like a concurrency issue with the >>>>> virus scanner. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>> >>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>> --- a/test/jdk/ProblemList.txt >>>>>> +++ b/test/jdk/ProblemList.txt >>>>>> @@ -838,8 +838,6 @@ >>>>>> >>>>>> com/sun/jdi/RepStep.java 8043571 generic-all >>>>>> >>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>>>> - >>>>>> com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>> >>>> >> > From daniel.daugherty at oracle.com Wed Jan 16 17:10:04 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 16 Jan 2019 12:10:04 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <5C3F62D4.7010806@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <52c92281-8687-1367-711a-dcafed7fe106@oracle.com> <5C3F62D4.7010806@oracle.com> Message-ID: <929d7ad5-903b-9a12-03a4-37fe97d4e721@oracle.com> > Do you have any specific references to "renames on Windows" > restrictions? Not at my fingertips. Sorry. > Should we hold back on the "rename A to A1" workaround? No. Let's give a try and see if it helps improve things. Dan On 1/16/19 11:59 AM, Gary Adams wrote: > The interference of a virus scanner for > > ? delete A > ? rename C to A > > makes sense, if the original A is not completely deleted > when the rename is requested. > > For the suggested replacement > > ? rename A to A1 > > The file A1 does not exist so there is no collision taking place. > If? a virus scanner was holding a reference to A1, it > would not collide with the > > ?? rename C to A > > There were no failures during testing with the fix in place. > > Do you have any specific references to "renames on Windows" > restrictions? > > Should we hold back on the "rename A to A1" workaround? > > Another possibility is to use the newer Windows MoveFile function... > > > On 1/16/19, 11:24 AM, Daniel D. Daugherty wrote: >> > rename A to A1 >> >> I believe the virus scanner will also mess with file renames on Win* >> so you may see intermittent failures for this operation. >> >> Dan >> >> >> On 1/11/19 11:01 AM, Gary Adams wrote: >>> I've been reading recently that Windows delete file operations >>> can be delayed, if there are open handles against the file. >>> Others have reported virus checkers or other indexing >>> programs may hold a handle on a file preventing the >>> deletion being completed. >>> >>> The basic logic in InstallSDE is >>> ?? A + B = C >>> ?? delete A >>> ?? rename C to A >>> >>> I think we can work around the issue with >>> ? rename A to A1 >>> ? A1 + B = C >>> ? delete A1 >>> ? rename C to A >>> >>> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>> @@ -31,9 +31,17 @@ >>> ???? } >>> >>> ???? static void install(File inOutClassFile, File attrFile) throws >>> IOException { >>> -??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >>> -??????? new InstallSDE(inOutClassFile, attrFile, tmpFile); >>> -??????? if (!inOutClassFile.delete()) { >>> +??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp-out"); >>> +??????? File tmpInOutClassFile = new File(inOutClassFile.getPath() >>> + "tmp-in"); >>> + >>> +??????? // Workaround delayed file deletes on Windows using a tmp >>> file name >>> +??????? if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >>> +??????????? throw new IOException("tmp copy of inOutClassFile >>> failed"); >>> +??????? } >>> + >>> +??????? new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >>> + >>> +??????? if (!tmpInOutClassFile.delete()) { >>> ???????????? throw new IOException("inOutClassFile.delete() failed"); >>> ???????? } >>> ???????? if (!tmpFile.renameTo(inOutClassFile)) { >>> >>> >>> Testing in progress ... >>> >>> On 1/11/19, 7:40 AM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg >>>>> agent communication issue with SourceDebugExtension. >>>>> >>>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>> >>>>> >>>>> >>>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>>> ??? at InstallSDE.install(InstallSDE.java:40) >>>>> ??? at MangleTest.testSetUp(MangleTest.java:38) >>>>> ??? at MangleTest.main(MangleTest.java:31) >>>> >>>> You might want to add some code in: >>>> >>>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>>> >>>> >>>> that checks the result of _wrename to see what error is occurring. >>>> I suspect it will be EACCES which won't be that helpful: >>>> >>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>>> >>>> >>>> but it would be good to confirm. >>>> >>>>> >>>>> result: Error. Agent communication error: >>>>> java.io.IOException:*Agent: unexpected op: 71;*? check console log >>>>> for any additional details >>>>> >>>>> I added some additional print outs for the rename issue and have >>>>> run ~2000 additional >>>>> testruns with no test failures repeated, yet. But there were 2 >>>>> mach5 reported errors: >>>>> >>>>> ??? TimeoutException in CLEANUP. >>>> >>>> That's a mach5 issue. >>>> >>>> David >>>> >>>>> >>>>> I'll do some more investigation with making the rename operation >>>>> more robust >>>>> before removing SourceDebugExtensionTest from the problem list. >>>>> >>>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>>> Hi Gary, >>>>>> >>>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>>>> The test does not appear to fail on the current mach5 test systems. >>>>>>> There was some question concerning symbolic links that might have >>>>>>> been problematic at that time. Additional testing in progress... >>>>>> >>>>>> Also note that there are two sets of SDE related tests and two >>>>>> versions of the InstallSDE.java file that both use renameTo. In >>>>>> nsk the testcase seems to be: >>>>>> >>>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>>> >>>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>>> reasonable to me. It was most like a concurrency issue with the >>>>>> virus scanner. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>>> >>>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>>> --- a/test/jdk/ProblemList.txt >>>>>>> +++ b/test/jdk/ProblemList.txt >>>>>>> @@ -838,8 +838,6 @@ >>>>>>> >>>>>>> ? com/sun/jdi/RepStep.java 8043571 generic-all >>>>>>> >>>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>>>>> - >>>>>>> ? com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>>> >>>>> >>> >> > From jcbeyler at google.com Wed Jan 16 17:29:54 2019 From: jcbeyler at google.com (JC Beyler) Date: Wed, 16 Jan 2019 09:29:54 -0800 Subject: getPCDescNearDbg returns incorrect PCDesc In-Reply-To: <1ed2e1d3cc6943e3be9bcc9551af5fe3@sap.com> References: <1ed2e1d3cc6943e3be9bcc9551af5fe3@sap.com> Message-ID: Hi David, The explanation you are providing is clear to me, though I'm not sure at all what the right fix would be in this case. I would agree that there might be a bug here but it would be easier to see if you could provide an easy reproducer that shows how the initial line is off by 1 and then how it messes up higher in the stack if you try to fix it by your -1. My best guess is that there is a difference between code paths as you are saying and we might have to differentiate top frame and other frames for this calculation but without a reproducer to see it in action, it is hard to tell. Thanks, Jc On Wed, Jan 16, 2019 at 7:58 AM Doerr, Martin wrote: > Hi David, > > re-posting to serviceability mailing list since you're referring to a > method from > > https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-dev On Behalf Of > David Griffiths > Sent: Mittwoch, 16. Januar 2019 12:08 > To: hotspot-dev at openjdk.java.net > Subject: getPCDescNearDbg returns incorrect PCDesc > > Hi, I'd like some help please understanding what appears to be a bug in > getPCDescNearDbg. The problem is caused by the fact that the _pc_offset > value stored in a PcDesc is actually the offset of the code contained in > the _next_ PcDesc rather than the current one. I assume it's done like this > so that obtaining stack traces works correctly. At least on x86, the last > instruction in a PcDesc chunk is the callq which means that the return > address pc points to the next PcDesc. Therefore associating the PcDesc > containing the callq with the address of the next PcDesc chunk means that > the matching works in getPCDescAt. > > But this causes "off by one" errors in getPCDescNearDbg which appears to > expect the PcDesc getRealPC address to be that of the PcDesc itself rather > than the following one. So you sometimes see incorrect top of stack line > numbers when debugging. (And this would presumably also affect profilers). > > I can fix the top of stack issue by changing distance to: > > long distance = pcDesc.getRealPC(this).minus(pc) - 1 > > but this then messes up the line numbers further down the stack because > they are trying to match against return pcs. > > Anybody come across this before, is my analysis correct? > > Cheers, > > David > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Wed Jan 16 23:28:48 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 16 Jan 2019 15:28:48 -0800 Subject: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails Message-ID: <645447f2-7755-dbf8-d672-e39464a0b156@oracle.com> Hi all, please review a fix for https://bugs.openjdk.java.net/browse/JDK-8216386 webrev: http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/ The fix updates WAIT_TIME to depend on test.timeout.factor system property. WAIT_TIME value is used as argument of Thread.join(). For the case when the thread is expected to be alive (i.e. Thread.join() exits by timeout) the timeout value is restricted by 5 seconds to avoid long run time with big timeout.factor values. --alex From jcbeyler at google.com Wed Jan 16 23:52:16 2019 From: jcbeyler at google.com (JC Beyler) Date: Wed, 16 Jan 2019 15:52:16 -0800 Subject: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails In-Reply-To: <645447f2-7755-dbf8-d672-e39464a0b156@oracle.com> References: <645447f2-7755-dbf8-d672-e39464a0b156@oracle.com> Message-ID: Hi Alex, Looks good to me :-) Jc On Wed, Jan 16, 2019 at 3:29 PM Alex Menkov wrote: > Hi all, > > please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8216386 > webrev: > http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/ > > The fix updates WAIT_TIME to depend on test.timeout.factor system property. > WAIT_TIME value is used as argument of Thread.join(). > For the case when the thread is expected to be alive (i.e. Thread.join() > exits by timeout) the timeout value is restricted by 5 seconds to avoid > long run time with big timeout.factor values. > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jan 17 05:44:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 15:44:51 +1000 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <5C3F5265.2090709@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <5C38E618.3020904@oracle.com> <5C3F5265.2090709@oracle.com> Message-ID: <4d5b899c-8719-d77e-aba5-aa38bf42201e@oracle.com> On 17/01/2019 1:48 am, Gary Adams wrote: > Looking through the test history for the vm/mlvm version of > InstallSDE.java there has never > been a reported problem with the renameTo operation. I'm inclined to not > apply the change > made to the com/sun/jdi/sde test until the failure is observed. There is much greater use of InstallSDE than just the vm/mlvm test that I mentioned earlier. InstallSDE is also used by: ./hotspot/jtreg/vmTestbase/nsk/share/jdi/sde/SDEDebugger.java which in turn is used by numerous nsk/jdi tests. It would be prudent IMHO to fix both versions. It would be extremely surprising (and raise doubt about the actual problem) if the jdk tests fail but the nsk tests never do. David ----- > I'm satisfied with the testing at this point and could use another > reviewer before > pushing. > > On 1/11/19, 6:14 PM, David Holmes wrote: >> Hi Gary, >> >> As I mentioned earlier there are two versions of InstallSDE.java in >> the tests, so both should be updated. >> >> Your strategy to avoid the windows delete issue seems reasonable. >> >> David >> >> On 12/01/2019 4:53 am, Gary Adams wrote: >>> Here's a webrev for review purposes. >>> No failures after ~1000 testruns. >>> >>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ >>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>> >>> On 1/11/19, 11:01 AM, Gary Adams wrote: >>>> I've been reading recently that Windows delete file operations >>>> can be delayed, if there are open handles against the file. >>>> Others have reported virus checkers or other indexing >>>> programs may hold a handle on a file preventing the >>>> deletion being completed. >>>> >>>> The basic logic in InstallSDE is >>>> ?? A + B = C >>>> ?? delete A >>>> ?? rename C to A >>>> >>>> I think we can work around the issue with >>>> ? rename A to A1 >>>> ? A1 + B = C >>>> ? delete A1 >>>> ? rename C to A >>>> >>>> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>> @@ -31,9 +31,17 @@ >>>> ???? } >>>> >>>> ???? static void install(File inOutClassFile, File attrFile) throws >>>> IOException { >>>> -??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >>>> -??????? new InstallSDE(inOutClassFile, attrFile, tmpFile); >>>> -??????? if (!inOutClassFile.delete()) { >>>> +??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp-out"); >>>> +??????? File tmpInOutClassFile = new File(inOutClassFile.getPath() >>>> + "tmp-in"); >>>> + >>>> +??????? // Workaround delayed file deletes on Windows using a tmp >>>> file name >>>> +??????? if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >>>> +??????????? throw new IOException("tmp copy of inOutClassFile >>>> failed"); >>>> +??????? } >>>> + >>>> +??????? new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >>>> + >>>> +??????? if (!tmpInOutClassFile.delete()) { >>>> ???????????? throw new IOException("inOutClassFile.delete() failed"); >>>> ???????? } >>>> ???????? if (!tmpFile.renameTo(inOutClassFile)) { >>>> >>>> >>>> Testing in progress ... >>>> >>>> On 1/11/19, 7:40 AM, David Holmes wrote: >>>>> Hi Gary, >>>>> >>>>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg >>>>>> agent communication issue with SourceDebugExtension. >>>>>> >>>>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>>> >>>>>> >>>>>> >>>>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>>>> ??? at InstallSDE.install(InstallSDE.java:40) >>>>>> ??? at MangleTest.testSetUp(MangleTest.java:38) >>>>>> ??? at MangleTest.main(MangleTest.java:31) >>>>> >>>>> You might want to add some code in: >>>>> >>>>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>>>> >>>>> >>>>> that checks the result of _wrename to see what error is occurring. >>>>> I suspect it will be EACCES which won't be that helpful: >>>>> >>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>>>> >>>>> >>>>> but it would be good to confirm. >>>>> >>>>>> >>>>>> result: Error. Agent communication error: >>>>>> java.io.IOException:*Agent: unexpected op: 71;*? check console log >>>>>> for any additional details >>>>>> >>>>>> I added some additional print outs for the rename issue and have >>>>>> run ~2000 additional >>>>>> testruns with no test failures repeated, yet. But there were 2 >>>>>> mach5 reported errors: >>>>>> >>>>>> ??? TimeoutException in CLEANUP. >>>>> >>>>> That's a mach5 issue. >>>>> >>>>> David >>>>> >>>>>> >>>>>> I'll do some more investigation with making the rename operation >>>>>> more robust >>>>>> before removing SourceDebugExtensionTest from the problem list. >>>>>> >>>>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>>>>> The test does not appear to fail on the current mach5 test systems. >>>>>>>> There was some question concerning symbolic links that might have >>>>>>>> been problematic at that time. Additional testing in progress... >>>>>>> >>>>>>> Also note that there are two sets of SDE related tests and two >>>>>>> versions of the InstallSDE.java file that both use renameTo. In >>>>>>> nsk the testcase seems to be: >>>>>>> >>>>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>>>> >>>>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>>>> reasonable to me. It was most like a concurrency issue with the >>>>>>> virus scanner. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>>>> >>>>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>>>> --- a/test/jdk/ProblemList.txt >>>>>>>> +++ b/test/jdk/ProblemList.txt >>>>>>>> @@ -838,8 +838,6 @@ >>>>>>>> >>>>>>>> ? com/sun/jdi/RepStep.java 8043571 generic-all >>>>>>>> >>>>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>>>>>> - >>>>>>>> ? com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>>>> >>>>>> >>>> >>> > From daniil.x.titov at oracle.com Thu Jan 17 06:27:09 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 16 Jan 2019 22:27:09 -0800 Subject: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails In-Reply-To: <030FBBD3-A2A4-43B8-8AFA-069FEF1C9B5E@oracle.com> References: <030FBBD3-A2A4-43B8-8AFA-069FEF1C9B5E@oracle.com> Message-ID: Hi Alex, The change looks good to me but I think the copyright comment needs to be updated for year 2019. Thanks. Best regards, Daniil ?On 1/16/19, 3:29 PM, "serviceability-dev on behalf of Alex Menkov" wrote: Hi all, please review a fix for https://bugs.openjdk.java.net/browse/JDK-8216386 webrev: http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/ The fix updates WAIT_TIME to depend on test.timeout.factor system property. WAIT_TIME value is used as argument of Thread.join(). For the case when the thread is expected to be alive (i.e. Thread.join() exits by timeout) the timeout value is restricted by 5 seconds to avoid long run time with big timeout.factor values. --alex From david.griffiths at gmail.com Thu Jan 17 09:12:35 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Thu, 17 Jan 2019 09:12:35 +0000 Subject: getPCDescNearDbg returns incorrect PCDesc In-Reply-To: References: <1ed2e1d3cc6943e3be9bcc9551af5fe3@sap.com> Message-ID: Hi Jc, ok thanks, I'll see if I can come up with a simple example. Cheers, David On Wed, 16 Jan 2019 at 17:30, JC Beyler wrote: > Hi David, > > The explanation you are providing is clear to me, though I'm not sure at > all what the right fix would be in this case. I would agree that there > might be a bug here but it would be easier to see if you could provide an > easy reproducer that shows how the initial line is off by 1 and then how it > messes up higher in the stack if you try to fix it by your -1. > > My best guess is that there is a difference between code paths as you are > saying and we might have to differentiate top frame and other frames for > this calculation but without a reproducer to see it in action, it is hard > to tell. > > Thanks, > Jc > > On Wed, Jan 16, 2019 at 7:58 AM Doerr, Martin > wrote: > >> Hi David, >> >> re-posting to serviceability mailing list since you're referring to a >> method from >> >> https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> David Griffiths >> Sent: Mittwoch, 16. Januar 2019 12:08 >> To: hotspot-dev at openjdk.java.net >> Subject: getPCDescNearDbg returns incorrect PCDesc >> >> Hi, I'd like some help please understanding what appears to be a bug in >> getPCDescNearDbg. The problem is caused by the fact that the _pc_offset >> value stored in a PcDesc is actually the offset of the code contained in >> the _next_ PcDesc rather than the current one. I assume it's done like >> this >> so that obtaining stack traces works correctly. At least on x86, the last >> instruction in a PcDesc chunk is the callq which means that the return >> address pc points to the next PcDesc. Therefore associating the PcDesc >> containing the callq with the address of the next PcDesc chunk means that >> the matching works in getPCDescAt. >> >> But this causes "off by one" errors in getPCDescNearDbg which appears to >> expect the PcDesc getRealPC address to be that of the PcDesc itself rather >> than the following one. So you sometimes see incorrect top of stack line >> numbers when debugging. (And this would presumably also affect profilers). >> >> I can fix the top of stack issue by changing distance to: >> >> long distance = pcDesc.getRealPC(this).minus(pc) - 1 >> >> but this then messes up the line numbers further down the stack because >> they are trying to match against return pcs. >> >> Anybody come across this before, is my analysis correct? >> >> Cheers, >> >> David >> > > > -- > > Thanks, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Thu Jan 17 11:06:52 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 17 Jan 2019 06:06:52 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <4d5b899c-8719-d77e-aba5-aa38bf42201e@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <5C38E618.3020904@oracle.com> <5C3F5265.2090709@oracle.com> <4d5b899c-8719-d77e-aba5-aa38bf42201e@oracle.com> Message-ID: Updated webrev: ?? Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.01/ On 1/17/19 12:44 AM, David Holmes wrote: > On 17/01/2019 1:48 am, Gary Adams wrote: >> Looking through the test history for the vm/mlvm version of >> InstallSDE.java there has never >> been a reported problem with the renameTo operation. I'm inclined to >> not apply the change >> made to the com/sun/jdi/sde test until the failure is observed. > > There is much greater use of InstallSDE than just the vm/mlvm test > that I mentioned earlier. InstallSDE is also used by: > > ./hotspot/jtreg/vmTestbase/nsk/share/jdi/sde/SDEDebugger.java > > which in turn is used by numerous nsk/jdi tests. > > It would be prudent IMHO to fix both versions. It would be extremely > surprising (and raise doubt about the actual problem) if the jdk tests > fail but the nsk tests never do. > > David > ----- > >> I'm satisfied with the testing at this point and could use another >> reviewer before >> pushing. >> >> On 1/11/19, 6:14 PM, David Holmes wrote: >>> Hi Gary, >>> >>> As I mentioned earlier there are two versions of InstallSDE.java in >>> the tests, so both should be updated. >>> >>> Your strategy to avoid the windows delete issue seems reasonable. >>> >>> David >>> >>> On 12/01/2019 4:53 am, Gary Adams wrote: >>>> Here's a webrev for review purposes. >>>> No failures after ~1000 testruns. >>>> >>>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ >>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>> >>>> On 1/11/19, 11:01 AM, Gary Adams wrote: >>>>> I've been reading recently that Windows delete file operations >>>>> can be delayed, if there are open handles against the file. >>>>> Others have reported virus checkers or other indexing >>>>> programs may hold a handle on a file preventing the >>>>> deletion being completed. >>>>> >>>>> The basic logic in InstallSDE is >>>>> ?? A + B = C >>>>> ?? delete A >>>>> ?? rename C to A >>>>> >>>>> I think we can work around the issue with >>>>> ? rename A to A1 >>>>> ? A1 + B = C >>>>> ? delete A1 >>>>> ? rename C to A >>>>> >>>>> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>> @@ -31,9 +31,17 @@ >>>>> ???? } >>>>> >>>>> ???? static void install(File inOutClassFile, File attrFile) >>>>> throws IOException { >>>>> -??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >>>>> -??????? new InstallSDE(inOutClassFile, attrFile, tmpFile); >>>>> -??????? if (!inOutClassFile.delete()) { >>>>> +??????? File tmpFile = new File(inOutClassFile.getPath() + >>>>> "tmp-out"); >>>>> +??????? File tmpInOutClassFile = new >>>>> File(inOutClassFile.getPath() + "tmp-in"); >>>>> + >>>>> +??????? // Workaround delayed file deletes on Windows using a tmp >>>>> file name >>>>> +??????? if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >>>>> +??????????? throw new IOException("tmp copy of inOutClassFile >>>>> failed"); >>>>> +??????? } >>>>> + >>>>> +??????? new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >>>>> + >>>>> +??????? if (!tmpInOutClassFile.delete()) { >>>>> ???????????? throw new IOException("inOutClassFile.delete() failed"); >>>>> ???????? } >>>>> ???????? if (!tmpFile.renameTo(inOutClassFile)) { >>>>> >>>>> >>>>> Testing in progress ... >>>>> >>>>> On 1/11/19, 7:40 AM, David Holmes wrote: >>>>>> Hi Gary, >>>>>> >>>>>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>>>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg >>>>>>> agent communication issue with SourceDebugExtension. >>>>>>> >>>>>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>>>> >>>>>>> >>>>>>> >>>>>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>>>>> ??? at InstallSDE.install(InstallSDE.java:40) >>>>>>> ??? at MangleTest.testSetUp(MangleTest.java:38) >>>>>>> ??? at MangleTest.main(MangleTest.java:31) >>>>>> >>>>>> You might want to add some code in: >>>>>> >>>>>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>>>>> >>>>>> >>>>>> that checks the result of _wrename to see what error is >>>>>> occurring. I suspect it will be EACCES which won't be that helpful: >>>>>> >>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>>>>> >>>>>> >>>>>> but it would be good to confirm. >>>>>> >>>>>>> >>>>>>> result: Error. Agent communication error: >>>>>>> java.io.IOException:*Agent: unexpected op: 71;*? check console >>>>>>> log for any additional details >>>>>>> >>>>>>> I added some additional print outs for the rename issue and have >>>>>>> run ~2000 additional >>>>>>> testruns with no test failures repeated, yet. But there were 2 >>>>>>> mach5 reported errors: >>>>>>> >>>>>>> ??? TimeoutException in CLEANUP. >>>>>> >>>>>> That's a mach5 issue. >>>>>> >>>>>> David >>>>>> >>>>>>> >>>>>>> I'll do some more investigation with making the rename operation >>>>>>> more robust >>>>>>> before removing SourceDebugExtensionTest from the problem list. >>>>>>> >>>>>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>>>>> Hi Gary, >>>>>>>> >>>>>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>>>>>> The test does not appear to fail on the current mach5 test >>>>>>>>> systems. >>>>>>>>> There was some question concerning symbolic links that might have >>>>>>>>> been problematic at that time. Additional testing in progress... >>>>>>>> >>>>>>>> Also note that there are two sets of SDE related tests and two >>>>>>>> versions of the InstallSDE.java file that both use renameTo. In >>>>>>>> nsk the testcase seems to be: >>>>>>>> >>>>>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>>>>> >>>>>>>> >>>>>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>>>>> reasonable to me. It was most like a concurrency issue with the >>>>>>>> virus scanner. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>>>>> >>>>>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>>>>> --- a/test/jdk/ProblemList.txt >>>>>>>>> +++ b/test/jdk/ProblemList.txt >>>>>>>>> @@ -838,8 +838,6 @@ >>>>>>>>> >>>>>>>>> ? com/sun/jdi/RepStep.java 8043571 generic-all >>>>>>>>> >>>>>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 >>>>>>>>> windows-all >>>>>>>>> - >>>>>>>>> ? com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>>>>> >>>>>>> >>>>> >>>> >> From david.griffiths at gmail.com Thu Jan 17 11:35:57 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Thu, 17 Jan 2019 11:35:57 +0000 Subject: getPCDescNearDbg returns incorrect PCDesc In-Reply-To: References: <1ed2e1d3cc6943e3be9bcc9551af5fe3@sap.com> Message-ID: Here is example as promised. First the test program: 1 public class PcDescTest 2 { 3 public static void main(String[] args) 4 { 5 new PcDescTest(); 6 } 7 8 PcDescTest() 9 { 10 for (int i = 0; ; i++) { 11 run(i); 12 } 13 } 14 15 int run(int i) 16 { 17 int j = i - 1; 18 int k = j + 23; 19 if ((j % 1000000) == 0) { 20 sleep(); 21 } 22 return k; 23 } 24 25 void sleep() 26 { 27 System.out.println("about to sleep..."); 28 try { 29 Thread.sleep(10000); 30 } catch (InterruptedException e) {} 31 System.out.println("...back from sleep"); 32 } 33 } run like this: java -Xmx8m -Xcomp -XX:CompileCommand=dontinline,PcDescTest.run -XX:CompileCommand=dontinline,PcDescTest.sleep -XX:CompileCommand=print,PcDescTest.run PcDescTest and it will print the assembler out which includes: [Verified Entry Point] 0x00007fc3a93bd880: mov %eax,-0x14000(%rsp) 0x00007fc3a93bd887: push %rbp 0x00007fc3a93bd888: sub $0x10,%rsp ;*synchronization entry ; - PcDescTest::run at -1 (line 17) 0x00007fc3a93bd88c: mov %edx,%r11d 0x00007fc3a93bd88f: dec %r11d ;*isub ; - PcDescTest::run at 2 (line 17) 0x00007fc3a93bd892: mov %edx,%ebp 0x00007fc3a93bd894: add $0x16,%ebp ;*iadd ; - PcDescTest::run at 7 (line 18) 0x00007fc3a93bd897: movslq %r11d,%r10 In another window, attach gdb (gdb --pid nnnn) and then set a breakpoint at the iadd line which I think we can agree is definitely the code for line 18: (gdb) b *0x00007fc3a93bd894 then continue until the breakpoint hits and then take a core dump: (gdb) c Continuing. [Switching to Thread 0x7fc3bfe1a700 (LWP 8354)] Thread 2 "java" hit Breakpoint 1, 0x00007fc3a93bd894 in ?? () (gdb) gcore warning: target file /proc/8353/cmdline contained unexpected null characters Saved corefile core.8353 (gdb) quit finally, use jstack to see the stack: $ jstack `command -v java` core.8353 and you will see: - PcDescTest.run(int) @bci=2, line=17 (Compiled frame; information may be imprecise) - PcDescTest.() @bci=8, line=11 (Compiled frame) - PcDescTest.main(java.lang.String[]) @bci=4, line=5 (Interpreted frame) which is incorrect (admittedly it warns you!) if I make the change I suggested: public PCDesc getPCDescNearDbg(Address pc) { PCDesc bestGuessPCDesc = null; //long bestDistance = 0; long bestDistance = Long.MAX_VALUE; for (Address p = scopesPCsBegin(); p.lessThan(scopesPCsEnd()); p = p.addOffsetTo(pcDescSize)) { PCDesc pcDesc = new PCDesc(p); // In case pc is null //long distance = -pcDesc.getRealPC(this).minus(pc); long distance = pcDesc.getRealPC(this).minus(pc) - 1; //if ((bestGuessPCDesc == null) || //((distance >= 0) && (distance < bestDistance))) { if (distance >= 0 && distance < bestDistance) { bestGuessPCDesc = pcDesc; bestDistance = distance; } then it gives: - PcDescTest.run(int) @bci=7, line=18 (Compiled frame; information may be imprecise) - PcDescTest.() @bci=12, line=10 (Compiled frame) - PcDescTest.main(java.lang.String[]) @bci=4, line=5 (Interpreted frame) but as you can see the caller line is now incorrect. Cheers, David On Thu, 17 Jan 2019 at 09:12, David Griffiths wrote: > > Hi Jc, ok thanks, I'll see if I can come up with a simple example. > > Cheers, > > David > > On Wed, 16 Jan 2019 at 17:30, JC Beyler wrote: >> >> Hi David, >> >> The explanation you are providing is clear to me, though I'm not sure at all what the right fix would be in this case. I would agree that there might be a bug here but it would be easier to see if you could provide an easy reproducer that shows how the initial line is off by 1 and then how it messes up higher in the stack if you try to fix it by your -1. >> >> My best guess is that there is a difference between code paths as you are saying and we might have to differentiate top frame and other frames for this calculation but without a reproducer to see it in action, it is hard to tell. >> >> Thanks, >> Jc >> >> On Wed, Jan 16, 2019 at 7:58 AM Doerr, Martin wrote: >>> >>> Hi David, >>> >>> re-posting to serviceability mailing list since you're referring to a method from >>> https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html >>> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: hotspot-dev On Behalf Of David Griffiths >>> Sent: Mittwoch, 16. Januar 2019 12:08 >>> To: hotspot-dev at openjdk.java.net >>> Subject: getPCDescNearDbg returns incorrect PCDesc >>> >>> Hi, I'd like some help please understanding what appears to be a bug in >>> getPCDescNearDbg. The problem is caused by the fact that the _pc_offset >>> value stored in a PcDesc is actually the offset of the code contained in >>> the _next_ PcDesc rather than the current one. I assume it's done like this >>> so that obtaining stack traces works correctly. At least on x86, the last >>> instruction in a PcDesc chunk is the callq which means that the return >>> address pc points to the next PcDesc. Therefore associating the PcDesc >>> containing the callq with the address of the next PcDesc chunk means that >>> the matching works in getPCDescAt. >>> >>> But this causes "off by one" errors in getPCDescNearDbg which appears to >>> expect the PcDesc getRealPC address to be that of the PcDesc itself rather >>> than the following one. So you sometimes see incorrect top of stack line >>> numbers when debugging. (And this would presumably also affect profilers). >>> >>> I can fix the top of stack issue by changing distance to: >>> >>> long distance = pcDesc.getRealPC(this).minus(pc) - 1 >>> >>> but this then messes up the line numbers further down the stack because >>> they are trying to match against return pcs. >>> >>> Anybody come across this before, is my analysis correct? >>> >>> Cheers, >>> >>> David >> >> >> >> -- >> >> Thanks, >> Jc From david.griffiths at gmail.com Thu Jan 17 12:27:09 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Thu, 17 Jan 2019 12:27:09 +0000 Subject: getPCDescNearDbg returns incorrect PCDesc In-Reply-To: References: <1ed2e1d3cc6943e3be9bcc9551af5fe3@sap.com> Message-ID: PS: for the caller being incorrect, the following change in VFrame.newVFrame fixes it: // FIXME: should revisit the check of isDebugging(); should not be necessary //if (mayBeImprecise || VM.getVM().isDebugging()) { if (mayBeImprecise) { scope = nm.getScopeDescNearDbg(f.getPC()); } else { scope = nm.getScopeDescAt(f.getPC()); } because mayBeImprecise is only set for the top frame. Cheers, David On Thu, 17 Jan 2019 at 11:35, David Griffiths wrote: > > Here is example as promised. First the test program: > > 1 public class PcDescTest > 2 { > 3 public static void main(String[] args) > 4 { > 5 new PcDescTest(); > 6 } > 7 > 8 PcDescTest() > 9 { > 10 for (int i = 0; ; i++) { > 11 run(i); > 12 } > 13 } > 14 > 15 int run(int i) > 16 { > 17 int j = i - 1; > 18 int k = j + 23; > 19 if ((j % 1000000) == 0) { > 20 sleep(); > 21 } > 22 return k; > 23 } > 24 > 25 void sleep() > 26 { > 27 System.out.println("about to sleep..."); > 28 try { > 29 Thread.sleep(10000); > 30 } catch (InterruptedException e) {} > 31 System.out.println("...back from sleep"); > 32 } > 33 } > > run like this: > > java -Xmx8m -Xcomp -XX:CompileCommand=dontinline,PcDescTest.run > -XX:CompileCommand=dontinline,PcDescTest.sleep > -XX:CompileCommand=print,PcDescTest.run PcDescTest > > and it will print the assembler out which includes: > > [Verified Entry Point] > 0x00007fc3a93bd880: mov %eax,-0x14000(%rsp) > 0x00007fc3a93bd887: push %rbp > 0x00007fc3a93bd888: sub $0x10,%rsp ;*synchronization entry > ; - PcDescTest::run at -1 (line 17) > > 0x00007fc3a93bd88c: mov %edx,%r11d > 0x00007fc3a93bd88f: dec %r11d ;*isub > ; - PcDescTest::run at 2 (line 17) > > 0x00007fc3a93bd892: mov %edx,%ebp > 0x00007fc3a93bd894: add $0x16,%ebp ;*iadd > ; - PcDescTest::run at 7 (line 18) > > 0x00007fc3a93bd897: movslq %r11d,%r10 > > In another window, attach gdb (gdb --pid nnnn) and then set a > breakpoint at the iadd line which I think we can agree is definitely > the code for line 18: > > (gdb) b *0x00007fc3a93bd894 > > then continue until the breakpoint hits and then take a core dump: > > (gdb) c > Continuing. > [Switching to Thread 0x7fc3bfe1a700 (LWP 8354)] > Thread 2 "java" hit Breakpoint 1, 0x00007fc3a93bd894 in ?? () > (gdb) gcore > warning: target file /proc/8353/cmdline contained unexpected null characters > Saved corefile core.8353 > (gdb) quit > > finally, use jstack to see the stack: > > $ jstack `command -v java` core.8353 > > and you will see: > > - PcDescTest.run(int) @bci=2, line=17 (Compiled frame; information > may be imprecise) > - PcDescTest.() @bci=8, line=11 (Compiled frame) > - PcDescTest.main(java.lang.String[]) @bci=4, line=5 (Interpreted frame) > > which is incorrect (admittedly it warns you!) > > if I make the change I suggested: > > public PCDesc getPCDescNearDbg(Address pc) { > PCDesc bestGuessPCDesc = null; > //long bestDistance = 0; > long bestDistance = Long.MAX_VALUE; > for (Address p = scopesPCsBegin(); p.lessThan(scopesPCsEnd()); p = > p.addOffsetTo(pcDescSize)) { > PCDesc pcDesc = new PCDesc(p); > // In case pc is null > //long distance = -pcDesc.getRealPC(this).minus(pc); > long distance = pcDesc.getRealPC(this).minus(pc) - 1; > //if ((bestGuessPCDesc == null) || > //((distance >= 0) && (distance < bestDistance))) { > if (distance >= 0 && distance < bestDistance) { > bestGuessPCDesc = pcDesc; > bestDistance = distance; > } > > then it gives: > > - PcDescTest.run(int) @bci=7, line=18 (Compiled frame; information > may be imprecise) > - PcDescTest.() @bci=12, line=10 (Compiled frame) > - PcDescTest.main(java.lang.String[]) @bci=4, line=5 (Interpreted frame) > > but as you can see the caller line is now incorrect. > > Cheers, > > David > > > On Thu, 17 Jan 2019 at 09:12, David Griffiths wrote: > > > > Hi Jc, ok thanks, I'll see if I can come up with a simple example. > > > > Cheers, > > > > David > > > > On Wed, 16 Jan 2019 at 17:30, JC Beyler wrote: > >> > >> Hi David, > >> > >> The explanation you are providing is clear to me, though I'm not sure at all what the right fix would be in this case. I would agree that there might be a bug here but it would be easier to see if you could provide an easy reproducer that shows how the initial line is off by 1 and then how it messes up higher in the stack if you try to fix it by your -1. > >> > >> My best guess is that there is a difference between code paths as you are saying and we might have to differentiate top frame and other frames for this calculation but without a reproducer to see it in action, it is hard to tell. > >> > >> Thanks, > >> Jc > >> > >> On Wed, Jan 16, 2019 at 7:58 AM Doerr, Martin wrote: > >>> > >>> Hi David, > >>> > >>> re-posting to serviceability mailing list since you're referring to a method from > >>> https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html > >>> > >>> Best regards, > >>> Martin > >>> > >>> > >>> -----Original Message----- > >>> From: hotspot-dev On Behalf Of David Griffiths > >>> Sent: Mittwoch, 16. Januar 2019 12:08 > >>> To: hotspot-dev at openjdk.java.net > >>> Subject: getPCDescNearDbg returns incorrect PCDesc > >>> > >>> Hi, I'd like some help please understanding what appears to be a bug in > >>> getPCDescNearDbg. The problem is caused by the fact that the _pc_offset > >>> value stored in a PcDesc is actually the offset of the code contained in > >>> the _next_ PcDesc rather than the current one. I assume it's done like this > >>> so that obtaining stack traces works correctly. At least on x86, the last > >>> instruction in a PcDesc chunk is the callq which means that the return > >>> address pc points to the next PcDesc. Therefore associating the PcDesc > >>> containing the callq with the address of the next PcDesc chunk means that > >>> the matching works in getPCDescAt. > >>> > >>> But this causes "off by one" errors in getPCDescNearDbg which appears to > >>> expect the PcDesc getRealPC address to be that of the PcDesc itself rather > >>> than the following one. So you sometimes see incorrect top of stack line > >>> numbers when debugging. (And this would presumably also affect profilers). > >>> > >>> I can fix the top of stack issue by changing distance to: > >>> > >>> long distance = pcDesc.getRealPC(this).minus(pc) - 1 > >>> > >>> but this then messes up the line numbers further down the stack because > >>> they are trying to match against return pcs. > >>> > >>> Anybody come across this before, is my analysis correct? > >>> > >>> Cheers, > >>> > >>> David > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc From daniel.daugherty at oracle.com Thu Jan 17 15:40:42 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Jan 2019 10:40:42 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: <929d7ad5-903b-9a12-03a4-37fe97d4e721@oracle.com> References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <52c92281-8687-1367-711a-dcafed7fe106@oracle.com> <5C3F62D4.7010806@oracle.com> <929d7ad5-903b-9a12-03a4-37fe97d4e721@oracle.com> Message-ID: <295ddc44-d949-1133-05ea-2fd73914fbe5@oracle.com> On re-reading this thread, I realized that my concern about: > rename A to A1 was not clear. I'm wasn't worried about the virus scanner having file A1 open. I was worried about the virus scanner having file A open and preventing the rename from happening. I have a vague memory of this happening a long time (so very old Win* versions). We should still give this work around a try and keep an eye on any failures... Dan On 1/16/19 12:10 PM, Daniel D. Daugherty wrote: >> Do you have any specific references to "renames on Windows" >> restrictions? > > Not at my fingertips. Sorry. > > >> Should we hold back on the "rename A to A1" workaround? > > No. Let's give a try and see if it helps improve things. > > Dan > > > > On 1/16/19 11:59 AM, Gary Adams wrote: >> The interference of a virus scanner for >> >> ? delete A >> ? rename C to A >> >> makes sense, if the original A is not completely deleted >> when the rename is requested. >> >> For the suggested replacement >> >> ? rename A to A1 >> >> The file A1 does not exist so there is no collision taking place. >> If? a virus scanner was holding a reference to A1, it >> would not collide with the >> >> ?? rename C to A >> >> There were no failures during testing with the fix in place. >> >> Do you have any specific references to "renames on Windows" >> restrictions? >> >> Should we hold back on the "rename A to A1" workaround? >> >> Another possibility is to use the newer Windows MoveFile function... >> >> >> On 1/16/19, 11:24 AM, Daniel D. Daugherty wrote: >>> > rename A to A1 >>> >>> I believe the virus scanner will also mess with file renames on Win* >>> so you may see intermittent failures for this operation. >>> >>> Dan >>> >>> >>> On 1/11/19 11:01 AM, Gary Adams wrote: >>>> I've been reading recently that Windows delete file operations >>>> can be delayed, if there are open handles against the file. >>>> Others have reported virus checkers or other indexing >>>> programs may hold a handle on a file preventing the >>>> deletion being completed. >>>> >>>> The basic logic in InstallSDE is >>>> ?? A + B = C >>>> ?? delete A >>>> ?? rename C to A >>>> >>>> I think we can work around the issue with >>>> ? rename A to A1 >>>> ? A1 + B = C >>>> ? delete A1 >>>> ? rename C to A >>>> >>>> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>> @@ -31,9 +31,17 @@ >>>> ???? } >>>> >>>> ???? static void install(File inOutClassFile, File attrFile) throws >>>> IOException { >>>> -??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >>>> -??????? new InstallSDE(inOutClassFile, attrFile, tmpFile); >>>> -??????? if (!inOutClassFile.delete()) { >>>> +??????? File tmpFile = new File(inOutClassFile.getPath() + >>>> "tmp-out"); >>>> +??????? File tmpInOutClassFile = new File(inOutClassFile.getPath() >>>> + "tmp-in"); >>>> + >>>> +??????? // Workaround delayed file deletes on Windows using a tmp >>>> file name >>>> +??????? if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >>>> +??????????? throw new IOException("tmp copy of inOutClassFile >>>> failed"); >>>> +??????? } >>>> + >>>> +??????? new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >>>> + >>>> +??????? if (!tmpInOutClassFile.delete()) { >>>> ???????????? throw new IOException("inOutClassFile.delete() failed"); >>>> ???????? } >>>> ???????? if (!tmpFile.renameTo(inOutClassFile)) { >>>> >>>> >>>> Testing in progress ... >>>> >>>> On 1/11/19, 7:40 AM, David Holmes wrote: >>>>> Hi Gary, >>>>> >>>>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg >>>>>> agent communication issue with SourceDebugExtension. >>>>>> >>>>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>>> >>>>>> >>>>>> >>>>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>>>> ??? at InstallSDE.install(InstallSDE.java:40) >>>>>> ??? at MangleTest.testSetUp(MangleTest.java:38) >>>>>> ??? at MangleTest.main(MangleTest.java:31) >>>>> >>>>> You might want to add some code in: >>>>> >>>>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>>>> >>>>> >>>>> that checks the result of _wrename to see what error is occurring. >>>>> I suspect it will be EACCES which won't be that helpful: >>>>> >>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>>>> >>>>> >>>>> but it would be good to confirm. >>>>> >>>>>> >>>>>> result: Error. Agent communication error: >>>>>> java.io.IOException:*Agent: unexpected op: 71;*? check console >>>>>> log for any additional details >>>>>> >>>>>> I added some additional print outs for the rename issue and have >>>>>> run ~2000 additional >>>>>> testruns with no test failures repeated, yet. But there were 2 >>>>>> mach5 reported errors: >>>>>> >>>>>> ??? TimeoutException in CLEANUP. >>>>> >>>>> That's a mach5 issue. >>>>> >>>>> David >>>>> >>>>>> >>>>>> I'll do some more investigation with making the rename operation >>>>>> more robust >>>>>> before removing SourceDebugExtensionTest from the problem list. >>>>>> >>>>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>>>> because of filesystem rename issues on Windows 2012 test systems. >>>>>>>> The test does not appear to fail on the current mach5 test >>>>>>>> systems. >>>>>>>> There was some question concerning symbolic links that might have >>>>>>>> been problematic at that time. Additional testing in progress... >>>>>>> >>>>>>> Also note that there are two sets of SDE related tests and two >>>>>>> versions of the InstallSDE.java file that both use renameTo. In >>>>>>> nsk the testcase seems to be: >>>>>>> >>>>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>>>> >>>>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>>>> reasonable to me. It was most like a concurrency issue with the >>>>>>> virus scanner. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>>>> >>>>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>>>> --- a/test/jdk/ProblemList.txt >>>>>>>> +++ b/test/jdk/ProblemList.txt >>>>>>>> @@ -838,8 +838,6 @@ >>>>>>>> >>>>>>>> ? com/sun/jdi/RepStep.java 8043571 generic-all >>>>>>>> >>>>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 windows-all >>>>>>>> - >>>>>>>> ? com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>>>> >>>>>> >>>> >>> >> > > From alexey.menkov at oracle.com Thu Jan 17 17:47:41 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 17 Jan 2019 09:47:41 -0800 Subject: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails In-Reply-To: References: <030FBBD3-A2A4-43B8-8AFA-069FEF1C9B5E@oracle.com> Message-ID: Hi Daniil, On 01/16/2019 22:27, Daniil Titov wrote: > Hi Alex, > > The change looks good to me but I think the copyright comment needs to be updated for year 2019. Updated the webrev in-place. --alex > > Thanks. > > Best regards, > Daniil > > ?On 1/16/19, 3:29 PM, "serviceability-dev on behalf of Alex Menkov" wrote: > > Hi all, > > please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8216386 > webrev: > http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/ > > The fix updates WAIT_TIME to depend on test.timeout.factor system property. > WAIT_TIME value is used as argument of Thread.join(). > For the case when the thread is expected to be alive (i.e. Thread.join() > exits by timeout) the timeout value is restricted by 5 seconds to avoid > long run time with big timeout.factor values. > > --alex > > > > From daniil.x.titov at oracle.com Thu Jan 17 17:59:25 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 17 Jan 2019 09:59:25 -0800 Subject: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails In-Reply-To: References: <030FBBD3-A2A4-43B8-8AFA-069FEF1C9B5E@oracle.com> Message-ID: Hi Alex, Looks good to me. Thanks! Best regards, Daniil ?On 1/17/19, 9:47 AM, "Alex Menkov" wrote: Hi Daniil, On 01/16/2019 22:27, Daniil Titov wrote: > Hi Alex, > > The change looks good to me but I think the copyright comment needs to be updated for year 2019. Updated the webrev in-place. --alex > > Thanks. > > Best regards, > Daniil > > ?On 1/16/19, 3:29 PM, "serviceability-dev on behalf of Alex Menkov" wrote: > > Hi all, > > please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8216386 > webrev: > http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/ > > The fix updates WAIT_TIME to depend on test.timeout.factor system property. > WAIT_TIME value is used as argument of Thread.join(). > For the case when the thread is expected to be alive (i.e. Thread.join() > exits by timeout) the timeout value is restricted by 5 seconds to avoid > long run time with big timeout.factor values. > > --alex > > > > From gary.adams at oracle.com Thu Jan 17 18:53:27 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 17 Jan 2019 13:53:27 -0500 Subject: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails In-Reply-To: <645447f2-7755-dbf8-d672-e39464a0b156@oracle.com> References: <645447f2-7755-dbf8-d672-e39464a0b156@oracle.com> Message-ID: <5C40CF27.4000107@oracle.com> I like the fact that test.timeout.factor is applied as a multiplier. It's not clear why an upper limit had to be added. Is that 50 or 5 seconds? 148 objWaiterThr1.join(Math.min(WAIT_TIME, 50000)); Why are the other wait times not limited? 136 objWaiterThr2.join(WAIT_TIME); ... 169 popFrameClsThr.join(WAIT_TIME); If you need to apply the upper limit, then it would be better to apply it at the beginning. 38 static final long WAIT_TIME = Math.min(Utils.adjustTimeout(2000),5000); On 1/16/19, 6:28 PM, Alex Menkov wrote: > Hi all, > > please review a fix for > https://bugs.openjdk.java.net/browse/JDK-8216386 > webrev: > http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/ > > The fix updates WAIT_TIME to depend on test.timeout.factor system > property. > WAIT_TIME value is used as argument of Thread.join(). > For the case when the thread is expected to be alive (i.e. > Thread.join() exits by timeout) the timeout value is restricted by 5 > seconds to avoid long run time with big timeout.factor values. > > --alex From alexey.menkov at oracle.com Thu Jan 17 20:21:04 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 17 Jan 2019 12:21:04 -0800 Subject: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails In-Reply-To: <5C40CF27.4000107@oracle.com> References: <645447f2-7755-dbf8-d672-e39464a0b156@oracle.com> <5C40CF27.4000107@oracle.com> Message-ID: <65e5db84-9561-8e7e-1aca-1047db1c4b8d@oracle.com> Hi Gary, On 01/17/2019 10:53, Gary Adams wrote: > I like the fact that test.timeout.factor is applied as a multiplier. > > It's not clear why an upper limit had to be added. As you noted there 3 cases where Thread.join() is called, but the expected behavior is different. objWaiterThr2 and popFrameClsThr are expected to exit, but objWaiterThr1 is expected to be alive after join (i.e. the call is expected to take the time specified). I don't want to increase the test run time (for timeout.factor == 10 it would take 18 extra seconds), so I restricted the timeout for the case. > Is that 50 or 5 seconds? Thank you for the catch. It should be 5 seconds (5000 ms) Updated webrev: http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev.02/ --alex > > ?148???????????? objWaiterThr1.join(Math.min(WAIT_TIME, 50000)); > > Why are the other wait times not limited? > > ?136???????????? objWaiterThr2.join(WAIT_TIME); > > ... > > ?169???????????????? popFrameClsThr.join(WAIT_TIME); > > > If you need to apply the upper limit, then it would be better to apply it > at the beginning. > > ? 38???? static final long WAIT_TIME = > Math.min(Utils.adjustTimeout(2000),5000); > > > > > > On 1/16/19, 6:28 PM, Alex Menkov wrote: >> Hi all, >> >> please review a fix for >> https://bugs.openjdk.java.net/browse/JDK-8216386 >> webrev: >> http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/ >> >> The fix updates WAIT_TIME to depend on test.timeout.factor system >> property. >> WAIT_TIME value is used as argument of Thread.join(). >> For the case when the thread is expected to be alive (i.e. >> Thread.join() exits by timeout) the timeout value is restricted by 5 >> seconds to avoid long run time with big timeout.factor values. >> >> --alex > From hohensee at amazon.com Thu Jan 17 22:11:14 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 17 Jan 2019 22:11:14 +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> Message-ID: <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> 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 daniil.x.titov at oracle.com Fri Jan 18 02:08:46 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 17 Jan 2019 18:08:46 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references Message-ID: Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 Thanks! --Daniil From jcbeyler at google.com Fri Jan 18 03:12:57 2019 From: jcbeyler at google.com (JC Beyler) Date: Thu, 17 Jan 2019 19:12:57 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: References: Message-ID: Hi Daniil, I "think" I understand what is going on but my major comment will be that you might want to revisit the comments and the log. The comment under the test: 300 if (step->depth == JDWP_STEP_DEPTH(OVER)) { might need a bit of a change. But more importantly, 347 * We installed a method entry event handler as part of a 348 * step into operation. We've popped back to the original 349 * stepping frame without finding a place to stop. 350 * Resume stepping in the original frame. 351 */ 352 LOG_STEP(("handleFramePopEvent: starting singlestep, have methodEnter handler && depth==OUT && fromDepth >= afterPopDepth (%d>%d)",fromDepth, afterPopDepth)); That comment might also need a bit of a rewrite due to "without finding a place to stop", is that still true or was it supposed that this was true due to the comparison you removed. Finally the message in the LOG_STEP needs to change since the comparison is no longer there, no? Thanks, Jc On Thu, Jan 17, 2019 at 6:09 PM Daniil Titov wrote: > Please review the change that fixes JDB stepping issue for a specific case > when the single step request was initiated earlier in the stack, previous > calls were for methods in the filtered classes (single stepping was > disabled), handleMethodEnterEvent() re-enabled stepping and the first > bytecode upon entering the current method requires resolving constant pool > entry. In this case the execution resumes in > java.lang.Classloader.loadClass() and since it is also a filtered class the > single stepping is getting disabled again (stepControl.c :593). When > loadClass() exits a notifyFramePop() is called on the loadClass() frame but > due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that > doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth > is 4) the notifyFramePop() fails to enable single stepping back. The fix > removes the excessive condition fromDepth >= afterPopDepth in > notifyFramePop() method (stepControl.c:346) to ensure that when a method > cal! > led from the stepping frame (and during which we had stepping disabled) > has returned the stepping is re-enabled to continue instructions steps in > the original stepping frame. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks! > --Daniil > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From sharath.ballal at oracle.com Fri Jan 18 05:38:01 2019 From: sharath.ballal at oracle.com (Sharath Ballal) Date: Thu, 17 Jan 2019 21:38:01 -0800 (PST) Subject: PING: RFR: 8181313: SA: Remove libthread_db dependency on Linux In-Reply-To: <6e245a2c-a308-1ee5-b0ca-f8fa2f91411b@gmail.com> References: <7419f616-31d4-4aef-f982-bc14f09b4ca6@oracle.com> <2efdc891-bd4a-ff13-fedc-fa9ae11e0b8a@gmail.com> <9f8a615d-9caa-936f-f439-e3d47ba313fd@oracle.com> <6e245a2c-a308-1ee5-b0ca-f8fa2f91411b@gmail.com> Message-ID: Looks good Yasumasa. Thanks, Sharath -----Original Message----- From: Yasumasa Suenaga [mailto:yasuenag at gmail.com] Sent: Tuesday, January 15, 2019 5:35 PM To: serviceability-dev at openjdk.java.net Subject: PING: RFR: 8181313: SA: Remove libthread_db dependency on Linux PING: Could you review it? We need one more reviewer. > http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.02/ Thanks, Yasumasa On 2019/01/11 11:51, Yasumasa Suenaga wrote: > Hi Jini, > > I removed ps_get_thread_area() in new webrev: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.02/ > > Diff from webrev.01 is here: > > http://hg.openjdk.java.net/jdk/submit/rev/691a931ae2ba > > > Thanks, > > Yasumasa > > > 2019?1?11?(?) 1:05 Jini George : >> >> Thanks, Yasumasa, but I meant removing the declaration and definition >> of >> ps_get_thread_area() also. I don't think it is needed anymore. >> >> Thanks, >> Jini. >> >> On 1/10/2019 6:50 PM, Yasumasa Suenaga wrote: >>> Hi Jini, >>> >>> Thank you for your comment. >>> I uploaded a new webrev: >>> >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.01/ >>> >>> It passed tests on submit repo. >>> Could you review again? >>> >>> >>> Yasumasa >>> >>> >>> On 2019/01/10 15:10, Jini George wrote: >>>> Thank you for implementing this change, Yasumasa. It looks good to me. >>>> Just a nit. >>>> >>>> ==> linux/native/libsaproc/libproc_impl.c >>>> Could you please remove these lines ? I don't think these are >>>> needed anymore. >>>> >>>> 421 >>>> 422 // new libthread_db of NPTL seem to require this symbol >>>> 423 JNIEXPORT ps_err_e JNICALL >>>> 424 ps_get_thread_area() { >>>> 425 print_debug("ps_get_thread_area not implemented\n"); >>>> 426 return PS_OK; >>>> 427 } >>>> >>>> ==> linux/native/libsaproc/proc_service.h >>>> Could you please remove these lines too ? >>>> 79 >>>> 80 // new libthread_db of NPTL seem to require this symbol >>>> 81 JNIEXPORT ps_err_e JNICALL >>>> 82 ps_get_thread_area(); >>>> >>>> Thanks, >>>> Jini. >>>> >>>> >>>> >>>> On 1/9/2019 6:53 AM, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8181313 >>>>> webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8181313/webrev.00/ >>>>> >>>>> It has passed all tests on submit repo, and serviceability/sa >>>>> tests on Linux x64. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumas >>>>> From goetz.lindenmaier at sap.com Fri Jan 18 13:30:10 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 18 Jan 2019 13:30:10 +0000 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> <2b441c90-c926-4286-9ca7-889f1fc0b4b6@default> Message-ID: <96a914e1729a4240843b5fe2423cef93@sap.com> Hi Jini, we see test failing after this change arrived deeper in our infrastructure. On a linuxx86_64 docker container it does not work. This is because you now throw Error() if shouldSAAttach() returns false. I think you need this: --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java Thu Jan 03 17:30:03 2019 +0100 +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java Fri Jan 18 14:25:05 2019 +0100 @@ -190,8 +190,9 @@ needPrivileges = true; } } else { - System.out.println("SA attach not expected to work. Insufficient privileges."); - throw new Error("Cannot attach."); + // Silently skip the test if we don't have enough permissions to attach + System.out.println("SA attach not expected to work - test skipped."); + return null; } } This is because canPtraceAttachLinux() in Platform.java returns false. What do you think? Best regards, Goetz. > -----Original Message----- > From: serviceability-dev On > Behalf Of Jini George > Sent: Montag, 14. Januar 2019 06:08 > To: Sharath Ballal ; JC Beyler > ; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo > privileges to enable MacOS tests on Mach5 > > Thank you very much, Sharath, for the review. My comments inline. > > On 1/12/2019 3:38 PM, Sharath Ballal wrote: > > Hi Jini, > > > > ClhsdbLauncher.java > > 1. Is the platform check not required in case of core files ? > No, it is not needed. The permission issues don't exist. > > > - if (!Platform.shouldSAAttach()) { > > - // Silently skip the test if we don't have enough permissions to attach > > - System.out.println("SA attach not expected to work - test skipped."); > > - return null; > > - } > > - > > > > 2. Nit: extra line at 135 > > Done. > > Thanks, > Jini. > > > > > > Thanks, > > Sharath > > > > > > -----Original Message----- > > From: Jini George > > Sent: Friday, January 11, 2019 9:46 AM > > To: JC Beyler; serviceability-dev at openjdk.java.net > > Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo > privileges to enable MacOS tests on Mach5 > > > > Thanks again, JC! :-) > > > > Folks, Could I please get one more review on this ? > > > > -Jini. > > > > On 1/11/2019 9:38 AM, JC Beyler wrote: > >> Hi Jini, > >> > >> Looks?good to me now :) Thanks for handling the comments :) Jc > >> > >> > >> On Tue, Jan 8, 2019 at 8:11 PM Jini George >> > wrote: > >> > >> Thank you very much for the review, JC. My comments inline: > >> > >> On 1/8/2019 12:22 AM, JC Beyler wrote: > >> > > >> > > >> > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/s > erviceability/sa/ClhsdbLauncher.java.udiff.html > >> >? ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check now if sudo > >> > passes in this > >> >? ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' command. > >> >? ? ? ?-> Really shouldn't provide implementation details about > >> what is > >> > being done by that method; if we change that, this comment will > >> rot :-) > >> > canAddPrivileges is explicit enough in my mind > >> > >> Done. I have removed the comment. > >> > >> > > >> > > >> > >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/tes > >> t/lib/SA/SATestUtils.java.html > >> > >> > > >> >? ? ? -> You put some System.out.println; are they intended to > >> still be > >> > there or were they for debug? > >> > >> I guess you meant this one: > >> System.out.println("Adding 'sudo -E' to the command."); > >> > >> This one is meant to be there. > >> > >> > > >> > > >> >? ? 77? ? ? ? ?for (String val: cmdStringList) { > >> >? ? 78? ? ? ? ? ? ?outStringList.add(val); > >> >? ? 79? ? ? ? ?} > >> > > >> > > >> > Couldn't we use addAll ? > >> > >> Done. > >> The modified webrev is at: > >> > >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html > >> > >> Thanks, > >> Jini. > >> > >> > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc From jini.george at oracle.com Fri Jan 18 18:41:49 2019 From: jini.george at oracle.com (Jini George) Date: Sat, 19 Jan 2019 00:11:49 +0530 Subject: getPCDescNearDbg returns incorrect PCDesc In-Reply-To: References: <1ed2e1d3cc6943e3be9bcc9551af5fe3@sap.com> Message-ID: Thank you for the example and the detailed explanation, David. I am not sure if the PcDesc being found in getPCDescNearDbg() is incorrect or if the PcDesc is being mapped to the incorrect bci and line number (or scope?). In the example, the PcDesc returned for 0x00007fc3a93bd894 will be the one with real pc = 0x00007fc3a93bd892. This seems to be correct since the instruction at 0x00007fc3a93bd892 -- which is: mov %edx,%ebp is technically a part of the 'iadd'. (since, if i understand right, this is moving 'i' into 'ebp' before adding 22 (instead of adding i - 1 to 23)). But the bci and the line number attributed to 0x00007fc3a93bd892 should be '7' and '18' respectively, instead of '2' and '17' which belong to the 'isub'. Would you be changing the PcDesc returned with your proposed fix ? I have not been able to delve deeper into this yet. Your fix for the callers (calling getScopeDescAt() instead of getScopeDescNearDbg()) seems correct to me. Thanks, Jini. On 1/17/2019 5:05 PM, David Griffiths wrote: > Here is example as promised. First the test program: > > 1 public class PcDescTest > 2 { > 3 public static void main(String[] args) > 4 { > 5 new PcDescTest(); > 6 } > 7 > 8 PcDescTest() > 9 { > 10 for (int i = 0; ; i++) { > 11 run(i); > 12 } > 13 } > 14 > 15 int run(int i) > 16 { > 17 int j = i - 1; > 18 int k = j + 23; > 19 if ((j % 1000000) == 0) { > 20 sleep(); > 21 } > 22 return k; > 23 } > 24 > 25 void sleep() > 26 { > 27 System.out.println("about to sleep..."); > 28 try { > 29 Thread.sleep(10000); > 30 } catch (InterruptedException e) {} > 31 System.out.println("...back from sleep"); > 32 } > 33 } > > run like this: > > java -Xmx8m -Xcomp -XX:CompileCommand=dontinline,PcDescTest.run > -XX:CompileCommand=dontinline,PcDescTest.sleep > -XX:CompileCommand=print,PcDescTest.run PcDescTest > > and it will print the assembler out which includes: > > [Verified Entry Point] > 0x00007fc3a93bd880: mov %eax,-0x14000(%rsp) > 0x00007fc3a93bd887: push %rbp > 0x00007fc3a93bd888: sub $0x10,%rsp ;*synchronization entry > ; - PcDescTest::run at -1 (line 17) > > 0x00007fc3a93bd88c: mov %edx,%r11d > 0x00007fc3a93bd88f: dec %r11d ;*isub > ; - PcDescTest::run at 2 (line 17) > > 0x00007fc3a93bd892: mov %edx,%ebp > 0x00007fc3a93bd894: add $0x16,%ebp ;*iadd > ; - PcDescTest::run at 7 (line 18) > > 0x00007fc3a93bd897: movslq %r11d,%r10 > > In another window, attach gdb (gdb --pid nnnn) and then set a > breakpoint at the iadd line which I think we can agree is definitely > the code for line 18: > > (gdb) b *0x00007fc3a93bd894 > > then continue until the breakpoint hits and then take a core dump: > > (gdb) c > Continuing. > [Switching to Thread 0x7fc3bfe1a700 (LWP 8354)] > Thread 2 "java" hit Breakpoint 1, 0x00007fc3a93bd894 in ?? () > (gdb) gcore > warning: target file /proc/8353/cmdline contained unexpected null characters > Saved corefile core.8353 > (gdb) quit > > finally, use jstack to see the stack: > > $ jstack `command -v java` core.8353 > > and you will see: > > - PcDescTest.run(int) @bci=2, line=17 (Compiled frame; information > may be imprecise) > - PcDescTest.() @bci=8, line=11 (Compiled frame) > - PcDescTest.main(java.lang.String[]) @bci=4, line=5 (Interpreted frame) > > which is incorrect (admittedly it warns you!) > > if I make the change I suggested: > > public PCDesc getPCDescNearDbg(Address pc) { > PCDesc bestGuessPCDesc = null; > //long bestDistance = 0; > long bestDistance = Long.MAX_VALUE; > for (Address p = scopesPCsBegin(); p.lessThan(scopesPCsEnd()); p = > p.addOffsetTo(pcDescSize)) { > PCDesc pcDesc = new PCDesc(p); > // In case pc is null > //long distance = -pcDesc.getRealPC(this).minus(pc); > long distance = pcDesc.getRealPC(this).minus(pc) - 1; > //if ((bestGuessPCDesc == null) || > //((distance >= 0) && (distance < bestDistance))) { > if (distance >= 0 && distance < bestDistance) { > bestGuessPCDesc = pcDesc; > bestDistance = distance; > } > > then it gives: > > - PcDescTest.run(int) @bci=7, line=18 (Compiled frame; information > may be imprecise) > - PcDescTest.() @bci=12, line=10 (Compiled frame) > - PcDescTest.main(java.lang.String[]) @bci=4, line=5 (Interpreted frame) > > but as you can see the caller line is now incorrect. > > Cheers, > > David > > > On Thu, 17 Jan 2019 at 09:12, David Griffiths wrote: >> >> Hi Jc, ok thanks, I'll see if I can come up with a simple example. >> >> Cheers, >> >> David >> >> On Wed, 16 Jan 2019 at 17:30, JC Beyler wrote: >>> >>> Hi David, >>> >>> The explanation you are providing is clear to me, though I'm not sure at all what the right fix would be in this case. I would agree that there might be a bug here but it would be easier to see if you could provide an easy reproducer that shows how the initial line is off by 1 and then how it messes up higher in the stack if you try to fix it by your -1. >>> >>> My best guess is that there is a difference between code paths as you are saying and we might have to differentiate top frame and other frames for this calculation but without a reproducer to see it in action, it is hard to tell. >>> >>> Thanks, >>> Jc >>> >>> On Wed, Jan 16, 2019 at 7:58 AM Doerr, Martin wrote: >>>> >>>> Hi David, >>>> >>>> re-posting to serviceability mailing list since you're referring to a method from >>>> https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html >>>> >>>> Best regards, >>>> Martin >>>> >>>> >>>> -----Original Message----- >>>> From: hotspot-dev On Behalf Of David Griffiths >>>> Sent: Mittwoch, 16. Januar 2019 12:08 >>>> To: hotspot-dev at openjdk.java.net >>>> Subject: getPCDescNearDbg returns incorrect PCDesc >>>> >>>> Hi, I'd like some help please understanding what appears to be a bug in >>>> getPCDescNearDbg. The problem is caused by the fact that the _pc_offset >>>> value stored in a PcDesc is actually the offset of the code contained in >>>> the _next_ PcDesc rather than the current one. I assume it's done like this >>>> so that obtaining stack traces works correctly. At least on x86, the last >>>> instruction in a PcDesc chunk is the callq which means that the return >>>> address pc points to the next PcDesc. Therefore associating the PcDesc >>>> containing the callq with the address of the next PcDesc chunk means that >>>> the matching works in getPCDescAt. >>>> >>>> But this causes "off by one" errors in getPCDescNearDbg which appears to >>>> expect the PcDesc getRealPC address to be that of the PcDesc itself rather >>>> than the following one. So you sometimes see incorrect top of stack line >>>> numbers when debugging. (And this would presumably also affect profilers). >>>> >>>> I can fix the top of stack issue by changing distance to: >>>> >>>> long distance = pcDesc.getRealPC(this).minus(pc) - 1 >>>> >>>> but this then messes up the line numbers further down the stack because >>>> they are trying to match against return pcs. >>>> >>>> Anybody come across this before, is my analysis correct? >>>> >>>> Cheers, >>>> >>>> David >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc From daniil.x.titov at oracle.com Fri Jan 18 23:08:30 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 18 Jan 2019 15:08:30 -0800 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: <5e9c223c-71c5-980e-03b9-679e69942f23@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> Message-ID: <0194722E-CFE1-4E3A-A521-14910D88B378@oracle.com> 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" 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" 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" 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 daniel.daugherty at oracle.com Fri Jan 18 23:22:52 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 18 Jan 2019 18:22:52 -0500 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <5C38E618.3020904@oracle.com> <5C3F5265.2090709@oracle.com> <4d5b899c-8719-d77e-aba5-aa38bf42201e@oracle.com> Message-ID: On 1/17/19 6:06 AM, gary.adams at oracle.com wrote: > Updated webrev: > > ?? Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.01/ test/hotspot/jtreg/vmTestbase/nsk/share/jdi/sde/InstallSDE.java ??? No comments. test/jdk/com/sun/jdi/sde/InstallSDE.java ??? No comments. test/jdk/ProblemList.txt ??? No comments. Thumbs up! Dan > > On 1/17/19 12:44 AM, David Holmes wrote: >> On 17/01/2019 1:48 am, Gary Adams wrote: >>> Looking through the test history for the vm/mlvm version of >>> InstallSDE.java there has never >>> been a reported problem with the renameTo operation. I'm inclined to >>> not apply the change >>> made to the com/sun/jdi/sde test until the failure is observed. >> >> There is much greater use of InstallSDE than just the vm/mlvm test >> that I mentioned earlier. InstallSDE is also used by: >> >> ./hotspot/jtreg/vmTestbase/nsk/share/jdi/sde/SDEDebugger.java >> >> which in turn is used by numerous nsk/jdi tests. >> >> It would be prudent IMHO to fix both versions. It would be extremely >> surprising (and raise doubt about the actual problem) if the jdk >> tests fail but the nsk tests never do. >> >> David >> ----- >> >>> I'm satisfied with the testing at this point and could use another >>> reviewer before >>> pushing. >>> >>> On 1/11/19, 6:14 PM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> As I mentioned earlier there are two versions of InstallSDE.java in >>>> the tests, so both should be updated. >>>> >>>> Your strategy to avoid the windows delete issue seems reasonable. >>>> >>>> David >>>> >>>> On 12/01/2019 4:53 am, Gary Adams wrote: >>>>> Here's a webrev for review purposes. >>>>> No failures after ~1000 testruns. >>>>> >>>>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ >>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>> >>>>> On 1/11/19, 11:01 AM, Gary Adams wrote: >>>>>> I've been reading recently that Windows delete file operations >>>>>> can be delayed, if there are open handles against the file. >>>>>> Others have reported virus checkers or other indexing >>>>>> programs may hold a handle on a file preventing the >>>>>> deletion being completed. >>>>>> >>>>>> The basic logic in InstallSDE is >>>>>> ?? A + B = C >>>>>> ?? delete A >>>>>> ?? rename C to A >>>>>> >>>>>> I think we can work around the issue with >>>>>> ? rename A to A1 >>>>>> ? A1 + B = C >>>>>> ? delete A1 >>>>>> ? rename C to A >>>>>> >>>>>> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>>> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>>> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>>> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>>> @@ -31,9 +31,17 @@ >>>>>> ???? } >>>>>> >>>>>> ???? static void install(File inOutClassFile, File attrFile) >>>>>> throws IOException { >>>>>> -??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >>>>>> -??????? new InstallSDE(inOutClassFile, attrFile, tmpFile); >>>>>> -??????? if (!inOutClassFile.delete()) { >>>>>> +??????? File tmpFile = new File(inOutClassFile.getPath() + >>>>>> "tmp-out"); >>>>>> +??????? File tmpInOutClassFile = new >>>>>> File(inOutClassFile.getPath() + "tmp-in"); >>>>>> + >>>>>> +??????? // Workaround delayed file deletes on Windows using a >>>>>> tmp file name >>>>>> +??????? if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >>>>>> +??????????? throw new IOException("tmp copy of inOutClassFile >>>>>> failed"); >>>>>> +??????? } >>>>>> + >>>>>> +??????? new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >>>>>> + >>>>>> +??????? if (!tmpInOutClassFile.delete()) { >>>>>> ???????????? throw new IOException("inOutClassFile.delete() >>>>>> failed"); >>>>>> ???????? } >>>>>> ???????? if (!tmpFile.renameTo(inOutClassFile)) { >>>>>> >>>>>> >>>>>> Testing in progress ... >>>>>> >>>>>> On 1/11/19, 7:40 AM, David Holmes wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>>>>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg >>>>>>>> agent communication issue with SourceDebugExtension. >>>>>>>> >>>>>>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>>>>>> ??? at InstallSDE.install(InstallSDE.java:40) >>>>>>>> ??? at MangleTest.testSetUp(MangleTest.java:38) >>>>>>>> ??? at MangleTest.main(MangleTest.java:31) >>>>>>> >>>>>>> You might want to add some code in: >>>>>>> >>>>>>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>>>>>> >>>>>>> >>>>>>> that checks the result of _wrename to see what error is >>>>>>> occurring. I suspect it will be EACCES which won't be that helpful: >>>>>>> >>>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>>>>>> >>>>>>> >>>>>>> but it would be good to confirm. >>>>>>> >>>>>>>> >>>>>>>> result: Error. Agent communication error: >>>>>>>> java.io.IOException:*Agent: unexpected op: 71;* check console >>>>>>>> log for any additional details >>>>>>>> >>>>>>>> I added some additional print outs for the rename issue and >>>>>>>> have run ~2000 additional >>>>>>>> testruns with no test failures repeated, yet. But there were 2 >>>>>>>> mach5 reported errors: >>>>>>>> >>>>>>>> ??? TimeoutException in CLEANUP. >>>>>>> >>>>>>> That's a mach5 issue. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> I'll do some more investigation with making the rename >>>>>>>> operation more robust >>>>>>>> before removing SourceDebugExtensionTest from the problem list. >>>>>>>> >>>>>>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>>>>>> Hi Gary, >>>>>>>>> >>>>>>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>>>>>> because of filesystem rename issues on Windows 2012 test >>>>>>>>>> systems. >>>>>>>>>> The test does not appear to fail on the current mach5 test >>>>>>>>>> systems. >>>>>>>>>> There was some question concerning symbolic links that might >>>>>>>>>> have >>>>>>>>>> been problematic at that time. Additional testing in progress... >>>>>>>>> >>>>>>>>> Also note that there are two sets of SDE related tests and two >>>>>>>>> versions of the InstallSDE.java file that both use renameTo. >>>>>>>>> In nsk the testcase seems to be: >>>>>>>>> >>>>>>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>>>>>> >>>>>>>>> >>>>>>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>>>>>> reasonable to me. It was most like a concurrency issue with >>>>>>>>> the virus scanner. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>>>>>> >>>>>>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>>>>>> --- a/test/jdk/ProblemList.txt >>>>>>>>>> +++ b/test/jdk/ProblemList.txt >>>>>>>>>> @@ -838,8 +838,6 @@ >>>>>>>>>> >>>>>>>>>> ? com/sun/jdi/RepStep.java 8043571 generic-all >>>>>>>>>> >>>>>>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 >>>>>>>>>> windows-all >>>>>>>>>> - >>>>>>>>>> ? com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > > From david.holmes at oracle.com Sat Jan 19 22:48:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 20 Jan 2019 08:48:29 +1000 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: <96a914e1729a4240843b5fe2423cef93@sap.com> References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> <2b441c90-c926-4286-9ca7-889f1fc0b4b6@default> <96a914e1729a4240843b5fe2423cef93@sap.com> Message-ID: <6d7bea9c-9158-3de7-23e4-04967596b4e1@oracle.com> On 18/01/2019 11:30 pm, Lindenmaier, Goetz wrote: > Hi Jini, > > we see test failing after this change arrived deeper in our infrastructure. > On a linuxx86_64 docker container it does not work. > > This is because you now throw Error() if shouldSAAttach() returns false. > I think you need this: > --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java Thu Jan 03 17:30:03 2019 +0100 > +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java Fri Jan 18 14:25:05 2019 +0100 > @@ -190,8 +190,9 @@ > needPrivileges = true; > } > } else { > - System.out.println("SA attach not expected to work. Insufficient privileges."); > - throw new Error("Cannot attach."); > + // Silently skip the test if we don't have enough permissions to attach > + System.out.println("SA attach not expected to work - test skipped."); > + return null; We should be able to use SkippedException for this case. David > } > } > > This is because canPtraceAttachLinux() in Platform.java returns false. > > What do you think? > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: serviceability-dev On >> Behalf Of Jini George >> Sent: Montag, 14. Januar 2019 06:08 >> To: Sharath Ballal ; JC Beyler >> ; serviceability-dev at openjdk.java.net >> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo >> privileges to enable MacOS tests on Mach5 >> >> Thank you very much, Sharath, for the review. My comments inline. >> >> On 1/12/2019 3:38 PM, Sharath Ballal wrote: >>> Hi Jini, >>> >>> ClhsdbLauncher.java >>> 1. Is the platform check not required in case of core files ? >> No, it is not needed. The permission issues don't exist. >> >>> - if (!Platform.shouldSAAttach()) { >>> - // Silently skip the test if we don't have enough permissions to attach >>> - System.out.println("SA attach not expected to work - test skipped."); >>> - return null; >>> - } >>> - >>> >>> 2. Nit: extra line at 135 >> >> Done. >> >> Thanks, >> Jini. >>> >>> >>> Thanks, >>> Sharath >>> >>> >>> -----Original Message----- >>> From: Jini George >>> Sent: Friday, January 11, 2019 9:46 AM >>> To: JC Beyler; serviceability-dev at openjdk.java.net >>> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo >> privileges to enable MacOS tests on Mach5 >>> >>> Thanks again, JC! :-) >>> >>> Folks, Could I please get one more review on this ? >>> >>> -Jini. >>> >>> On 1/11/2019 9:38 AM, JC Beyler wrote: >>>> Hi Jini, >>>> >>>> Looks?good to me now :) Thanks for handling the comments :) Jc >>>> >>>> >>>> On Tue, Jan 8, 2019 at 8:11 PM Jini George >>> > wrote: >>>> >>>> Thank you very much for the review, JC. My comments inline: >>>> >>>> On 1/8/2019 12:22 AM, JC Beyler wrote: >>>> > >>>> > >>>> >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/s >> erviceability/sa/ClhsdbLauncher.java.udiff.html >>>> >? ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check now if sudo >>>> > passes in this >>>> >? ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' command. >>>> >? ? ? ?-> Really shouldn't provide implementation details about >>>> what is >>>> > being done by that method; if we change that, this comment will >>>> rot :-) >>>> > canAddPrivileges is explicit enough in my mind >>>> >>>> Done. I have removed the comment. >>>> >>>> > >>>> > >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/tes >>>> t/lib/SA/SATestUtils.java.html >>>> >>>> > >>>> >? ? ? -> You put some System.out.println; are they intended to >>>> still be >>>> > there or were they for debug? >>>> >>>> I guess you meant this one: >>>> System.out.println("Adding 'sudo -E' to the command."); >>>> >>>> This one is meant to be there. >>>> >>>> > >>>> > >>>> >? ? 77? ? ? ? ?for (String val: cmdStringList) { >>>> >? ? 78? ? ? ? ? ? ?outStringList.add(val); >>>> >? ? 79? ? ? ? ?} >>>> > >>>> > >>>> > Couldn't we use addAll ? >>>> >>>> Done. >>>> The modified webrev is at: >>>> >>>> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html >>>> >>>> Thanks, >>>> Jini. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc From jini.george at oracle.com Sun Jan 20 16:12:25 2019 From: jini.george at oracle.com (Jini George) Date: Sun, 20 Jan 2019 21:42:25 +0530 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: <6d7bea9c-9158-3de7-23e4-04967596b4e1@oracle.com> References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> <2b441c90-c926-4286-9ca7-889f1fc0b4b6@default> <96a914e1729a4240843b5fe2423cef93@sap.com> <6d7bea9c-9158-3de7-23e4-04967596b4e1@oracle.com> Message-ID: <0b3b612c-c12c-b36a-9f5a-933c55cf0a7a@oracle.com> Thanks, Goetz for letting me know of the failure and thanks, David for the suggestion wrt SkippedException. Goetz, I will send you a patch off-list, and it would be great if you could test it again for me. Thanks, Jini. On 1/20/2019 4:18 AM, David Holmes wrote: > On 18/01/2019 11:30 pm, Lindenmaier, Goetz wrote: >> Hi Jini, >> >> we see test failing after this change arrived deeper in our >> infrastructure. >> On a linuxx86_64 docker container it does not work. >> >> This is because you now throw Error() if shouldSAAttach() returns false. >> I think you need this: >> --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java??? Thu >> Jan 03 17:30:03 2019 +0100 >> +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java??? Fri >> Jan 18 14:25:05 2019 +0100 >> @@ -190,8 +190,9 @@ >> ???????????????????? needPrivileges = true; >> ???????????????? } >> ????????????? } else { >> -??????????????? System.out.println("SA attach not expected to work. >> Insufficient privileges."); >> -??????????????? throw new Error("Cannot attach."); >> +??????????????? // Silently skip the test if we don't have enough >> permissions to attach >> +??????????????? System.out.println("SA attach not expected to work - >> test skipped."); >> +??????????????? return null; > > We should be able to use SkippedException for this case. > > David > >> ????????????? } >> ????????? } >> >> This is because canPtraceAttachLinux() in Platform.java returns false. >> >> What do you think? >> >> Best regards, >> ?? Goetz. >> >> >> >>> -----Original Message----- >>> From: serviceability-dev >>> On >>> Behalf Of Jini George >>> Sent: Montag, 14. Januar 2019 06:08 >>> To: Sharath Ballal ; JC Beyler >>> ; serviceability-dev at openjdk.java.net >>> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo >>> privileges to enable MacOS tests on Mach5 >>> >>> Thank you very much, Sharath, for the review. My comments inline. >>> >>> On 1/12/2019 3:38 PM, Sharath Ballal wrote: >>>> Hi Jini, >>>> >>>> ClhsdbLauncher.java >>>> 1. Is the platform check not required in case of core files ? >>> No, it is not needed. The permission issues don't exist. >>> >>>> -??????? if (!Platform.shouldSAAttach()) { >>>> -??????????? // Silently skip the test if we don't have enough >>>> permissions to attach >>>> -??????????? System.out.println("SA attach not expected to work - >>>> test skipped."); >>>> -??????????? return null; >>>> -??????? } >>>> - >>>> >>>> 2. Nit: extra line at 135 >>> >>> Done. >>> >>> Thanks, >>> Jini. >>>> >>>> >>>> Thanks, >>>> Sharath >>>> >>>> >>>> -----Original Message----- >>>> From: Jini George >>>> Sent: Friday, January 11, 2019 9:46 AM >>>> To: JC Beyler; serviceability-dev at openjdk.java.net >>>> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo >>> privileges to enable MacOS tests on Mach5 >>>> >>>> Thanks again, JC! :-) >>>> >>>> Folks, Could I please get one more review on this ? >>>> >>>> -Jini. >>>> >>>> On 1/11/2019 9:38 AM, JC Beyler wrote: >>>>> Hi Jini, >>>>> >>>>> Looks?good to me now :) Thanks for handling the comments :) Jc >>>>> >>>>> >>>>> On Tue, Jan 8, 2019 at 8:11 PM Jini George >>>> > wrote: >>>>> >>>>> ????? Thank you very much for the review, JC. My comments inline: >>>>> >>>>> ????? On 1/8/2019 12:22 AM, JC Beyler wrote: >>>>> ?????? > >>>>> ?????? > >>>>> >>> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/s >>> >>> erviceability/sa/ClhsdbLauncher.java.udiff.html >>>>> ?????? >? ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check >>>>> now if sudo >>>>> ?????? > passes in this >>>>> ?????? >? ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' >>>>> command. >>>>> ?????? >? ? ? ?-> Really shouldn't provide implementation details >>>>> about >>>>> ????? what is >>>>> ?????? > being done by that method; if we change that, this comment >>>>> will >>>>> ????? rot :-) >>>>> ?????? > canAddPrivileges is explicit enough in my mind >>>>> >>>>> ????? Done. I have removed the comment. >>>>> >>>>> ?????? > >>>>> ?????? > >>>>> >>>>> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/tes >>>>> t/lib/SA/SATestUtils.java.html >>>>> >>>>> ?????? > >>>>> ?????? >? ? ? -> You put some System.out.println; are they intended to >>>>> ????? still be >>>>> ?????? > there or were they for debug? >>>>> >>>>> ????? I guess you meant this one: >>>>> ????? System.out.println("Adding 'sudo -E' to the command."); >>>>> >>>>> ????? This one is meant to be there. >>>>> >>>>> ?????? > >>>>> ?????? > >>>>> ?????? >? ? 77? ? ? ? ?for (String val: cmdStringList) { >>>>> ?????? >? ? 78? ? ? ? ? ? ?outStringList.add(val); >>>>> ?????? >? ? 79? ? ? ? ?} >>>>> ?????? > >>>>> ?????? > >>>>> ?????? > Couldn't we use addAll ? >>>>> >>>>> ????? Done. >>>>> ????? The modified webrev is at: >>>>> >>>>> ????? http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html >>>>> >>>>> ????? Thanks, >>>>> ????? Jini. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc From david.holmes at oracle.com Mon Jan 21 05:18:56 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2019 15:18:56 +1000 Subject: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out In-Reply-To: <0194722E-CFE1-4E3A-A521-14910D88B378@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> Message-ID: 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" 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" 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" 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.griffiths at gmail.com Mon Jan 21 09:36:08 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Mon, 21 Jan 2019 09:36:08 +0000 Subject: getPCDescNearDbg returns incorrect PCDesc In-Reply-To: References: <1ed2e1d3cc6943e3be9bcc9551af5fe3@sap.com> Message-ID: Hi, I would be changing the PcDesc returned, yes. I can't comment on the PcDesc having been mapped incorrectly but seems unsafe to change that because then the line numbers for callers further down the stack won't match? But whilst browsing that code I came across nmethod.match_desc: if (!approximate) return pc->pc_offset() == pc_offset; else return (pc-1)->pc_offset() < pc_offset && pc_offset <= pc->pc_offset(); and that logic would match "PcDescTest::run at 7 (line 18)" because its offset gives 0x00007fc3a93bd897 which is >= 0x00007fc3a93bd894 which in turn is > the previous PcDesc. (Not so sure about the situation where pc == 0x00007fc3a93bd892. My version makes it match line 18 but that only works for the imprecise top of stack case. That's because there's a difference between matching a return address further down the stack where you are still executing the line before and matching the same address at the top of the stack where the call has returned and you are about to execute the next line.) Cheers, David On Fri, 18 Jan 2019 at 18:42, Jini George wrote: > > Thank you for the example and the detailed explanation, David. > > I am not sure if the PcDesc being found in getPCDescNearDbg() is > incorrect or if the PcDesc is being mapped to the incorrect bci and line > number (or scope?). In the example, the PcDesc returned for > 0x00007fc3a93bd894 will be the one with real pc = 0x00007fc3a93bd892. > This seems to be correct since the instruction at 0x00007fc3a93bd892 -- > which is: > > mov %edx,%ebp > > is technically a part of the 'iadd'. (since, if i understand right, this > is moving 'i' into 'ebp' before adding 22 (instead of adding i - 1 to > 23)). But the bci and the line number attributed to 0x00007fc3a93bd892 > should be '7' and '18' respectively, instead of '2' and '17' which > belong to the 'isub'. Would you be changing the PcDesc returned with > your proposed fix ? > > I have not been able to delve deeper into this yet. Your fix for the > callers (calling getScopeDescAt() instead of getScopeDescNearDbg()) > seems correct to me. > > Thanks, > Jini. > > On 1/17/2019 5:05 PM, David Griffiths wrote: > > Here is example as promised. First the test program: > > > > 1 public class PcDescTest > > 2 { > > 3 public static void main(String[] args) > > 4 { > > 5 new PcDescTest(); > > 6 } > > 7 > > 8 PcDescTest() > > 9 { > > 10 for (int i = 0; ; i++) { > > 11 run(i); > > 12 } > > 13 } > > 14 > > 15 int run(int i) > > 16 { > > 17 int j = i - 1; > > 18 int k = j + 23; > > 19 if ((j % 1000000) == 0) { > > 20 sleep(); > > 21 } > > 22 return k; > > 23 } > > 24 > > 25 void sleep() > > 26 { > > 27 System.out.println("about to sleep..."); > > 28 try { > > 29 Thread.sleep(10000); > > 30 } catch (InterruptedException e) {} > > 31 System.out.println("...back from sleep"); > > 32 } > > 33 } > > > > run like this: > > > > java -Xmx8m -Xcomp -XX:CompileCommand=dontinline,PcDescTest.run > > -XX:CompileCommand=dontinline,PcDescTest.sleep > > -XX:CompileCommand=print,PcDescTest.run PcDescTest > > > > and it will print the assembler out which includes: > > > > [Verified Entry Point] > > 0x00007fc3a93bd880: mov %eax,-0x14000(%rsp) > > 0x00007fc3a93bd887: push %rbp > > 0x00007fc3a93bd888: sub $0x10,%rsp ;*synchronization entry > > ; - PcDescTest::run at -1 (line 17) > > > > 0x00007fc3a93bd88c: mov %edx,%r11d > > 0x00007fc3a93bd88f: dec %r11d ;*isub > > ; - PcDescTest::run at 2 (line 17) > > > > 0x00007fc3a93bd892: mov %edx,%ebp > > 0x00007fc3a93bd894: add $0x16,%ebp ;*iadd > > ; - PcDescTest::run at 7 (line 18) > > > > 0x00007fc3a93bd897: movslq %r11d,%r10 > > > > In another window, attach gdb (gdb --pid nnnn) and then set a > > breakpoint at the iadd line which I think we can agree is definitely > > the code for line 18: > > > > (gdb) b *0x00007fc3a93bd894 > > > > then continue until the breakpoint hits and then take a core dump: > > > > (gdb) c > > Continuing. > > [Switching to Thread 0x7fc3bfe1a700 (LWP 8354)] > > Thread 2 "java" hit Breakpoint 1, 0x00007fc3a93bd894 in ?? () > > (gdb) gcore > > warning: target file /proc/8353/cmdline contained unexpected null characters > > Saved corefile core.8353 > > (gdb) quit > > > > finally, use jstack to see the stack: > > > > $ jstack `command -v java` core.8353 > > > > and you will see: > > > > - PcDescTest.run(int) @bci=2, line=17 (Compiled frame; information > > may be imprecise) > > - PcDescTest.() @bci=8, line=11 (Compiled frame) > > - PcDescTest.main(java.lang.String[]) @bci=4, line=5 (Interpreted frame) > > > > which is incorrect (admittedly it warns you!) > > > > if I make the change I suggested: > > > > public PCDesc getPCDescNearDbg(Address pc) { > > PCDesc bestGuessPCDesc = null; > > //long bestDistance = 0; > > long bestDistance = Long.MAX_VALUE; > > for (Address p = scopesPCsBegin(); p.lessThan(scopesPCsEnd()); p = > > p.addOffsetTo(pcDescSize)) { > > PCDesc pcDesc = new PCDesc(p); > > // In case pc is null > > //long distance = -pcDesc.getRealPC(this).minus(pc); > > long distance = pcDesc.getRealPC(this).minus(pc) - 1; > > //if ((bestGuessPCDesc == null) || > > //((distance >= 0) && (distance < bestDistance))) { > > if (distance >= 0 && distance < bestDistance) { > > bestGuessPCDesc = pcDesc; > > bestDistance = distance; > > } > > > > then it gives: > > > > - PcDescTest.run(int) @bci=7, line=18 (Compiled frame; information > > may be imprecise) > > - PcDescTest.() @bci=12, line=10 (Compiled frame) > > - PcDescTest.main(java.lang.String[]) @bci=4, line=5 (Interpreted frame) > > > > but as you can see the caller line is now incorrect. > > > > Cheers, > > > > David > > > > > > On Thu, 17 Jan 2019 at 09:12, David Griffiths wrote: > >> > >> Hi Jc, ok thanks, I'll see if I can come up with a simple example. > >> > >> Cheers, > >> > >> David > >> > >> On Wed, 16 Jan 2019 at 17:30, JC Beyler wrote: > >>> > >>> Hi David, > >>> > >>> The explanation you are providing is clear to me, though I'm not sure at all what the right fix would be in this case. I would agree that there might be a bug here but it would be easier to see if you could provide an easy reproducer that shows how the initial line is off by 1 and then how it messes up higher in the stack if you try to fix it by your -1. > >>> > >>> My best guess is that there is a difference between code paths as you are saying and we might have to differentiate top frame and other frames for this calculation but without a reproducer to see it in action, it is hard to tell. > >>> > >>> Thanks, > >>> Jc > >>> > >>> On Wed, Jan 16, 2019 at 7:58 AM Doerr, Martin wrote: > >>>> > >>>> Hi David, > >>>> > >>>> re-posting to serviceability mailing list since you're referring to a method from > >>>> https://docs.oracle.com/javase/jp/8/docs/serviceabilityagent/sun/jvm/hotspot/code/NMethod.html > >>>> > >>>> Best regards, > >>>> Martin > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: hotspot-dev On Behalf Of David Griffiths > >>>> Sent: Mittwoch, 16. Januar 2019 12:08 > >>>> To: hotspot-dev at openjdk.java.net > >>>> Subject: getPCDescNearDbg returns incorrect PCDesc > >>>> > >>>> Hi, I'd like some help please understanding what appears to be a bug in > >>>> getPCDescNearDbg. The problem is caused by the fact that the _pc_offset > >>>> value stored in a PcDesc is actually the offset of the code contained in > >>>> the _next_ PcDesc rather than the current one. I assume it's done like this > >>>> so that obtaining stack traces works correctly. At least on x86, the last > >>>> instruction in a PcDesc chunk is the callq which means that the return > >>>> address pc points to the next PcDesc. Therefore associating the PcDesc > >>>> containing the callq with the address of the next PcDesc chunk means that > >>>> the matching works in getPCDescAt. > >>>> > >>>> But this causes "off by one" errors in getPCDescNearDbg which appears to > >>>> expect the PcDesc getRealPC address to be that of the PcDesc itself rather > >>>> than the following one. So you sometimes see incorrect top of stack line > >>>> numbers when debugging. (And this would presumably also affect profilers). > >>>> > >>>> I can fix the top of stack issue by changing distance to: > >>>> > >>>> long distance = pcDesc.getRealPC(this).minus(pc) - 1 > >>>> > >>>> but this then messes up the line numbers further down the stack because > >>>> they are trying to match against return pcs. > >>>> > >>>> Anybody come across this before, is my analysis correct? > >>>> > >>>> Cheers, > >>>> > >>>> David > >>> > >>> > >>> > >>> -- > >>> > >>> Thanks, > >>> Jc From goetz.lindenmaier at sap.com Mon Jan 21 10:25:17 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 21 Jan 2019 10:25:17 +0000 Subject: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5 In-Reply-To: <0b3b612c-c12c-b36a-9f5a-933c55cf0a7a@oracle.com> References: <37914195-ba50-c205-13de-3ca5ca65261b@oracle.com> <9ccfc82e-53b1-a5ec-cca0-2321eeb217a4@oracle.com> <6d0cd289-41da-de04-bfcf-77f25fcc1d6f@oracle.com> <2b441c90-c926-4286-9ca7-889f1fc0b4b6@default> <96a914e1729a4240843b5fe2423cef93@sap.com> <6d7bea9c-9158-3de7-23e4-04967596b4e1@oracle.com> <0b3b612c-c12c-b36a-9f5a-933c55cf0a7a@oracle.com> Message-ID: <99cb1e48ee444f0bbb0c5f5741a75752@sap.com> Sure, I'll try to test it. Best regards, Goetz. > -----Original Message----- > From: Jini George > Sent: Sonntag, 20. Januar 2019 17:12 > To: David Holmes ; Lindenmaier, Goetz > ; serviceability-dev at openjdk.java.net > Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo > privileges to enable MacOS tests on Mach5 > > Thanks, Goetz for letting me know of the failure and thanks, David for > the suggestion wrt SkippedException. Goetz, I will send you a patch > off-list, and it would be great if you could test it again for me. > > Thanks, > Jini. > > On 1/20/2019 4:18 AM, David Holmes wrote: > > On 18/01/2019 11:30 pm, Lindenmaier, Goetz wrote: > >> Hi Jini, > >> > >> we see test failing after this change arrived deeper in our > >> infrastructure. > >> On a linuxx86_64 docker container it does not work. > >> > >> This is because you now throw Error() if shouldSAAttach() returns false. > >> I think you need this: > >> --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java??? Thu > >> Jan 03 17:30:03 2019 +0100 > >> +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java??? Fri > >> Jan 18 14:25:05 2019 +0100 > >> @@ -190,8 +190,9 @@ > >> ???????????????????? needPrivileges = true; > >> ???????????????? } > >> ????????????? } else { > >> -??????????????? System.out.println("SA attach not expected to work. > >> Insufficient privileges."); > >> -??????????????? throw new Error("Cannot attach."); > >> +??????????????? // Silently skip the test if we don't have enough > >> permissions to attach > >> +??????????????? System.out.println("SA attach not expected to work - > >> test skipped."); > >> +??????????????? return null; > > > > We should be able to use SkippedException for this case. > > > > David > > > >> ????????????? } > >> ????????? } > >> > >> This is because canPtraceAttachLinux() in Platform.java returns false. > >> > >> What do you think? > >> > >> Best regards, > >> ?? Goetz. > >> > >> > >> > >>> -----Original Message----- > >>> From: serviceability-dev > >>> On > >>> Behalf Of Jini George > >>> Sent: Montag, 14. Januar 2019 06:08 > >>> To: Sharath Ballal ; JC Beyler > >>> ; serviceability-dev at openjdk.java.net > >>> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo > >>> privileges to enable MacOS tests on Mach5 > >>> > >>> Thank you very much, Sharath, for the review. My comments inline. > >>> > >>> On 1/12/2019 3:38 PM, Sharath Ballal wrote: > >>>> Hi Jini, > >>>> > >>>> ClhsdbLauncher.java > >>>> 1. Is the platform check not required in case of core files ? > >>> No, it is not needed. The permission issues don't exist. > >>> > >>>> -??????? if (!Platform.shouldSAAttach()) { > >>>> -??????????? // Silently skip the test if we don't have enough > >>>> permissions to attach > >>>> -??????????? System.out.println("SA attach not expected to work - > >>>> test skipped."); > >>>> -??????????? return null; > >>>> -??????? } > >>>> - > >>>> > >>>> 2. Nit: extra line at 135 > >>> > >>> Done. > >>> > >>> Thanks, > >>> Jini. > >>>> > >>>> > >>>> Thanks, > >>>> Sharath > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Jini George > >>>> Sent: Friday, January 11, 2019 9:46 AM > >>>> To: JC Beyler; serviceability-dev at openjdk.java.net > >>>> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo > >>> privileges to enable MacOS tests on Mach5 > >>>> > >>>> Thanks again, JC! :-) > >>>> > >>>> Folks, Could I please get one more review on this ? > >>>> > >>>> -Jini. > >>>> > >>>> On 1/11/2019 9:38 AM, JC Beyler wrote: > >>>>> Hi Jini, > >>>>> > >>>>> Looks?good to me now :) Thanks for handling the comments :) Jc > >>>>> > >>>>> > >>>>> On Tue, Jan 8, 2019 at 8:11 PM Jini George >>>>> > wrote: > >>>>> > >>>>> ????? Thank you very much for the review, JC. My comments inline: > >>>>> > >>>>> ????? On 1/8/2019 12:22 AM, JC Beyler wrote: > >>>>> ?????? > > >>>>> ?????? > > >>>>> > >>> > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/s > >>> > >>> erviceability/sa/ClhsdbLauncher.java.udiff.html > >>>>> ?????? >? ? +? ? ? ? ? ? ? ? // by appending 'sudo' to it. Check > >>>>> now if sudo > >>>>> ?????? > passes in this > >>>>> ?????? >? ? +? ? ? ? ? ? ? ? // environment with a simple 'echo' > >>>>> command. > >>>>> ?????? >? ? ? ?-> Really shouldn't provide implementation details > >>>>> about > >>>>> ????? what is > >>>>> ?????? > being done by that method; if we change that, this comment > >>>>> will > >>>>> ????? rot :-) > >>>>> ?????? > canAddPrivileges is explicit enough in my mind > >>>>> > >>>>> ????? Done. I have removed the comment. > >>>>> > >>>>> ?????? > > >>>>> ?????? > > >>>>> > >>>>> > http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/tes > >>>>> t/lib/SA/SATestUtils.java.html > >>>>> > >>>>> ?????? > > >>>>> ?????? >? ? ? -> You put some System.out.println; are they intended to > >>>>> ????? still be > >>>>> ?????? > there or were they for debug? > >>>>> > >>>>> ????? I guess you meant this one: > >>>>> ????? System.out.println("Adding 'sudo -E' to the command."); > >>>>> > >>>>> ????? This one is meant to be there. > >>>>> > >>>>> ?????? > > >>>>> ?????? > > >>>>> ?????? >? ? 77? ? ? ? ?for (String val: cmdStringList) { > >>>>> ?????? >? ? 78? ? ? ? ? ? ?outStringList.add(val); > >>>>> ?????? >? ? 79? ? ? ? ?} > >>>>> ?????? > > >>>>> ?????? > > >>>>> ?????? > Couldn't we use addAll ? > >>>>> > >>>>> ????? Done. > >>>>> ????? The modified webrev is at: > >>>>> > >>>>> ????? http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html > >>>>> > >>>>> ????? Thanks, > >>>>> ????? Jini. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Thanks, > >>>>> Jc From zanglin5 at jd.com Tue Jan 22 06:18:06 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Tue, 22 Jan 2019 06:18:06 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> References: <336c32cab24f42e388ccab4910c0d3b6@jd.com> <2ae477cd25b64ef2ab82d20f89ab8540@jd.com> <1fa6b35a9ad64ca5b88529ae5481d734@jd.com> <3281becb646347759cf0a9412524eb1e@jd.com> <70826c967ec543df9febd907812d4361@jd.com> , <0033D2ED-B80A-41C4-BCAD-642292B19D31@amazon.com> Message-ID: <3f34421b11514358af3ed110b830a7f3@jd.com> 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 jcbeyler at google.com Tue Jan 22 18:28:20 2019 From: jcbeyler at google.com (JC Beyler) Date: Tue, 22 Jan 2019 10:28:20 -0800 Subject: RFR(S) 8215113: Sampling interval not always correct In-Reply-To: References: <45A5FFFC-729A-4E50-877E-955CE17BF9FA@amazon.com> Message-ID: Friendly ping for this RFR :) Jc On Fri, Jan 11, 2019 at 6:54 PM JC Beyler wrote: > Hi Paul, > > Thanks, fixed all of the above in my local branch :-), > Jc > > On Fri, Jan 11, 2019 at 5:07 PM Hohensee, Paul > wrote: > >> Nits: >> >> >> >> memAllocator.cpp: >> >> >> >> Copyright line should read >> >> >> >> * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights >> reserved. >> >> >> >> The comment >> >> >> >> // Tell tlab to forget the bytes_since if we passed it to the heap sampler. >> >> >> >> would be clearer if it read >> >> >> >> // Tell tlab to forget bytes_since_last if we passed it to the heap sampler. >> >> Same copyright line comment for HeapMonitor.java, >> HeapMonitorArrayAllSampledTest.java and HeapMonitorStatArrayCorrectnessTest.java >> as for memAllocator.cpp. >> >> Otherwise lgtm, no need for another webrev on my account. >> >> >> Thanks, >> >> >> >> Paul >> >> >> >> *From: *serviceability-dev >> on behalf of JC Beyler >> *Date: *Thursday, January 10, 2019 at 11:28 AM >> *To: *OpenJDK Serviceability >> *Subject: *RFR(S) 8215113: Sampling interval not always correct >> >> >> >> Hi all, >> >> >> >> Could I get a review for this: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8215113/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215113 >> >> >> >> This fixes the code to do the right accounting in sampling and get the >> right sample counts and sampled objects. My error percentage calculation >> was wrong so the two tests I had added were false positives (my apologies). >> >> >> >> Thanks, >> >> Jc >> > > > -- > > Thanks, > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jan 22 20:32:10 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 22 Jan 2019 12:32:10 -0800 Subject: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file In-Reply-To: References: <3da734c5-b3ab-eb83-9314-1e47946ba5e5@oracle.com> <1ddd54b2-abd6-d399-4156-3877eb73535a@oracle.com> <5C38BDDD.80602@oracle.com> <5C38E618.3020904@oracle.com> <5C3F5265.2090709@oracle.com> <4d5b899c-8719-d77e-aba5-aa38bf42201e@oracle.com> Message-ID: Hi Gary, It looks Okay in general. But I have a small concern/question about the line: 65 if (!inOutClassFile.renameTo(tmpInOutClassFile)) { What if the tmpInOutClassFile does exist in the system? Is it possible there can be some leftover from previous runs? Thanks, Serguei On 1/17/19 3:06 AM, gary.adams at oracle.com wrote: > Updated webrev: > > ?? Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.01/ > > On 1/17/19 12:44 AM, David Holmes wrote: >> On 17/01/2019 1:48 am, Gary Adams wrote: >>> Looking through the test history for the vm/mlvm version of >>> InstallSDE.java there has never >>> been a reported problem with the renameTo operation. I'm inclined to >>> not apply the change >>> made to the com/sun/jdi/sde test until the failure is observed. >> >> There is much greater use of InstallSDE than just the vm/mlvm test >> that I mentioned earlier. InstallSDE is also used by: >> >> ./hotspot/jtreg/vmTestbase/nsk/share/jdi/sde/SDEDebugger.java >> >> which in turn is used by numerous nsk/jdi tests. >> >> It would be prudent IMHO to fix both versions. It would be extremely >> surprising (and raise doubt about the actual problem) if the jdk >> tests fail but the nsk tests never do. >> >> David >> ----- >> >>> I'm satisfied with the testing at this point and could use another >>> reviewer before >>> pushing. >>> >>> On 1/11/19, 6:14 PM, David Holmes wrote: >>>> Hi Gary, >>>> >>>> As I mentioned earlier there are two versions of InstallSDE.java in >>>> the tests, so both should be updated. >>>> >>>> Your strategy to avoid the windows delete issue seems reasonable. >>>> >>>> David >>>> >>>> On 12/01/2019 4:53 am, Gary Adams wrote: >>>>> Here's a webrev for review purposes. >>>>> No failures after ~1000 testruns. >>>>> >>>>> ?? Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ >>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>> >>>>> On 1/11/19, 11:01 AM, Gary Adams wrote: >>>>>> I've been reading recently that Windows delete file operations >>>>>> can be delayed, if there are open handles against the file. >>>>>> Others have reported virus checkers or other indexing >>>>>> programs may hold a handle on a file preventing the >>>>>> deletion being completed. >>>>>> >>>>>> The basic logic in InstallSDE is >>>>>> ?? A + B = C >>>>>> ?? delete A >>>>>> ?? rename C to A >>>>>> >>>>>> I think we can work around the issue with >>>>>> ? rename A to A1 >>>>>> ? A1 + B = C >>>>>> ? delete A1 >>>>>> ? rename C to A >>>>>> >>>>>> diff --git a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>>> b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>>> --- a/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>>> +++ b/test/jdk/com/sun/jdi/sde/InstallSDE.java >>>>>> @@ -31,9 +31,17 @@ >>>>>> ???? } >>>>>> >>>>>> ???? static void install(File inOutClassFile, File attrFile) >>>>>> throws IOException { >>>>>> -??????? File tmpFile = new File(inOutClassFile.getPath() + "tmp"); >>>>>> -??????? new InstallSDE(inOutClassFile, attrFile, tmpFile); >>>>>> -??????? if (!inOutClassFile.delete()) { >>>>>> +??????? File tmpFile = new File(inOutClassFile.getPath() + >>>>>> "tmp-out"); >>>>>> +??????? File tmpInOutClassFile = new >>>>>> File(inOutClassFile.getPath() + "tmp-in"); >>>>>> + >>>>>> +??????? // Workaround delayed file deletes on Windows using a >>>>>> tmp file name >>>>>> +??????? if (!inOutClassFile.renameTo(tmpInOutClassFile)) { >>>>>> +??????????? throw new IOException("tmp copy of inOutClassFile >>>>>> failed"); >>>>>> +??????? } >>>>>> + >>>>>> +??????? new InstallSDE(tmpInOutClassFile, attrFile, tmpFile); >>>>>> + >>>>>> +??????? if (!tmpInOutClassFile.delete()) { >>>>>> ???????????? throw new IOException("inOutClassFile.delete() >>>>>> failed"); >>>>>> ???????? } >>>>>> ???????? if (!tmpFile.renameTo(inOutClassFile)) { >>>>>> >>>>>> >>>>>> Testing in progress ... >>>>>> >>>>>> On 1/11/19, 7:40 AM, David Holmes wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> On 11/01/2019 9:22 pm, gary.adams at oracle.com wrote: >>>>>>>> After ~1000 testruns I hit a failure in MangleTest and a jtreg >>>>>>>> agent communication issue with SourceDebugExtension. >>>>>>>> >>>>>>>> https://java.se.oracle.com:10065/mdash/builds/2019-01-10-1159535.gary.adams.jdk-jdb/results?search=status%3Afailed%20AND%20-state%3Ainvalid >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *java.io.IOException: tmpFile.renameTo(inOutClassFile) failed* >>>>>>>> ??? at InstallSDE.install(InstallSDE.java:40) >>>>>>>> ??? at MangleTest.testSetUp(MangleTest.java:38) >>>>>>>> ??? at MangleTest.main(MangleTest.java:31) >>>>>>> >>>>>>> You might want to add some code in: >>>>>>> >>>>>>> ./java.base/windows/native/libjava/WinNTFileSystem_md.c:Java_java_io_WinNTFileSystem_rename0 >>>>>>> >>>>>>> >>>>>>> that checks the result of _wrename to see what error is >>>>>>> occurring. I suspect it will be EACCES which won't be that helpful: >>>>>>> >>>>>>> https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/rename-wrename?view=vs-2017 >>>>>>> >>>>>>> >>>>>>> but it would be good to confirm. >>>>>>> >>>>>>>> >>>>>>>> result: Error. Agent communication error: >>>>>>>> java.io.IOException:*Agent: unexpected op: 71;* check console >>>>>>>> log for any additional details >>>>>>>> >>>>>>>> I added some additional print outs for the rename issue and >>>>>>>> have run ~2000 additional >>>>>>>> testruns with no test failures repeated, yet. But there were 2 >>>>>>>> mach5 reported errors: >>>>>>>> >>>>>>>> ??? TimeoutException in CLEANUP. >>>>>>> >>>>>>> That's a mach5 issue. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> I'll do some more investigation with making the rename >>>>>>>> operation more robust >>>>>>>> before removing SourceDebugExtensionTest from the problem list. >>>>>>>> >>>>>>>> On 1/10/19 8:28 PM, David Holmes wrote: >>>>>>>>> Hi Gary, >>>>>>>>> >>>>>>>>> On 10/01/2019 11:02 pm, gary.adams at oracle.com wrote: >>>>>>>>>> SourceDebugExtensionTest was placed on the ProblemList >>>>>>>>>> because of filesystem rename issues on Windows 2012 test >>>>>>>>>> systems. >>>>>>>>>> The test does not appear to fail on the current mach5 test >>>>>>>>>> systems. >>>>>>>>>> There was some question concerning symbolic links that might >>>>>>>>>> have >>>>>>>>>> been problematic at that time. Additional testing in progress... >>>>>>>>> >>>>>>>>> Also note that there are two sets of SDE related tests and two >>>>>>>>> versions of the InstallSDE.java file that both use renameTo. >>>>>>>>> In nsk the testcase seems to be: >>>>>>>>> >>>>>>>>> ./hotspot/jtreg/vmTestbase/vm/mlvm/share/StratumClassesBuilder.java >>>>>>>>> >>>>>>>>> >>>>>>>>> and AFAICS it is not excluded. So removing the exclusion seems >>>>>>>>> reasonable to me. It was most like a concurrency issue with >>>>>>>>> the virus scanner. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 >>>>>>>>>> >>>>>>>>>> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >>>>>>>>>> --- a/test/jdk/ProblemList.txt >>>>>>>>>> +++ b/test/jdk/ProblemList.txt >>>>>>>>>> @@ -838,8 +838,6 @@ >>>>>>>>>> >>>>>>>>>> ? com/sun/jdi/RepStep.java 8043571 generic-all >>>>>>>>>> >>>>>>>>>> -com/sun/jdi/sde/SourceDebugExtensionTest.java 8158066 >>>>>>>>>> windows-all >>>>>>>>>> - >>>>>>>>>> ? com/sun/jdi/NashornPopFrameTest.java 8187143 generic-all >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jan 22 20:32:28 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 22 Jan 2019 12:32:28 -0800 Subject: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails In-Reply-To: <65e5db84-9561-8e7e-1aca-1047db1c4b8d@oracle.com> References: <645447f2-7755-dbf8-d672-e39464a0b156@oracle.com> <5C40CF27.4000107@oracle.com> <65e5db84-9561-8e7e-1aca-1047db1c4b8d@oracle.com> Message-ID: <6cccbaa9-e01a-5374-330c-c61dfc1fa8dc@oracle.com> Hi Alex, It looks good to me. Thanks, Serguei On 1/17/19 12:21 PM, Alex Menkov wrote: > Hi Gary, > > On 01/17/2019 10:53, Gary Adams wrote: >> I like the fact that test.timeout.factor is applied as a multiplier. >> >> It's not clear why an upper limit had to be added. > > As you noted there 3 cases where Thread.join() is called, but the > expected behavior is different. objWaiterThr2 and popFrameClsThr are > expected to exit, but objWaiterThr1 is expected to be alive after join > (i.e. the call is expected to take the time specified). I don't want > to increase the test run time (for timeout.factor == 10 it would take > 18 extra seconds), so I restricted the timeout for the case. > >> Is that 50 or 5 seconds? > > Thank you for the catch. It should be 5 seconds (5000 ms) > > Updated webrev: > http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev.02/ > > --alex > >> >> ??148???????????? objWaiterThr1.join(Math.min(WAIT_TIME, 50000)); >> >> Why are the other wait times not limited? >> >> ??136???????????? objWaiterThr2.join(WAIT_TIME); >> >> ... >> >> ??169???????????????? popFrameClsThr.join(WAIT_TIME); >> >> >> If you need to apply the upper limit, then it would be better to >> apply it >> at the beginning. >> >> ?? 38???? static final long WAIT_TIME = >> Math.min(Utils.adjustTimeout(2000),5000); >> >> >> >> >> >> On 1/16/19, 6:28 PM, Alex Menkov wrote: >>> Hi all, >>> >>> please review a fix for >>> https://bugs.openjdk.java.net/browse/JDK-8216386 >>> webrev: >>> http://cr.openjdk.java.net/~amenkov/popframe005_wait_time/webrev/ >>> >>> The fix updates WAIT_TIME to depend on test.timeout.factor system >>> property. >>> WAIT_TIME value is used as argument of Thread.join(). >>> For the case when the thread is expected to be alive (i.e. >>> Thread.join() exits by timeout) the timeout value is restricted by 5 >>> seconds to avoid long run time with big timeout.factor values. >>> >>> --alex >> From serguei.spitsyn at oracle.com Tue Jan 22 20:54:04 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 22 Jan 2019 12:54:04 -0800 Subject: RFR(S) 8215113: Sampling interval not always correct In-Reply-To: <45A5FFFC-729A-4E50-877E-955CE17BF9FA@amazon.com> References: <45A5FFFC-729A-4E50-877E-955CE17BF9FA@amazon.com> Message-ID: Hi Jc, It looks good to me too. Thanks, Serguei On 1/11/19 5:07 PM, Hohensee, Paul wrote: > > Nits: > > memAllocator.cpp: > > Copyright line should read > > * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights > reserved. > > The comment > > // Tell tlab to forget the bytes_since if we passed it to the heap > sampler. > > would be clearer if it read > > // Tell tlab to forget bytes_since_last if we passed it to the heap > sampler. > > > Same copyright line comment for HeapMonitor.java, > HeapMonitorArrayAllSampledTest.java and > HeapMonitorStatArrayCorrectnessTest.java as for memAllocator.cpp. > > Otherwise lgtm, no need for another webrev on my account. > > > Thanks, > > Paul > > *From: *serviceability-dev > on behalf of JC Beyler > > *Date: *Thursday, January 10, 2019 at 11:28 AM > *To: *OpenJDK Serviceability > *Subject: *RFR(S) 8215113: Sampling interval not always correct > > Hi all, > > Could I get a review for this: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8215113/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215113 > > This fixes the code to do the right accounting in sampling and get the > right sample counts and sampled objects. My error percentage > calculation was wrong so the two tests I had added were false > positives (my apologies). > > Thanks, > > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jan 22 21:13:53 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 22 Jan 2019 13:13:53 -0800 Subject: RFR(S) 8215113: Sampling interval not always correct In-Reply-To: References: <45A5FFFC-729A-4E50-877E-955CE17BF9FA@amazon.com> Message-ID: On 1/22/19 12:54 PM, serguei.spitsyn at oracle.com wrote: > Hi Jc, > > It looks good to me too. Forgot to say that I hope it was tested well. Thanks, Serguei > > Thanks, > Serguei > > > On 1/11/19 5:07 PM, Hohensee, Paul wrote: >> >> Nits: >> >> memAllocator.cpp: >> >> Copyright line should read >> >> * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights >> reserved. >> >> The comment >> >> // Tell tlab to forget the bytes_since if we passed it to the heap >> sampler. >> >> would be clearer if it read >> >> // Tell tlab to forget bytes_since_last if we passed it to the heap >> sampler. >> >> >> Same copyright line comment for HeapMonitor.java, >> HeapMonitorArrayAllSampledTest.java and >> HeapMonitorStatArrayCorrectnessTest.java as for memAllocator.cpp. >> >> Otherwise lgtm, no need for another webrev on my account. >> >> >> Thanks, >> >> Paul >> >> *From: *serviceability-dev >> on behalf of JC Beyler >> >> *Date: *Thursday, January 10, 2019 at 11:28 AM >> *To: *OpenJDK Serviceability >> *Subject: *RFR(S) 8215113: Sampling interval not always correct >> >> Hi all, >> >> Could I get a review for this: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8215113/webrev.00/ >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8215113 >> >> This fixes the code to do the right accounting in sampling and get >> the right sample counts and sampled objects. My error percentage >> calculation was wrong so the two tests I had added were false >> positives (my apologies). >> >> Thanks, >> >> Jc >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue Jan 22 21:41:03 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 22 Jan 2019 13:41:03 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: References: Message-ID: <8f466791-fe92-6ca1-62da-dc9a562e7648@oracle.com> Hi Daniil, It'd be nice if Chris has a chance to look at this fix. He has most recent experience in this area. Thanks, Serguei On 1/17/19 6:08 PM, Daniil Titov wrote: > Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! > led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks! > --Daniil > > From chris.plummer at oracle.com Wed Jan 23 04:47:57 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 22 Jan 2019 20:47:57 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: <8f466791-fe92-6ca1-62da-dc9a562e7648@oracle.com> References: <8f466791-fe92-6ca1-62da-dc9a562e7648@oracle.com> Message-ID: <38b70173-8d0a-04e2-ccce-cc009618693a@oracle.com> Yes, I will have a look at it tomorrow. Chris On 1/22/19 1:41 PM, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > It'd be nice if Chris has a chance to look at this fix. > He has most recent experience in this area. > > Thanks, > Serguei > > > On 1/17/19 6:08 PM, Daniil Titov wrote: >> Please review the change that fixes JDB stepping issue for a specific >> case when the single step request was initiated earlier in the stack, >> previous calls were for methods in the filtered classes (single >> stepping was disabled), handleMethodEnterEvent() re-enabled stepping >> and the first bytecode upon entering the current method requires >> resolving constant pool entry. In this case the execution resumes in >> java.lang.Classloader.loadClass() and since it is also a filtered >> class the single stepping is getting disabled again (stepControl.c >> :593).? When loadClass() exits a notifyFramePop() is called on the >> loadClass() frame but due to condition fromDepth >= afterPopDepth? at >> stepControl.c :346 (that doesn't hold in this case, in this case >> fromDepth is 1 and afterPopDepth? is 4) the notifyFramePop() fails to >> enable single stepping back. The fix removes the excessive condition >> fromDepth >= afterPopDepth? in notifyFramePop() method >> (stepControl.c:346)? to ensure that when a method cal! >> ? led from the stepping frame (and during which we had stepping >> disabled) has returned the stepping is re-enabled to continue >> instructions steps in the original stepping frame. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 >> >> Thanks! >> --Daniil >> >> > > From chris.plummer at oracle.com Wed Jan 23 23:53:50 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 23 Jan 2019 15:53:50 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: References: Message-ID: Hi Daniil, I don't see an explanation for why fromDepth is 1 and afterPopDepth is 4. ??????? currentDepth = getThreadFrameCount(thread); ??????? fromDepth = step->fromStackDepth; ??????? afterPopDepth = currentDepth-1; step->fromStackDepth got setup when single stepping was first setup for this thread. There was also a notifyFramePop() done at this time, but I think that's just to catch exiting from the method you were single stepping in, and has no bearing in the case we are looking at here, where we area still some # of frames below where we user last issued a STEP_INTO. The FRAME_POP we are receiving now is not the one for when step->fromStackDepth was setup, but is for when we stepped into a filtered method. I think this is what the "fromDepth > afterPopDepth" check is for. I think the current logic is correct for intended handling of a FRAME_POP event. Although your fix is probably solving the problem, I get the feeling it is enabling single stepping too soon in many cases. That many not turn up as an error in any tests, but could cause debugging performance issues, or for the user to see spurious single step events that they were not expecting. I think the bug actually occurs long before we ever get to this point in the code (and we should in fact not be getting here). In my last entry in the bug I mentioned JvmtiHideSingleStepping(), and how it is used to turn off single stepping while we are doing invoke and field resolution, but doesn't seem to be used during class resolution, which is what we are doing here. If it where used, then the agent would never even see the SINGLE_STEP when loadClass() is entered, therefore no notifyFramePop() would be done, and we would not be relying on this code in handleFramePopEvent(). Instead, we would receive the next SINGLE_STEP event after cp resolution is complete, and we are finally executing the now resolved opc_new opcode. I'm hoping Serguei and/or Alex can also comment on this, since I think they were dealing with JvmtiHideSingleStepping() last month. thanks, Chris On 1/17/19 6:08 PM, Daniil Titov wrote: > Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! > led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks! > --Daniil > > From daniil.x.titov at oracle.com Thu Jan 24 18:38:57 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 24 Jan 2019 10:38:57 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: References: Message-ID: Hi Chris and JC, Thank you for reviewing this change. Please review a new version of the fix that uses the approach Chris suggested ( disabling the single stepping during the class resolution). Just in case please find below the stack trace for this case when loadClass() method is entered. #0 SystemDictionary::load_instance_class(Symbol*, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:853 #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:271 #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:202 #5 ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 #6 ConstantPool::klass_at(int, Thread*) at open/src/hotspot/share/oops/constantPool.hpp:382 #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 # 8 .... Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 Thanks, Daniil ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: Hi Daniil, I don't see an explanation for why fromDepth is 1 and afterPopDepth is 4. currentDepth = getThreadFrameCount(thread); fromDepth = step->fromStackDepth; afterPopDepth = currentDepth-1; step->fromStackDepth got setup when single stepping was first setup for this thread. There was also a notifyFramePop() done at this time, but I think that's just to catch exiting from the method you were single stepping in, and has no bearing in the case we are looking at here, where we area still some # of frames below where we user last issued a STEP_INTO. The FRAME_POP we are receiving now is not the one for when step->fromStackDepth was setup, but is for when we stepped into a filtered method. I think this is what the "fromDepth > afterPopDepth" check is for. I think the current logic is correct for intended handling of a FRAME_POP event. Although your fix is probably solving the problem, I get the feeling it is enabling single stepping too soon in many cases. That many not turn up as an error in any tests, but could cause debugging performance issues, or for the user to see spurious single step events that they were not expecting. I think the bug actually occurs long before we ever get to this point in the code (and we should in fact not be getting here). In my last entry in the bug I mentioned JvmtiHideSingleStepping(), and how it is used to turn off single stepping while we are doing invoke and field resolution, but doesn't seem to be used during class resolution, which is what we are doing here. If it where used, then the agent would never even see the SINGLE_STEP when loadClass() is entered, therefore no notifyFramePop() would be done, and we would not be relying on this code in handleFramePopEvent(). Instead, we would receive the next SINGLE_STEP event after cp resolution is complete, and we are finally executing the now resolved opc_new opcode. I'm hoping Serguei and/or Alex can also comment on this, since I think they were dealing with JvmtiHideSingleStepping() last month. thanks, Chris On 1/17/19 6:08 PM, Daniil Titov wrote: > Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! > led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks! > --Daniil > > From chris.plummer at oracle.com Thu Jan 24 19:19:39 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 24 Jan 2019 11:19:39 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: References: Message-ID: Hi Daniil, Thanks for the stack track. I was just about to send an email asking for it when your new RFR arrived. The fix looks good. I think you also need to apply it here: InterpreterRuntime::ldc() InterpreterRuntime::anewarray() InterpreterRuntime::multianewarray() InterpreterRuntime::quicken_io_cc() I wonder if it wouldn't be better if you moved the disabling into ConstantPool::klass_at_impl() thanks, Chris On 1/24/19 10:38 AM, Daniil Titov wrote: > Hi Chris and JC, > > Thank you for reviewing this change. Please review a new version of the fix that uses > the approach Chris suggested ( disabling the single stepping during the class resolution). > > Just in case please find below the stack trace for this case when loadClass() method is entered. > > #0 SystemDictionary::load_instance_class(Symbol*, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 > #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:853 > #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:271 > #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 > #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:202 > #5 ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 > #6 ConstantPool::klass_at(int, Thread*) at open/src/hotspot/share/oops/constantPool.hpp:382 > #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 > # 8 > .... > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks, > Daniil > > ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: > > Hi Daniil, > > I don't see an explanation for why fromDepth is 1 and afterPopDepth is 4. > > currentDepth = getThreadFrameCount(thread); > fromDepth = step->fromStackDepth; > afterPopDepth = currentDepth-1; > > step->fromStackDepth got setup when single stepping was first setup for > this thread. There was also a notifyFramePop() done at this time, but I > think that's just to catch exiting from the method you were single > stepping in, and has no bearing in the case we are looking at here, > where we area still some # of frames below where we user last issued a > STEP_INTO. The FRAME_POP we are receiving now is not the one for when > step->fromStackDepth was setup, but is for when we stepped into a > filtered method. I think this is what the "fromDepth > afterPopDepth" > check is for. I think the current logic is correct for intended handling > of a FRAME_POP event. Although your fix is probably solving the problem, > I get the feeling it is enabling single stepping too soon in many cases. > That many not turn up as an error in any tests, but could cause > debugging performance issues, or for the user to see spurious single > step events that they were not expecting. > > I think the bug actually occurs long before we ever get to this point in > the code (and we should in fact not be getting here). In my last entry > in the bug I mentioned JvmtiHideSingleStepping(), and how it is used to > turn off single stepping while we are doing invoke and field resolution, > but doesn't seem to be used during class resolution, which is what we > are doing here. If it where used, then the agent would never even see > the SINGLE_STEP when loadClass() is entered, therefore no > notifyFramePop() would be done, and we would not be relying on this code > in handleFramePopEvent(). Instead, we would receive the next SINGLE_STEP > event after cp resolution is complete, and we are finally executing the > now resolved opc_new opcode. > > I'm hoping Serguei and/or Alex can also comment on this, since I think > they were dealing with JvmtiHideSingleStepping() last month. > > thanks, > > Chris > > > > On 1/17/19 6:08 PM, Daniil Titov wrote: > > Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! > > led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > Thanks! > > --Daniil > > > > > > > > > From serguei.spitsyn at oracle.com Thu Jan 24 20:22:06 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Jan 2019 12:22:06 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: References: Message-ID: <7f6ac457-efd9-ac5d-a791-8e5080d50c2e@oracle.com> Hi Daniil, I wonder what tests do you run to make sure nothing is broken. Thanks, Serguei On 1/24/19 11:19, Chris Plummer wrote: > Hi Daniil, > > Thanks for the stack track. I was just about to send an email asking > for it when your new RFR arrived. > > The fix looks good. I think you also need to apply it here: > > InterpreterRuntime::ldc() > InterpreterRuntime::anewarray() > InterpreterRuntime::multianewarray() > InterpreterRuntime::quicken_io_cc() > > I wonder if it wouldn't be better if you moved the disabling into > ConstantPool::klass_at_impl() > > thanks, > > Chris > > On 1/24/19 10:38 AM, Daniil Titov wrote: >> Hi Chris and JC, >> >> Thank you for reviewing this change.? Please review a new version of >> the fix that uses >> the approach Chris suggested ( disabling the single stepping during >> the class resolution). >> >> Just in case please find below the stack trace for this case when >> loadClass() method is entered. >> >> #0?????????? SystemDictionary::load_instance_class(Symbol*, Handle, >> Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 >> #1??? SystemDictionary::resolve_instance_class_or_null(Symbol*, >> Handle, Handle, Thread*) at >> open/src/hotspot/share/classfile/systemDictionary.cpp:853 >> #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, >> Handle, Handle, Thread*) at >> open/src/hotspot/share/classfile/systemDictionary.cpp:271 >> #3??? SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, >> Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 >> #4??? SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, >> bool, Thread*) at >> open/src/hotspot/share/classfile/systemDictionary.cpp:202 >> #5??? ConstantPool::klass_at_impl(constantPoolHandle const&, int, >> bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 >> #6??? ConstantPool::klass_at(int, Thread*) at >> open/src/hotspot/share/oops/constantPool.hpp:382 >> #7??? InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at >> open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 >> # 8???????? >> ? .... >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 >> >> Thanks, >> Daniil >> >> ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: >> >> ???? Hi Daniil, >> ???? ???? I don't see an explanation for why fromDepth is 1 and >> afterPopDepth is 4. >> ???? ????????????? currentDepth = getThreadFrameCount(thread); >> ????????????? fromDepth = step->fromStackDepth; >> ????????????? afterPopDepth = currentDepth-1; >> ???? ???? step->fromStackDepth got setup when single stepping was >> first setup for >> ???? this thread. There was also a notifyFramePop() done at this >> time, but I >> ???? think that's just to catch exiting from the method you were single >> ???? stepping in, and has no bearing in the case we are looking at here, >> ???? where we area still some # of frames below where we user last >> issued a >> ???? STEP_INTO. The FRAME_POP we are receiving now is not the one for >> when >> ???? step->fromStackDepth was setup, but is for when we stepped into a >> ???? filtered method. I think this is what the "fromDepth > >> afterPopDepth" >> ???? check is for. I think the current logic is correct for intended >> handling >> ???? of a FRAME_POP event. Although your fix is probably solving the >> problem, >> ???? I get the feeling it is enabling single stepping too soon in >> many cases. >> ???? That many not turn up as an error in any tests, but could cause >> ???? debugging performance issues, or for the user to see spurious >> single >> ???? step events that they were not expecting. >> ???? ???? I think the bug actually occurs long before we ever get to >> this point in >> ???? the code (and we should in fact not be getting here). In my last >> entry >> ???? in the bug I mentioned JvmtiHideSingleStepping(), and how it is >> used to >> ???? turn off single stepping while we are doing invoke and field >> resolution, >> ???? but doesn't seem to be used during class resolution, which is >> what we >> ???? are doing here. If it where used, then the agent would never >> even see >> ???? the SINGLE_STEP when loadClass() is entered, therefore no >> ???? notifyFramePop() would be done, and we would not be relying on >> this code >> ???? in handleFramePopEvent(). Instead, we would receive the next >> SINGLE_STEP >> ???? event after cp resolution is complete, and we are finally >> executing the >> ???? now resolved opc_new opcode. >> ???? ???? I'm hoping Serguei and/or Alex can also comment on this, >> since I think >> ???? they were dealing with JvmtiHideSingleStepping() last month. >> ???? ???? thanks, >> ???? ???? Chris >> ???? ???? ???? ???? On 1/17/19 6:08 PM, Daniil Titov wrote: >> ???? > Please review the change that fixes JDB stepping issue for a >> specific case when the single step request was initiated earlier in >> the stack, previous calls were for methods in the filtered classes >> (single stepping was disabled), handleMethodEnterEvent() re-enabled >> stepping and the first bytecode upon entering the current method >> requires resolving constant pool entry. In this case the execution >> resumes in java.lang.Classloader.loadClass() and since it is also a >> filtered class the single stepping is getting disabled again >> (stepControl.c :593).? When loadClass() exits a notifyFramePop() is >> called on the loadClass() frame but due to condition fromDepth >= >> afterPopDepth? at stepControl.c :346 (that doesn't hold in this case, >> in this case fromDepth is 1 and afterPopDepth? is 4) the >> notifyFramePop() fails to enable single stepping back. The fix >> removes the excessive condition fromDepth >= afterPopDepth? in >> notifyFramePop() method (stepControl.c:346)? to ensure that when a >> method cal! >> ???? >?? led from the stepping frame (and during which we had >> stepping disabled) has returned the stepping is re-enabled to >> continue? instructions steps in the original stepping frame. >> ???? > >> ???? > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 >> ???? > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 >> ???? > >> ???? > Thanks! >> ???? > --Daniil >> ???? > >> ???? > >> >> > > From daniil.x.titov at oracle.com Thu Jan 24 21:38:35 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 24 Jan 2019 13:38:35 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: <7f6ac457-efd9-ac5d-a791-8e5080d50c2e@oracle.com> References: <7f6ac457-efd9-ac5d-a791-8e5080d50c2e@oracle.com> Message-ID: <7B295D25-8A62-4AF6-A906-5C9205ADE514@oracle.com> Hi Serguei, The testing is not fully completed yet. I ran locally jdk_jdi, vmTestbase_nsk_jdi, vmTestbase_nsk_jdb and have the same tests plus serviceability still running in Mach5. I am also starting tier1,tier2 and tier3 jobs. Best regards, Daniil ?On 1/24/19, 12:22 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, I wonder what tests do you run to make sure nothing is broken. Thanks, Serguei On 1/24/19 11:19, Chris Plummer wrote: > Hi Daniil, > > Thanks for the stack track. I was just about to send an email asking > for it when your new RFR arrived. > > The fix looks good. I think you also need to apply it here: > > InterpreterRuntime::ldc() > InterpreterRuntime::anewarray() > InterpreterRuntime::multianewarray() > InterpreterRuntime::quicken_io_cc() > > I wonder if it wouldn't be better if you moved the disabling into > ConstantPool::klass_at_impl() > > thanks, > > Chris > > On 1/24/19 10:38 AM, Daniil Titov wrote: >> Hi Chris and JC, >> >> Thank you for reviewing this change. Please review a new version of >> the fix that uses >> the approach Chris suggested ( disabling the single stepping during >> the class resolution). >> >> Just in case please find below the stack trace for this case when >> loadClass() method is entered. >> >> #0 SystemDictionary::load_instance_class(Symbol*, Handle, >> Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 >> #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, >> Handle, Handle, Thread*) at >> open/src/hotspot/share/classfile/systemDictionary.cpp:853 >> #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, >> Handle, Handle, Thread*) at >> open/src/hotspot/share/classfile/systemDictionary.cpp:271 >> #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, >> Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 >> #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, >> bool, Thread*) at >> open/src/hotspot/share/classfile/systemDictionary.cpp:202 >> #5 ConstantPool::klass_at_impl(constantPoolHandle const&, int, >> bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 >> #6 ConstantPool::klass_at(int, Thread*) at >> open/src/hotspot/share/oops/constantPool.hpp:382 >> #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at >> open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 >> # 8 >> .... >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 >> >> Thanks, >> Daniil >> >> ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: >> >> Hi Daniil, >> I don't see an explanation for why fromDepth is 1 and >> afterPopDepth is 4. >> currentDepth = getThreadFrameCount(thread); >> fromDepth = step->fromStackDepth; >> afterPopDepth = currentDepth-1; >> step->fromStackDepth got setup when single stepping was >> first setup for >> this thread. There was also a notifyFramePop() done at this >> time, but I >> think that's just to catch exiting from the method you were single >> stepping in, and has no bearing in the case we are looking at here, >> where we area still some # of frames below where we user last >> issued a >> STEP_INTO. The FRAME_POP we are receiving now is not the one for >> when >> step->fromStackDepth was setup, but is for when we stepped into a >> filtered method. I think this is what the "fromDepth > >> afterPopDepth" >> check is for. I think the current logic is correct for intended >> handling >> of a FRAME_POP event. Although your fix is probably solving the >> problem, >> I get the feeling it is enabling single stepping too soon in >> many cases. >> That many not turn up as an error in any tests, but could cause >> debugging performance issues, or for the user to see spurious >> single >> step events that they were not expecting. >> I think the bug actually occurs long before we ever get to >> this point in >> the code (and we should in fact not be getting here). In my last >> entry >> in the bug I mentioned JvmtiHideSingleStepping(), and how it is >> used to >> turn off single stepping while we are doing invoke and field >> resolution, >> but doesn't seem to be used during class resolution, which is >> what we >> are doing here. If it where used, then the agent would never >> even see >> the SINGLE_STEP when loadClass() is entered, therefore no >> notifyFramePop() would be done, and we would not be relying on >> this code >> in handleFramePopEvent(). Instead, we would receive the next >> SINGLE_STEP >> event after cp resolution is complete, and we are finally >> executing the >> now resolved opc_new opcode. >> I'm hoping Serguei and/or Alex can also comment on this, >> since I think >> they were dealing with JvmtiHideSingleStepping() last month. >> thanks, >> Chris >> On 1/17/19 6:08 PM, Daniil Titov wrote: >> > Please review the change that fixes JDB stepping issue for a >> specific case when the single step request was initiated earlier in >> the stack, previous calls were for methods in the filtered classes >> (single stepping was disabled), handleMethodEnterEvent() re-enabled >> stepping and the first bytecode upon entering the current method >> requires resolving constant pool entry. In this case the execution >> resumes in java.lang.Classloader.loadClass() and since it is also a >> filtered class the single stepping is getting disabled again >> (stepControl.c :593). When loadClass() exits a notifyFramePop() is >> called on the loadClass() frame but due to condition fromDepth >= >> afterPopDepth at stepControl.c :346 (that doesn't hold in this case, >> in this case fromDepth is 1 and afterPopDepth is 4) the >> notifyFramePop() fails to enable single stepping back. The fix >> removes the excessive condition fromDepth >= afterPopDepth in >> notifyFramePop() method (stepControl.c:346) to ensure that when a >> method cal! >> > led from the stepping frame (and during which we had >> stepping disabled) has returned the stepping is re-enabled to >> continue instructions steps in the original stepping frame. >> > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 >> > >> > Thanks! >> > --Daniil >> > >> > >> >> > > From serguei.spitsyn at oracle.com Thu Jan 24 21:57:32 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 24 Jan 2019 13:57:32 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: <7B295D25-8A62-4AF6-A906-5C9205ADE514@oracle.com> References: <7f6ac457-efd9-ac5d-a791-8e5080d50c2e@oracle.com> <7B295D25-8A62-4AF6-A906-5C9205ADE514@oracle.com> Message-ID: <98b98291-1498-acee-5592-2b0ecf488711@oracle.com> Hi Daniil, Must be good enough. Thanks! Serguei On 1/24/19 1:38 PM, Daniil Titov wrote: > Hi Serguei, > > The testing is not fully completed yet. I ran locally jdk_jdi, vmTestbase_nsk_jdi, vmTestbase_nsk_jdb and have the same tests plus serviceability still running in Mach5. I am also starting tier1,tier2 and tier3 jobs. > > Best regards, > Daniil > > ?On 1/24/19, 12:22 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > I wonder what tests do you run to make sure nothing is broken. > > Thanks, > Serguei > > > On 1/24/19 11:19, Chris Plummer wrote: > > Hi Daniil, > > > > Thanks for the stack track. I was just about to send an email asking > > for it when your new RFR arrived. > > > > The fix looks good. I think you also need to apply it here: > > > > InterpreterRuntime::ldc() > > InterpreterRuntime::anewarray() > > InterpreterRuntime::multianewarray() > > InterpreterRuntime::quicken_io_cc() > > > > I wonder if it wouldn't be better if you moved the disabling into > > ConstantPool::klass_at_impl() > > > > thanks, > > > > Chris > > > > On 1/24/19 10:38 AM, Daniil Titov wrote: > >> Hi Chris and JC, > >> > >> Thank you for reviewing this change. Please review a new version of > >> the fix that uses > >> the approach Chris suggested ( disabling the single stepping during > >> the class resolution). > >> > >> Just in case please find below the stack trace for this case when > >> loadClass() method is entered. > >> > >> #0 SystemDictionary::load_instance_class(Symbol*, Handle, > >> Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 > >> #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, > >> Handle, Handle, Thread*) at > >> open/src/hotspot/share/classfile/systemDictionary.cpp:853 > >> #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, > >> Handle, Handle, Thread*) at > >> open/src/hotspot/share/classfile/systemDictionary.cpp:271 > >> #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, > >> Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 > >> #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, > >> bool, Thread*) at > >> open/src/hotspot/share/classfile/systemDictionary.cpp:202 > >> #5 ConstantPool::klass_at_impl(constantPoolHandle const&, int, > >> bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 > >> #6 ConstantPool::klass_at(int, Thread*) at > >> open/src/hotspot/share/oops/constantPool.hpp:382 > >> #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at > >> open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 > >> # 8 > >> .... > >> > >> Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > >> > >> Thanks, > >> Daniil > >> > >> ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: > >> > >> Hi Daniil, > >> I don't see an explanation for why fromDepth is 1 and > >> afterPopDepth is 4. > >> currentDepth = getThreadFrameCount(thread); > >> fromDepth = step->fromStackDepth; > >> afterPopDepth = currentDepth-1; > >> step->fromStackDepth got setup when single stepping was > >> first setup for > >> this thread. There was also a notifyFramePop() done at this > >> time, but I > >> think that's just to catch exiting from the method you were single > >> stepping in, and has no bearing in the case we are looking at here, > >> where we area still some # of frames below where we user last > >> issued a > >> STEP_INTO. The FRAME_POP we are receiving now is not the one for > >> when > >> step->fromStackDepth was setup, but is for when we stepped into a > >> filtered method. I think this is what the "fromDepth > > >> afterPopDepth" > >> check is for. I think the current logic is correct for intended > >> handling > >> of a FRAME_POP event. Although your fix is probably solving the > >> problem, > >> I get the feeling it is enabling single stepping too soon in > >> many cases. > >> That many not turn up as an error in any tests, but could cause > >> debugging performance issues, or for the user to see spurious > >> single > >> step events that they were not expecting. > >> I think the bug actually occurs long before we ever get to > >> this point in > >> the code (and we should in fact not be getting here). In my last > >> entry > >> in the bug I mentioned JvmtiHideSingleStepping(), and how it is > >> used to > >> turn off single stepping while we are doing invoke and field > >> resolution, > >> but doesn't seem to be used during class resolution, which is > >> what we > >> are doing here. If it where used, then the agent would never > >> even see > >> the SINGLE_STEP when loadClass() is entered, therefore no > >> notifyFramePop() would be done, and we would not be relying on > >> this code > >> in handleFramePopEvent(). Instead, we would receive the next > >> SINGLE_STEP > >> event after cp resolution is complete, and we are finally > >> executing the > >> now resolved opc_new opcode. > >> I'm hoping Serguei and/or Alex can also comment on this, > >> since I think > >> they were dealing with JvmtiHideSingleStepping() last month. > >> thanks, > >> Chris > >> On 1/17/19 6:08 PM, Daniil Titov wrote: > >> > Please review the change that fixes JDB stepping issue for a > >> specific case when the single step request was initiated earlier in > >> the stack, previous calls were for methods in the filtered classes > >> (single stepping was disabled), handleMethodEnterEvent() re-enabled > >> stepping and the first bytecode upon entering the current method > >> requires resolving constant pool entry. In this case the execution > >> resumes in java.lang.Classloader.loadClass() and since it is also a > >> filtered class the single stepping is getting disabled again > >> (stepControl.c :593). When loadClass() exits a notifyFramePop() is > >> called on the loadClass() frame but due to condition fromDepth >= > >> afterPopDepth at stepControl.c :346 (that doesn't hold in this case, > >> in this case fromDepth is 1 and afterPopDepth is 4) the > >> notifyFramePop() fails to enable single stepping back. The fix > >> removes the excessive condition fromDepth >= afterPopDepth in > >> notifyFramePop() method (stepControl.c:346) to ensure that when a > >> method cal! > >> > led from the stepping frame (and during which we had > >> stepping disabled) has returned the stepping is re-enabled to > >> continue instructions steps in the original stepping frame. > >> > > >> > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > >> > > >> > Thanks! > >> > --Daniil > >> > > >> > > >> > >> > > > > > > > > From yasuenag at gmail.com Fri Jan 25 00:41:02 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 25 Jan 2019 09:41:02 +0900 Subject: RFR: 8217612: (CL)HSDB cannot show some JVM flags Message-ID: Hi all, Please review this change. JBS: https://bugs.openjdk.java.net/browse/JDK-8217612 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217612/webrev.00/ "Show -XX flags" on HSDB and `flags` command on CLHSDB show -XX flags. However some flags cannot do so. sun.jvm.hotspot.runtime.VM.Flag handles -XX flags in debuggee, but it do not handle following types: - ccstr - ccstrlist - double - uint64_t This webrev has passed all tests on submit repo. Thanks, Yasumasa From zanglin5 at jd.com Fri Jan 25 01:00:19 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Fri, 25 Jan 2019 01:00:19 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <3f34421b11514358af3ed110b830a7f3@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> Message-ID: <0cf0d209864e46a3bdcbe6a9080ec1dc@jd.com> 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 zanglin5 at jd.com Fri Jan 25 01:01:25 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Fri, 25 Jan 2019 01:01:25 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: References: <66546343ae324ab28bb54951ad774a89@jd.com>, <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> , Message-ID: <74eaa1f868b74257beffff465f60edb2@jd.com> Dear All, May I get more review about this webrev? Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks! Lin ________________________________________ From: ???? Sent: Wednesday, January 9, 2019 9:46:55 AM To: Hohensee, Paul; serviceability-dev at openjdk.java.net Subject: RE: [RFR]8215623: Add incremental dump for jmap histo Hi Paul and All, Thanks a lot for your review and comments, I have updated the webrev to Webrev: http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Would you like to help review it. Thanks. BRs Lin From: ???? Sent: Monday, January 7, 2019 7:14 PM To: Hohensee, Paul ; serviceability-dev at openjdk.java.net; ???? Subject: RE: [RFR]8215623: Add incremental dump for jmap histo And another way is to add a argument ??IncrementalFile=??,which specifies the location for saving the intermediate data file. And if it is not specified, incremental data will dump to ??out??. What do you think? Thanks, Lin From: ???? Sent: Monday, January 7, 2019 7:02 PM To: Hohensee, Paul >; serviceability-dev at openjdk.java.net Subject: ????: [RFR]8215623: Add incremental dump for jmap histo Dear Paul, Thanks for your review, I agree your suggestion to make incremental general. and I think the incremental file is better to be different with the file or the "out", because in future the parallel histo will have each thread individually dump their data, and I want it to be lock-free, so each thread need to dump to their own file. The final data will be sum up and dump to the file that "filename=" specified. Moreover, the incremental file contains intermediate data, if it is dumped to "", it more or less "pollute" the final file (final file that contains lots intermediate data). so the logic is that incremental data will be dumped to a file named "Histo_Dump_Temp.dump", if the "filename" is assigned, the "Histo_Dump_Temp.dump" will be generated under the same folder, if "filename" not specified, it will dump to current dir. And if "chunkcount" is 0 or max_int, or "maxfilesize" is 0, the incremental dump will be disabled. ________________________________ ??????: Hohensee, Paul > ????????: 2019??1??1?? 4:56 ??????: ????; serviceability-dev at openjdk.java.net ????: Re: [RFR]8215623: Add incremental dump for jmap histo As for 8215622, update the copyright dates to 2019 please, since this won??t get pushed until then. You might generalize the implementation so that all inspections are done incrementally, and parameterize RecordInstanceClosure with the incremental threshold. ??incremental?? could become ??chunkcount=??, where defaults to infinity (max value of size_t). I??d not use a default file name when ??chunkcount?? is specified, I??d just write to whatever the output stream is. ??chunkcount?? is then independent of ??file??. I??d add another histo argument for the maximum file size, call it ??maxfilesize??, and parameterize RecordInstanceClosure with it. Default would be infinity (max value of size_t). If you want to make it easy to use your 8k and 5mb chunkcount and maxfilesize combination, you could redefine your original ??incremental?? argument as syntactic sugar for ??chunkcount=8k,maxfilesize=5m??. INCREMENTAL_THRESHOLD and MAX_INCREMENTAL_FILESIZE become DEFAULT_CHUNKSIZE and MAX_FILE_SIZE, are both set to max size_t, and should be defined as ??const int?? within RecordInstanceClosure. Thanks, Paul From: serviceability-dev > on behalf of ???? > Date: Thursday, December 20, 2018 at 11:13 PM To: "serviceability-dev at openjdk.java.net" > Subject: [RFR]8215623: Add incremental dump for jmap histo Hi All, May I ask your help to review this patch for enhance jmap ?Chisto. It adds the ??incremental?? arguments that allow jmap ?Chisto to incrementally save the intermediate data into a temp file. The intermediate data is dumped incrementally and write to a rolling file, which limit the size of the temp file to be small. This is useful for user to get intermediate results when jmap/jvm process is killed accidentally. Especially when the heap is large. 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/8215623/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215623 Thanks. BRs, Lin From david.holmes at oracle.com Fri Jan 25 02:46:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2019 12:46:07 +1000 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning Message-ID: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ Lots of analysis in the bug report. Bottom line: SuspendThread of the current thread was not actually suspending the thread until it hit specific thread-state transitions. That meant that SuspendThread would actually return and continue executing native code whilst suspended, in violation of the specification for it. The fix is quite simple: in java_suspend() we check for the current thread and call java_suspend_self(). Testing: - Any test that looked like it referred to thread suspension - hotspot/jtreg/vmTestbase/nsk/jvmti/* - jdk/ com/sun/jdi/* java/lang/ThreadGroup/Suspend.java java/lang/management/CompositeData/ThreadInfoCompositeData.java java/lang/management/ThreadMXBean/* java/nio/channels/SocketChannel/SendUrgentData.java java/util/logging/LogManager/Configuration/TestConfigurationLock.java - Mach 5 tiers 1-3 (in progress) Two tests were found to be erroneously relying on SuspendThread returning whilst suspended: - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp The test updated a shared counter after the SuspendThread call, but it needed to be updated before the call. - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp The test was using a 0 return value from SuspendThread as an indicator that the thread was in the suspended state - but that value can't be seen until after SuspendThread returns, which is after the thread is resumed. So I ripped out the custom state tracking logic and replaced with a simple check of GetThreadState. Thanks, David From david.holmes at oracle.com Fri Jan 25 06:30:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2019 16:30:30 +1000 Subject: RFR: 8217612: (CL)HSDB cannot show some JVM flags In-Reply-To: References: Message-ID: Hi Yasumasa, This all looks quite reasonable to me. Thanks, David On 25/01/2019 10:41 am, Yasumasa Suenaga wrote: > Hi all, > > Please review this change. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8217612 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217612/webrev.00/ > > > "Show -XX flags" on HSDB and `flags` command on CLHSDB show -XX flags. > However some flags cannot do so. > > sun.jvm.hotspot.runtime.VM.Flag handles -XX flags in debuggee, but it do not > handle following types: > > - ccstr > - ccstrlist > - double > - uint64_t > > > This webrev has passed all tests on submit repo. > > > Thanks, > > Yasumasa > From yasuenag at gmail.com Fri Jan 25 06:59:53 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 25 Jan 2019 15:59:53 +0900 Subject: RFR: 8217612: (CL)HSDB cannot show some JVM flags In-Reply-To: References: Message-ID: Thanks David! I'm waiting for second reviewer. Yasumasa 2019?1?25?(?) 15:31 David Holmes : > > Hi Yasumasa, > > This all looks quite reasonable to me. > > Thanks, > David > > On 25/01/2019 10:41 am, Yasumasa Suenaga wrote: > > Hi all, > > > > Please review this change. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8217612 > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217612/webrev.00/ > > > > > > "Show -XX flags" on HSDB and `flags` command on CLHSDB show -XX flags. > > However some flags cannot do so. > > > > sun.jvm.hotspot.runtime.VM.Flag handles -XX flags in debuggee, but it do not > > handle following types: > > > > - ccstr > > - ccstrlist > > - double > > - uint64_t > > > > > > This webrev has passed all tests on submit repo. > > > > > > Thanks, > > > > Yasumasa > > From serguei.spitsyn at oracle.com Fri Jan 25 18:32:55 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 25 Jan 2019 10:32:55 -0800 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> Message-ID: <1311983c-ebdb-b227-77dd-75532038ab94@oracle.com> Hi David, The fix looks good to me. Thank you for taking care about it! Thanks, Serguei On 1/24/19 6:46 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 > webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ > > Lots of analysis in the bug report. Bottom line: SuspendThread of the > current thread was not actually suspending the thread until it hit > specific thread-state transitions. That meant that SuspendThread would > actually return and continue executing native code whilst suspended, > in violation of the specification for it. > > The fix is quite simple: in java_suspend() we check for the current > thread and call java_suspend_self(). > > Testing: > ?- Any test that looked like it referred to thread suspension > ? - hotspot/jtreg/vmTestbase/nsk/jvmti/* > ? - jdk/ > ???? com/sun/jdi/* > ???? java/lang/ThreadGroup/Suspend.java > java/lang/management/CompositeData/ThreadInfoCompositeData.java > ???? java/lang/management/ThreadMXBean/* > ???? java/nio/channels/SocketChannel/SendUrgentData.java > java/util/logging/LogManager/Configuration/TestConfigurationLock.java > > ?- Mach 5 tiers 1-3 (in progress) > > Two tests were found to be erroneously relying on SuspendThread > returning whilst suspended: > > - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp > > The test updated a shared counter after the SuspendThread call, but it > needed to be updated before the call. > > - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp > > The test was using a 0 return value from SuspendThread as an indicator > that the thread was in the suspended state - but that value can't be > seen until after SuspendThread returns, which is after the thread is > resumed. So I ripped out the custom state tracking logic and replaced > with a simple check of GetThreadState. > > Thanks, > David From chris.plummer at oracle.com Fri Jan 25 18:53:47 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 25 Jan 2019 10:53:47 -0800 Subject: RFR: 8217612: (CL)HSDB cannot show some JVM flags In-Reply-To: References: Message-ID: <04db1d9a-dab4-9948-fc38-1c2e3106dee5@oracle.com> +1 Chris On 1/24/19 10:59 PM, Yasumasa Suenaga wrote: > Thanks David! > > I'm waiting for second reviewer. > > > Yasumasa > > 2019?1?25?(?) 15:31 David Holmes : >> Hi Yasumasa, >> >> This all looks quite reasonable to me. >> >> Thanks, >> David >> >> On 25/01/2019 10:41 am, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8217612 >>> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217612/webrev.00/ >>> >>> >>> "Show -XX flags" on HSDB and `flags` command on CLHSDB show -XX flags. >>> However some flags cannot do so. >>> >>> sun.jvm.hotspot.runtime.VM.Flag handles -XX flags in debuggee, but it do not >>> handle following types: >>> >>> - ccstr >>> - ccstrlist >>> - double >>> - uint64_t >>> >>> >>> This webrev has passed all tests on submit repo. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> From daniel.daugherty at oracle.com Fri Jan 25 19:23:04 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 14:23:04 -0500 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> Message-ID: <09a960d7-9180-8c9f-3fde-f242f8e74d81@oracle.com> On 1/24/19 9:46 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 > webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ src/hotspot/share/runtime/thread.cpp ??? L2364: // Self-suspension will happen on the transition out of the vm. ??????? This comment is no longer accurate and should be deleted. ??? L2365: // Catch "this" coming in from JNIEnv pointers when the thread has been freed ??????? This comment should have been deleted by the Thread-SMR project. ??????? Do you mind deleting it now? test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp ??? No comments. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp ??? No comments. Thumbs up! No new webrev needed even if you decide to delete the comments I flagged above. Dan > > Lots of analysis in the bug report. Bottom line: SuspendThread of the > current thread was not actually suspending the thread until it hit > specific thread-state transitions. That meant that SuspendThread would > actually return and continue executing native code whilst suspended, > in violation of the specification for it. > > The fix is quite simple: in java_suspend() we check for the current > thread and call java_suspend_self(). > > Testing: > ?- Any test that looked like it referred to thread suspension > ? - hotspot/jtreg/vmTestbase/nsk/jvmti/* > ? - jdk/ > ???? com/sun/jdi/* > ???? java/lang/ThreadGroup/Suspend.java > java/lang/management/CompositeData/ThreadInfoCompositeData.java > ???? java/lang/management/ThreadMXBean/* > ???? java/nio/channels/SocketChannel/SendUrgentData.java > java/util/logging/LogManager/Configuration/TestConfigurationLock.java > > ?- Mach 5 tiers 1-3 (in progress) > > Two tests were found to be erroneously relying on SuspendThread > returning whilst suspended: > > - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp > > The test updated a shared counter after the SuspendThread call, but it > needed to be updated before the call. > > - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp > > The test was using a 0 return value from SuspendThread as an indicator > that the thread was in the suspended state - but that value can't be > seen until after SuspendThread returns, which is after the thread is > resumed. So I ripped out the custom state tracking logic and replaced > with a simple check of GetThreadState. > > Thanks, > David From yasuenag at gmail.com Sat Jan 26 01:32:31 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 26 Jan 2019 10:32:31 +0900 Subject: RFR: 8217612: (CL)HSDB cannot show some JVM flags In-Reply-To: <04db1d9a-dab4-9948-fc38-1c2e3106dee5@oracle.com> References: <04db1d9a-dab4-9948-fc38-1c2e3106dee5@oracle.com> Message-ID: Thanks Chris! Yasumasa On 2019/01/26 3:53, Chris Plummer wrote: > +1 > > Chris > > On 1/24/19 10:59 PM, Yasumasa Suenaga wrote: >> Thanks David! >> >> I'm waiting for second reviewer. >> >> >> Yasumasa >> >> 2019?1?25?(?) 15:31 David Holmes : >>> Hi Yasumasa, >>> >>> This all looks quite reasonable to me. >>> >>> Thanks, >>> David >>> >>> On 25/01/2019 10:41 am, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change. >>>> >>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217612 >>>> ??? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217612/webrev.00/ >>>> >>>> >>>> "Show -XX flags" on HSDB and `flags` command on CLHSDB show -XX flags. >>>> However some flags cannot do so. >>>> >>>> sun.jvm.hotspot.runtime.VM.Flag handles -XX flags in debuggee, but it do not >>>> handle following types: >>>> >>>> ??? - ccstr >>>> ??? - ccstrlist >>>> ??? - double >>>> ??? - uint64_t >>>> >>>> >>>> This webrev has passed all tests on submit repo. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> > > From yasuenag at gmail.com Sat Jan 26 04:43:11 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 26 Jan 2019 13:43:11 +0900 Subject: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot Message-ID: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> 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 Sat Jan 26 04:44:40 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 26 Jan 2019 13:44:40 +0900 Subject: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: <1fd781de-5df6-b616-f489-a252678053aa@gmail.com> 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/ This change passed tests on submit repo. (mach5-one-ysuenaga-JDK-8217845-20190126-0215-85869) Yasumasa > 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 david.holmes at oracle.com Sat Jan 26 05:22:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2019 15:22:51 +1000 Subject: RFR: 8217612: (CL)HSDB cannot show some JVM flags In-Reply-To: References: <04db1d9a-dab4-9948-fc38-1c2e3106dee5@oracle.com> Message-ID: <53922123-d26b-fe46-fc5e-bd5ba10a84f3@oracle.com> Hi Yasumasa, We're seeing the following test fail on all platforms after this change: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java No real information just: java.lang.Exception: jmap -heap exited with error code: 1 at CompressedClassSpaceSizeInJmapHeap.run(CompressedClassSpaceSizeInJmapHeap.java:80) at CompressedClassSpaceSizeInJmapHeap.main(CompressedClassSpaceSizeInJmapHeap.java:68) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:835) Can you try it? Thanks, David On 26/01/2019 11:32 am, Yasumasa Suenaga wrote: > Thanks Chris! > > > Yasumasa > > > On 2019/01/26 3:53, Chris Plummer wrote: >> +1 >> >> Chris >> >> On 1/24/19 10:59 PM, Yasumasa Suenaga wrote: >>> Thanks David! >>> >>> I'm waiting for second reviewer. >>> >>> >>> Yasumasa >>> >>> 2019?1?25?(?) 15:31 David Holmes : >>>> Hi Yasumasa, >>>> >>>> This all looks quite reasonable to me. >>>> >>>> Thanks, >>>> David >>>> >>>> On 25/01/2019 10:41 am, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change. >>>>> >>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217612 >>>>> ??? webrev: >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8217612/webrev.00/ >>>>> >>>>> >>>>> "Show -XX flags" on HSDB and `flags` command on CLHSDB show -XX flags. >>>>> However some flags cannot do so. >>>>> >>>>> sun.jvm.hotspot.runtime.VM.Flag handles -XX flags in debuggee, but >>>>> it do not >>>>> handle following types: >>>>> >>>>> ??? - ccstr >>>>> ??? - ccstrlist >>>>> ??? - double >>>>> ??? - uint64_t >>>>> >>>>> >>>>> This webrev has passed all tests on submit repo. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >> >> From yasuenag at gmail.com Sat Jan 26 05:38:32 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 26 Jan 2019 14:38:32 +0900 Subject: RFR: 8217612: (CL)HSDB cannot show some JVM flags In-Reply-To: <53922123-d26b-fe46-fc5e-bd5ba10a84f3@oracle.com> References: <04db1d9a-dab4-9948-fc38-1c2e3106dee5@oracle.com> <53922123-d26b-fe46-fc5e-bd5ba10a84f3@oracle.com> Message-ID: Hi David, On 2019/01/26 14:22, David Holmes wrote: > Hi Yasumasa, > > We're seeing the following test fail on all platforms after this change: > > gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > > No real information just: > > java.lang.Exception: jmap -heap exited with error code: 1 > ????at CompressedClassSpaceSizeInJmapHeap.run(CompressedClassSpaceSizeInJmapHeap.java:80) > ????at CompressedClassSpaceSizeInJmapHeap.main(CompressedClassSpaceSizeInJmapHeap.java:68) > ????at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ????at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ????at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ????at java.base/java.lang.reflect.Method.invoke(Method.java:567) > ????at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > ????at java.base/java.lang.Thread.run(Thread.java:835) > > Can you try it? Sure, but I will be able to try it tonight (in GMT +9:00) Can you share CompressedClassSpaceSizeInJmapHeap.stdout.txt and CompressedClassSpaceSizeInJmapHeap.stderr.txt ? CompressedClassSpaceSizeInJmapHeap.java seems to redirect stdout/err to them. FYI: This change is passed tests on submit repo: mach5-one-ysuenaga-JDK-8217612-20190124-0420-31228 But CompressedClassSpaceSizeInJmapHeap.java is excluded from tier1_gc_2. Thanks, Yasumasa > Thanks, > David > > On 26/01/2019 11:32 am, Yasumasa Suenaga wrote: >> Thanks Chris! >> >> >> Yasumasa >> >> >> On 2019/01/26 3:53, Chris Plummer wrote: >>> +1 >>> >>> Chris >>> >>> On 1/24/19 10:59 PM, Yasumasa Suenaga wrote: >>>> Thanks David! >>>> >>>> I'm waiting for second reviewer. >>>> >>>> >>>> Yasumasa >>>> >>>> 2019?1?25?(?) 15:31 David Holmes : >>>>> Hi Yasumasa, >>>>> >>>>> This all looks quite reasonable to me. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 25/01/2019 10:41 am, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change. >>>>>> >>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217612 >>>>>> ??? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217612/webrev.00/ >>>>>> >>>>>> >>>>>> "Show -XX flags" on HSDB and `flags` command on CLHSDB show -XX flags. >>>>>> However some flags cannot do so. >>>>>> >>>>>> sun.jvm.hotspot.runtime.VM.Flag handles -XX flags in debuggee, but it do not >>>>>> handle following types: >>>>>> >>>>>> ??? - ccstr >>>>>> ??? - ccstrlist >>>>>> ??? - double >>>>>> ??? - uint64_t >>>>>> >>>>>> >>>>>> This webrev has passed all tests on submit repo. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>> >>> From yasuenag at gmail.com Sat Jan 26 10:49:50 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 26 Jan 2019 19:49:50 +0900 Subject: RFR: 8217612: (CL)HSDB cannot show some JVM flags In-Reply-To: References: <04db1d9a-dab4-9948-fc38-1c2e3106dee5@oracle.com> <53922123-d26b-fe46-fc5e-bd5ba10a84f3@oracle.com> Message-ID: <671b3519-04c1-bb59-8f33-c27ddc5a57bf@gmail.com> Hi David, I could reproduce this issue. I filed it as JDK-8217850 to JBS: https://bugs.openjdk.java.net/browse/JDK-8217850 JDK-8217612 distinguishes signed / unsigned values. However CompressedClassSpaceSizeInJmapHeap does not do so. I've pushed the fix to submit repo. It works fine on my Linux x64 box. http://hg.openjdk.java.net/jdk/submit/rev/d6a9afe96531 I will send review request when I received the result from submit repo. Thanks, Yasumasa On 2019/01/26 14:38, Yasumasa Suenaga wrote: > Hi David, > > On 2019/01/26 14:22, David Holmes wrote: >> Hi Yasumasa, >> >> We're seeing the following test fail on all platforms after this change: >> >> gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >> >> No real information just: >> >> java.lang.Exception: jmap -heap exited with error code: 1 >> ?????at CompressedClassSpaceSizeInJmapHeap.run(CompressedClassSpaceSizeInJmapHeap.java:80) >> ?????at CompressedClassSpaceSizeInJmapHeap.main(CompressedClassSpaceSizeInJmapHeap.java:68) >> ?????at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> ?????at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> ?????at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> ?????at java.base/java.lang.reflect.Method.invoke(Method.java:567) >> ?????at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> ?????at java.base/java.lang.Thread.run(Thread.java:835) >> >> Can you try it? > > Sure, but I will be able to try it tonight (in GMT +9:00) > > Can you share CompressedClassSpaceSizeInJmapHeap.stdout.txt and CompressedClassSpaceSizeInJmapHeap.stderr.txt ? > > CompressedClassSpaceSizeInJmapHeap.java seems to redirect stdout/err to them. > > > FYI: > ? This change is passed tests on submit repo: mach5-one-ysuenaga-JDK-8217612-20190124-0420-31228 > ? But CompressedClassSpaceSizeInJmapHeap.java is excluded from tier1_gc_2. > > > Thanks, > > Yasumasa > > > >> Thanks, >> David >> >> On 26/01/2019 11:32 am, Yasumasa Suenaga wrote: >>> Thanks Chris! >>> >>> >>> Yasumasa >>> >>> >>> On 2019/01/26 3:53, Chris Plummer wrote: >>>> +1 >>>> >>>> Chris >>>> >>>> On 1/24/19 10:59 PM, Yasumasa Suenaga wrote: >>>>> Thanks David! >>>>> >>>>> I'm waiting for second reviewer. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> 2019?1?25?(?) 15:31 David Holmes : >>>>>> Hi Yasumasa, >>>>>> >>>>>> This all looks quite reasonable to me. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 25/01/2019 10:41 am, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change. >>>>>>> >>>>>>> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217612 >>>>>>> ??? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8217612/webrev.00/ >>>>>>> >>>>>>> >>>>>>> "Show -XX flags" on HSDB and `flags` command on CLHSDB show -XX flags. >>>>>>> However some flags cannot do so. >>>>>>> >>>>>>> sun.jvm.hotspot.runtime.VM.Flag handles -XX flags in debuggee, but it do not >>>>>>> handle following types: >>>>>>> >>>>>>> ??? - ccstr >>>>>>> ??? - ccstrlist >>>>>>> ??? - double >>>>>>> ??? - uint64_t >>>>>>> >>>>>>> >>>>>>> This webrev has passed all tests on submit repo. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>> >>>> From yasuenag at gmail.com Sat Jan 26 12:44:54 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 26 Jan 2019 21:44:54 +0900 Subject: RFR: 8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612 Message-ID: <5da25f73-c0e2-dcfe-6b87-a51148f88db8@gmail.com> Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8217850 webrev: https://bugs.openjdk.java.net/browse/JDK-8217850 This change passed tests on submit repo, and test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on my Linux x64 box. Thanks, Yasumasa From yasuenag at gmail.com Sat Jan 26 12:47:38 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 26 Jan 2019 21:47:38 +0900 Subject: RFR: 8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612 In-Reply-To: <5da25f73-c0e2-dcfe-6b87-a51148f88db8@gmail.com> References: <5da25f73-c0e2-dcfe-6b87-a51148f88db8@gmail.com> Message-ID: <641c4c68-a8d1-6007-8d00-9adcc202f5fc@gmail.com> Sorry, webrev is here: http://cr.openjdk.java.net/~ysuenaga/JDK-8217850/webrev.00/ Yasumasa On 2019/01/26 21:44, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8217850 > ? webrev: https://bugs.openjdk.java.net/browse/JDK-8217850 > > This change passed tests on submit repo, and test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on my Linux x64 box. > > > Thanks, > > Yasumasa From daniil.x.titov at oracle.com Sat Jan 26 19:23:36 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Sat, 26 Jan 2019 11:23:36 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: References: Message-ID: <72D6EC06-48FD-4C0D-8C7B-DB51F8D8E359@oracle.com> Hi Chris, Please review a new version of the patch that moves the disabling of the single stepping into ConstantPool::klass_at_impl(). Mach5 jdk_jdi, vmTestbase_nsk_jdi, vmTestbase_nsk_jdb and serviceability tests, as well as all tier1,tier2 and tier3 tests successfully passed. Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 Thanks! --Daniil ?On 1/24/19, 11:19 AM, "Chris Plummer" wrote: Hi Daniil, Thanks for the stack track. I was just about to send an email asking for it when your new RFR arrived. The fix looks good. I think you also need to apply it here: InterpreterRuntime::ldc() InterpreterRuntime::anewarray() InterpreterRuntime::multianewarray() InterpreterRuntime::quicken_io_cc() I wonder if it wouldn't be better if you moved the disabling into ConstantPool::klass_at_impl() thanks, Chris On 1/24/19 10:38 AM, Daniil Titov wrote: > Hi Chris and JC, > > Thank you for reviewing this change. Please review a new version of the fix that uses > the approach Chris suggested ( disabling the single stepping during the class resolution). > > Just in case please find below the stack trace for this case when loadClass() method is entered. > > #0 SystemDictionary::load_instance_class(Symbol*, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 > #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:853 > #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:271 > #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 > #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:202 > #5 ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 > #6 ConstantPool::klass_at(int, Thread*) at open/src/hotspot/share/oops/constantPool.hpp:382 > #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 > # 8 > .... > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks, > Daniil > > ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: > > Hi Daniil, > > I don't see an explanation for why fromDepth is 1 and afterPopDepth is 4. > > currentDepth = getThreadFrameCount(thread); > fromDepth = step->fromStackDepth; > afterPopDepth = currentDepth-1; > > step->fromStackDepth got setup when single stepping was first setup for > this thread. There was also a notifyFramePop() done at this time, but I > think that's just to catch exiting from the method you were single > stepping in, and has no bearing in the case we are looking at here, > where we area still some # of frames below where we user last issued a > STEP_INTO. The FRAME_POP we are receiving now is not the one for when > step->fromStackDepth was setup, but is for when we stepped into a > filtered method. I think this is what the "fromDepth > afterPopDepth" > check is for. I think the current logic is correct for intended handling > of a FRAME_POP event. Although your fix is probably solving the problem, > I get the feeling it is enabling single stepping too soon in many cases. > That many not turn up as an error in any tests, but could cause > debugging performance issues, or for the user to see spurious single > step events that they were not expecting. > > I think the bug actually occurs long before we ever get to this point in > the code (and we should in fact not be getting here). In my last entry > in the bug I mentioned JvmtiHideSingleStepping(), and how it is used to > turn off single stepping while we are doing invoke and field resolution, > but doesn't seem to be used during class resolution, which is what we > are doing here. If it where used, then the agent would never even see > the SINGLE_STEP when loadClass() is entered, therefore no > notifyFramePop() would be done, and we would not be relying on this code > in handleFramePopEvent(). Instead, we would receive the next SINGLE_STEP > event after cp resolution is complete, and we are finally executing the > now resolved opc_new opcode. > > I'm hoping Serguei and/or Alex can also comment on this, since I think > they were dealing with JvmtiHideSingleStepping() last month. > > thanks, > > Chris > > > > On 1/17/19 6:08 PM, Daniil Titov wrote: > > Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! > > led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > Thanks! > > --Daniil > > > > > > > > > From chris.plummer at oracle.com Sat Jan 26 19:35:52 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 26 Jan 2019 11:35:52 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: <72D6EC06-48FD-4C0D-8C7B-DB51F8D8E359@oracle.com> References: <72D6EC06-48FD-4C0D-8C7B-DB51F8D8E359@oracle.com> Message-ID: <36e052be-5c46-2d51-efbd-b8fb76df4ffc@oracle.com> Looks good. thanks, Chris On 1/26/19 11:23 AM, Daniil Titov wrote: > Hi Chris, > > Please review a new version of the patch that moves the disabling of the single stepping into ConstantPool::klass_at_impl(). > > Mach5 jdk_jdi, vmTestbase_nsk_jdi, vmTestbase_nsk_jdb and serviceability tests, as well as all tier1,tier2 and tier3 tests successfully passed. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks! > --Daniil > > ?On 1/24/19, 11:19 AM, "Chris Plummer" wrote: > > Hi Daniil, > > Thanks for the stack track. I was just about to send an email asking for > it when your new RFR arrived. > > The fix looks good. I think you also need to apply it here: > > InterpreterRuntime::ldc() > InterpreterRuntime::anewarray() > InterpreterRuntime::multianewarray() > InterpreterRuntime::quicken_io_cc() > > I wonder if it wouldn't be better if you moved the disabling into > ConstantPool::klass_at_impl() > > thanks, > > Chris > > On 1/24/19 10:38 AM, Daniil Titov wrote: > > Hi Chris and JC, > > > > Thank you for reviewing this change. Please review a new version of the fix that uses > > the approach Chris suggested ( disabling the single stepping during the class resolution). > > > > Just in case please find below the stack trace for this case when loadClass() method is entered. > > > > #0 SystemDictionary::load_instance_class(Symbol*, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 > > #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:853 > > #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:271 > > #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 > > #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:202 > > #5 ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 > > #6 ConstantPool::klass_at(int, Thread*) at open/src/hotspot/share/oops/constantPool.hpp:382 > > #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 > > # 8 > > .... > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > Thanks, > > Daniil > > > > ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: > > > > Hi Daniil, > > > > I don't see an explanation for why fromDepth is 1 and afterPopDepth is 4. > > > > currentDepth = getThreadFrameCount(thread); > > fromDepth = step->fromStackDepth; > > afterPopDepth = currentDepth-1; > > > > step->fromStackDepth got setup when single stepping was first setup for > > this thread. There was also a notifyFramePop() done at this time, but I > > think that's just to catch exiting from the method you were single > > stepping in, and has no bearing in the case we are looking at here, > > where we area still some # of frames below where we user last issued a > > STEP_INTO. The FRAME_POP we are receiving now is not the one for when > > step->fromStackDepth was setup, but is for when we stepped into a > > filtered method. I think this is what the "fromDepth > afterPopDepth" > > check is for. I think the current logic is correct for intended handling > > of a FRAME_POP event. Although your fix is probably solving the problem, > > I get the feeling it is enabling single stepping too soon in many cases. > > That many not turn up as an error in any tests, but could cause > > debugging performance issues, or for the user to see spurious single > > step events that they were not expecting. > > > > I think the bug actually occurs long before we ever get to this point in > > the code (and we should in fact not be getting here). In my last entry > > in the bug I mentioned JvmtiHideSingleStepping(), and how it is used to > > turn off single stepping while we are doing invoke and field resolution, > > but doesn't seem to be used during class resolution, which is what we > > are doing here. If it where used, then the agent would never even see > > the SINGLE_STEP when loadClass() is entered, therefore no > > notifyFramePop() would be done, and we would not be relying on this code > > in handleFramePopEvent(). Instead, we would receive the next SINGLE_STEP > > event after cp resolution is complete, and we are finally executing the > > now resolved opc_new opcode. > > > > I'm hoping Serguei and/or Alex can also comment on this, since I think > > they were dealing with JvmtiHideSingleStepping() last month. > > > > thanks, > > > > Chris > > > > > > > > On 1/17/19 6:08 PM, Daniil Titov wrote: > > > Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! > > > led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > > > > > > > From chris.plummer at oracle.com Sat Jan 26 19:39:42 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 26 Jan 2019 11:39:42 -0800 Subject: RFR: 8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612 In-Reply-To: <641c4c68-a8d1-6007-8d00-9adcc202f5fc@gmail.com> References: <5da25f73-c0e2-dcfe-6b87-a51148f88db8@gmail.com> <641c4c68-a8d1-6007-8d00-9adcc202f5fc@gmail.com> Message-ID: <699bf3a0-e62b-3f62-c19c-4c88827738a9@oracle.com> Looks good. thanks, Chris On 1/26/19 4:47 AM, Yasumasa Suenaga wrote: > Sorry, webrev is here: > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8217850/webrev.00/ > > > Yasumasa > > > On 2019/01/26 21:44, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217850 >> ?? webrev: https://bugs.openjdk.java.net/browse/JDK-8217850 >> >> This change passed tests on submit repo, and >> test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >> on my Linux x64 box. >> >> >> Thanks, >> >> Yasumasa From dean.long at oracle.com Sat Jan 26 20:33:21 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sat, 26 Jan 2019 12:33:21 -0800 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> Message-ID: <738a9af2-988a-457e-6fb2-9ff5b04b14bb@oracle.com> I think there is going to be a race with resume wherever you put the self-suspend, because we do it without holding SR_lock.? So you should be able to move the self check and self suspend to before the SR_lock.? This would just be a performance optimization. dl On 1/24/19 6:46 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 > webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ > > Lots of analysis in the bug report. Bottom line: SuspendThread of the > current thread was not actually suspending the thread until it hit > specific thread-state transitions. That meant that SuspendThread would > actually return and continue executing native code whilst suspended, > in violation of the specification for it. > > The fix is quite simple: in java_suspend() we check for the current > thread and call java_suspend_self(). > > Testing: > ?- Any test that looked like it referred to thread suspension > ? - hotspot/jtreg/vmTestbase/nsk/jvmti/* > ? - jdk/ > ???? com/sun/jdi/* > ???? java/lang/ThreadGroup/Suspend.java > java/lang/management/CompositeData/ThreadInfoCompositeData.java > ???? java/lang/management/ThreadMXBean/* > ???? java/nio/channels/SocketChannel/SendUrgentData.java > java/util/logging/LogManager/Configuration/TestConfigurationLock.java > > ?- Mach 5 tiers 1-3 (in progress) > > Two tests were found to be erroneously relying on SuspendThread > returning whilst suspended: > > - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp > > The test updated a shared counter after the SuspendThread call, but it > needed to be updated before the call. > > - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp > > The test was using a 0 return value from SuspendThread as an indicator > that the thread was in the suspended state - but that value can't be > seen until after SuspendThread returns, which is after the thread is > resumed. So I ripped out the custom state tracking logic and replaced > with a simple check of GetThreadState. > > Thanks, > David From david.holmes at oracle.com Sat Jan 26 23:23:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 27 Jan 2019 09:23:49 +1000 Subject: RFR: 8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612 In-Reply-To: <641c4c68-a8d1-6007-8d00-9adcc202f5fc@gmail.com> References: <5da25f73-c0e2-dcfe-6b87-a51148f88db8@gmail.com> <641c4c68-a8d1-6007-8d00-9adcc202f5fc@gmail.com> Message-ID: <134a19c3-3a09-9403-7152-3bab7bb0bae6@oracle.com> Hi Yasumasa, That seems quite reasonable. Thanks for the quick fix. David ----- On 26/01/2019 10:47 pm, Yasumasa Suenaga wrote: > Sorry, webrev is here: > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8217850/webrev.00/ > > > Yasumasa > > > On 2019/01/26 21:44, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217850 >> ?? webrev: https://bugs.openjdk.java.net/browse/JDK-8217850 >> >> This change passed tests on submit repo, and >> test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on >> my Linux x64 box. >> >> >> Thanks, >> >> Yasumasa From david.holmes at oracle.com Sat Jan 26 23:59:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 27 Jan 2019 09:59:11 +1000 Subject: RFR: 8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612 In-Reply-To: <134a19c3-3a09-9403-7152-3bab7bb0bae6@oracle.com> References: <5da25f73-c0e2-dcfe-6b87-a51148f88db8@gmail.com> <641c4c68-a8d1-6007-8d00-9adcc202f5fc@gmail.com> <134a19c3-3a09-9403-7152-3bab7bb0bae6@oracle.com> Message-ID: <937b1baf-2bac-5cee-bb14-e376e709b245@oracle.com> Can you please ensure you have tested all the j* tool using tests please as we are seeing related failures e.g. sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java Exception in thread "main" java.lang.NumberFormatException: For input string: "18446744073709486080" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68) at java.base/java.lang.Long.parseLong(Long.java:699) at java.base/java.lang.Long.parseLong(Long.java:824) at jdk.hotspot.agent/sun.jvm.hotspot.tools.HeapSummary.getFlagValue(HeapSummary.java:298) at jdk.hotspot.agent/sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:86) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) Thanks, David On 27/01/2019 9:23 am, David Holmes wrote: > Hi Yasumasa, > > That seems quite reasonable. > > Thanks for the quick fix. > > David > ----- > > On 26/01/2019 10:47 pm, Yasumasa Suenaga wrote: >> Sorry, webrev is here: >> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8217850/webrev.00/ >> >> >> Yasumasa >> >> >> On 2019/01/26 21:44, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217850 >>> ?? webrev: https://bugs.openjdk.java.net/browse/JDK-8217850 >>> >>> This change passed tests on submit repo, and >>> test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >>> on my Linux x64 box. >>> >>> >>> Thanks, >>> >>> Yasumasa From david.holmes at oracle.com Sun Jan 27 00:06:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Sun, 27 Jan 2019 10:06:19 +1000 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: <738a9af2-988a-457e-6fb2-9ff5b04b14bb@oracle.com> References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> <738a9af2-988a-457e-6fb2-9ff5b04b14bb@oracle.com> Message-ID: <03871531-75db-83b1-8f0f-ef0b3e4a6b57@oracle.com> On 27/01/2019 6:33 am, dean.long at oracle.com wrote: > I think there is going to be a race with resume wherever you put the > self-suspend, because we do it without holding SR_lock.? So you should > be able to move the self check and self suspend to before the SR_lock. > This would just be a performance optimization. I would prefer not to skip the resume checks even if they are racy. The logic is very obvious in the current form: safepoint for "other" thread else self-suspend. Thanks, David > dl > > On 1/24/19 6:46 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 >> webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ >> >> Lots of analysis in the bug report. Bottom line: SuspendThread of the >> current thread was not actually suspending the thread until it hit >> specific thread-state transitions. That meant that SuspendThread would >> actually return and continue executing native code whilst suspended, >> in violation of the specification for it. >> >> The fix is quite simple: in java_suspend() we check for the current >> thread and call java_suspend_self(). >> >> Testing: >> ?- Any test that looked like it referred to thread suspension >> ? - hotspot/jtreg/vmTestbase/nsk/jvmti/* >> ? - jdk/ >> ???? com/sun/jdi/* >> ???? java/lang/ThreadGroup/Suspend.java >> java/lang/management/CompositeData/ThreadInfoCompositeData.java >> ???? java/lang/management/ThreadMXBean/* >> ???? java/nio/channels/SocketChannel/SendUrgentData.java >> java/util/logging/LogManager/Configuration/TestConfigurationLock.java >> >> ?- Mach 5 tiers 1-3 (in progress) >> >> Two tests were found to be erroneously relying on SuspendThread >> returning whilst suspended: >> >> - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp >> >> The test updated a shared counter after the SuspendThread call, but it >> needed to be updated before the call. >> >> - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp >> >> The test was using a 0 return value from SuspendThread as an indicator >> that the thread was in the suspended state - but that value can't be >> seen until after SuspendThread returns, which is after the thread is >> resumed. So I ripped out the custom state tracking logic and replaced >> with a simple check of GetThreadState. >> >> Thanks, >> David > From yasuenag at gmail.com Sun Jan 27 01:41:42 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sun, 27 Jan 2019 10:41:42 +0900 Subject: RFR: 8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612 In-Reply-To: <937b1baf-2bac-5cee-bb14-e376e709b245@oracle.com> References: <5da25f73-c0e2-dcfe-6b87-a51148f88db8@gmail.com> <641c4c68-a8d1-6007-8d00-9adcc202f5fc@gmail.com> <134a19c3-3a09-9403-7152-3bab7bb0bae6@oracle.com> <937b1baf-2bac-5cee-bb14-e376e709b245@oracle.com> Message-ID: Hi David, On 2019/01/27 8:59, David Holmes wrote: > Can you please ensure you have tested all the j* tool using tests please as we are seeing related failures e.g. > > sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java > > Exception in thread "main" java.lang.NumberFormatException: For input string: "18446744073709486080" > ????at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68) > ????at java.base/java.lang.Long.parseLong(Long.java:699) > ????at java.base/java.lang.Long.parseLong(Long.java:824) > ????at jdk.hotspot.agent/sun.jvm.hotspot.tools.HeapSummary.getFlagValue(HeapSummary.java:298) > ????at jdk.hotspot.agent/sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:86) > ????at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) This change affects SA, so I grep'ed test code with jhsdb: ``` [ysuenaga at fc29 test]$ grep -lrw jhsdb * hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java hotspot/jtreg/serviceability/sa/TestIntConstant.java hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java hotspot/jtreg/serviceability/sa/TestUniverse.java hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java hotspot/jtreg/serviceability/sa/TestType.java hotspot/jtreg/serviceability/sa/CDSJMapClstats.java hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java hotspot/jtreg/serviceability/sa/TestPrintMdo.java hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java hotspot/jtreg/serviceability/sa/TestJmapCore.java hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java jdk/sun/tools/jhsdb/heapconfig/TmtoolTestScenario.java jdk/sun/tools/jhsdb/HeapDumpTest.java jdk/sun/tools/jhsdb/BasicLauncherTest.java jdk/tools/launcher/HelpFlagsTest.java jdk/ProblemList.txt jtreg-ext/requires/VMProps.java lib/jdk/test/lib/Platform.java ``` Thuns I run tests as following, and they work fine with JDK-8217850 fix: ``` [ysuenaga at fc29 jdk]$ $JT_HOME/bin/jtreg -ignore:quiet -exclude:ProblemList.txt -nativepath:/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-server-fastdebug/support/test/jdk/jtreg/native/lib sun/tools/jhsdb tools/launcher/HelpFlagsTest.java Directory "JTwork" not found: creating Directory "JTreport" not found: creating Test results: passed: 5 ``` Can I push JDK-8217850 change? or should I test more? I think hotspot/jtreg/serviceability/sa will be run on submit repo (tier-1 test). Thanks, Yasumasa > Thanks, > David > > > On 27/01/2019 9:23 am, David Holmes wrote: >> Hi Yasumasa, >> >> That seems quite reasonable. >> >> Thanks for the quick fix. >> >> David >> ----- >> >> On 26/01/2019 10:47 pm, Yasumasa Suenaga wrote: >>> Sorry, webrev is here: >>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8217850/webrev.00/ >>> >>> >>> Yasumasa >>> >>> >>> On 2019/01/26 21:44, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217850 >>>> ?? webrev: https://bugs.openjdk.java.net/browse/JDK-8217850 >>>> >>>> This change passed tests on submit repo, and test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on my Linux x64 box. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa From daniel.daugherty at oracle.com Sun Jan 27 03:43:01 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 26 Jan 2019 22:43:01 -0500 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: <03871531-75db-83b1-8f0f-ef0b3e4a6b57@oracle.com> References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> <738a9af2-988a-457e-6fb2-9ff5b04b14bb@oracle.com> <03871531-75db-83b1-8f0f-ef0b3e4a6b57@oracle.com> Message-ID: On 1/26/19 7:06 PM, David Holmes wrote: > On 27/01/2019 6:33 am, dean.long at oracle.com wrote: >> I think there is going to be a race with resume wherever you put the >> self-suspend, because we do it without holding SR_lock.? So you >> should be able to move the self check and self suspend to before the >> SR_lock. This would just be a performance optimization. Dean, let's see if I understand what race you're worried about. The JavaThread is suspending itself so it has to be resumed from another thread. The other thread cannot reliably call ResumeThread() until it has observed the target thread as suspended via GetThreadStatus(). The relevant thread status bits are set here: open/src/hotspot/share/prims/jvmtiEnv.cpp: ??? if (java_thread->is_being_ext_suspended()) { ????? state |= JVMTI_THREAD_STATE_SUSPENDED; ??? } open/src/hotspot/share/runtime/thread.hpp: ? // utility methods to see if we are doing some kind of suspension ? bool is_being_ext_suspended() const??????????? { ??? MutexLockerEx ml(SR_lock(), Mutex::_no_safepoint_check_flag); ??? return is_ext_suspended() || is_external_suspend(); ? } So it looks like 'other thread' can see is_external_suspend() on the target thread and call ResumeThread(). And yes, that ResumeThread() can happen after the SR_lock() is dropped in java_suspend() and before the new java_suspend_self() call. However, java_suspend_self() is careful and only self-suspends if is_external_suspend() is still true (and it makes that check while it owns the SR_lock). The code in java_suspend_self() has to be careful in both directions. You don't want it to self-suspend when it has been resumed by a racer and you don't want it to resume if there was another SuspendThread() call was made and has returned to it's caller. Check out the comments in java_suspend_self(); they should help clarify things. > I would prefer not to skip the resume checks even if they are racy. The existing resume checks are not racy because the SR_lock is held. > The logic is very obvious in the current form: safepoint for "other" > thread else self-suspend. Agreed. Dan > > Thanks, > David > > >> dl >> >> On 1/24/19 6:46 PM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 >>> webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ >>> >>> Lots of analysis in the bug report. Bottom line: SuspendThread of >>> the current thread was not actually suspending the thread until it >>> hit specific thread-state transitions. That meant that SuspendThread >>> would actually return and continue executing native code whilst >>> suspended, in violation of the specification for it. >>> >>> The fix is quite simple: in java_suspend() we check for the current >>> thread and call java_suspend_self(). >>> >>> Testing: >>> ?- Any test that looked like it referred to thread suspension >>> ? - hotspot/jtreg/vmTestbase/nsk/jvmti/* >>> ? - jdk/ >>> ???? com/sun/jdi/* >>> ???? java/lang/ThreadGroup/Suspend.java >>> java/lang/management/CompositeData/ThreadInfoCompositeData.java >>> ???? java/lang/management/ThreadMXBean/* >>> ???? java/nio/channels/SocketChannel/SendUrgentData.java >>> java/util/logging/LogManager/Configuration/TestConfigurationLock.java >>> >>> ?- Mach 5 tiers 1-3 (in progress) >>> >>> Two tests were found to be erroneously relying on SuspendThread >>> returning whilst suspended: >>> >>> - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp >>> >>> The test updated a shared counter after the SuspendThread call, but >>> it needed to be updated before the call. >>> >>> - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp >>> >>> The test was using a 0 return value from SuspendThread as an >>> indicator that the thread was in the suspended state - but that >>> value can't be seen until after SuspendThread returns, which is >>> after the thread is resumed. So I ripped out the custom state >>> tracking logic and replaced with a simple check of GetThreadState. >>> >>> Thanks, >>> David >> From dean.long at oracle.com Sun Jan 27 20:39:53 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sun, 27 Jan 2019 12:39:53 -0800 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> <738a9af2-988a-457e-6fb2-9ff5b04b14bb@oracle.com> <03871531-75db-83b1-8f0f-ef0b3e4a6b57@oracle.com> Message-ID: <5110c7aa-2c65-6c81-3b17-f05ff6ce09a3@oracle.com> On 1/26/19 7:43 PM, Daniel D. Daugherty wrote: > However, java_suspend_self() is careful and only self-suspends if > is_external_suspend() is still true (and it makes that check while > it owns the SR_lock). The code in java_suspend_self() has to be > careful in both directions. You don't want it to self-suspend > when it has been resumed by a racer and you don't want it to > resume if there was another SuspendThread() call was made and > has returned to it's caller. Check out the comments in > java_suspend_self(); they should help clarify things. Thanks for the explanation.? I was assuming that if you call suspend and resume without synchronization, then all bets are off.? But since we already have some guarantees in place, it makes sense to preserve them. dl From david.holmes at oracle.com Sun Jan 27 20:46:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Jan 2019 06:46:04 +1000 Subject: RFR: 8217850: CompressedClassSpaceSizeInJmapHeap fails after JDK-8217612 In-Reply-To: References: <5da25f73-c0e2-dcfe-6b87-a51148f88db8@gmail.com> <641c4c68-a8d1-6007-8d00-9adcc202f5fc@gmail.com> <134a19c3-3a09-9403-7152-3bab7bb0bae6@oracle.com> <937b1baf-2bac-5cee-bb14-e376e709b245@oracle.com> Message-ID: <44b5062c-0c53-762f-49d3-85cf20a5fcb0@oracle.com> Hi Yasumasa, Please push. Thanks, David On 27/01/2019 11:41 am, Yasumasa Suenaga wrote: > Hi David, > > On 2019/01/27 8:59, David Holmes wrote: >> Can you please ensure you have tested all the j* tool using tests >> please as we are seeing related failures e.g. >> >> sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java >> >> Exception in thread "main" java.lang.NumberFormatException: For input >> string: "18446744073709486080" >> ?????at >> java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:68) >> >> ?????at java.base/java.lang.Long.parseLong(Long.java:699) >> ?????at java.base/java.lang.Long.parseLong(Long.java:824) >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.HeapSummary.getFlagValue(HeapSummary.java:298) >> >> ?????at >> jdk.hotspot.agent/sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:86) >> >> ?????at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:115) > > This change affects SA, so I grep'ed test code with jhsdb: > > > ``` > [ysuenaga at fc29 test]$ grep -lrw jhsdb * > hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java > hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java > hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java > hotspot/jtreg/serviceability/sa/TestIntConstant.java > hotspot/jtreg/serviceability/sa/sadebugd/SADebugDTest.java > hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java > hotspot/jtreg/serviceability/sa/TestUniverse.java > hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java > hotspot/jtreg/serviceability/sa/TestType.java > hotspot/jtreg/serviceability/sa/CDSJMapClstats.java > hotspot/jtreg/serviceability/sa/JhsdbThreadInfoTest.java > hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java > hotspot/jtreg/serviceability/sa/TestPrintMdo.java > hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java > hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java > hotspot/jtreg/serviceability/sa/TestJmapCore.java > hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java > jdk/sun/tools/jhsdb/heapconfig/TmtoolTestScenario.java > jdk/sun/tools/jhsdb/HeapDumpTest.java > jdk/sun/tools/jhsdb/BasicLauncherTest.java > jdk/tools/launcher/HelpFlagsTest.java > jdk/ProblemList.txt > jtreg-ext/requires/VMProps.java > lib/jdk/test/lib/Platform.java > ``` > > Thuns I run tests as following, and they work fine with JDK-8217850 fix: > > > ``` > [ysuenaga at fc29 jdk]$ $JT_HOME/bin/jtreg -ignore:quiet > -exclude:ProblemList.txt > -nativepath:/home/ysuenaga/OpenJDK/jdk/build/linux-x86_64-server-fastdebug/support/test/jdk/jtreg/native/lib > sun/tools/jhsdb tools/launcher/HelpFlagsTest.java > Directory "JTwork" not found: creating > Directory "JTreport" not found: creating > Test results: passed: 5 > ``` > > Can I push JDK-8217850 change? or should I test more? > I think hotspot/jtreg/serviceability/sa will be run on submit repo > (tier-1 test). > > > Thanks, > > Yasumasa > > >> Thanks, >> David >> >> >> On 27/01/2019 9:23 am, David Holmes wrote: >>> Hi Yasumasa, >>> >>> That seems quite reasonable. >>> >>> Thanks for the quick fix. >>> >>> David >>> ----- >>> >>> On 26/01/2019 10:47 pm, Yasumasa Suenaga wrote: >>>> Sorry, webrev is here: >>>> ?? http://cr.openjdk.java.net/~ysuenaga/JDK-8217850/webrev.00/ >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/01/26 21:44, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8217850 >>>>> ?? webrev: https://bugs.openjdk.java.net/browse/JDK-8217850 >>>>> >>>>> This change passed tests on submit repo, and >>>>> test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java >>>>> on my Linux x64 box. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa From yasuenag at gmail.com Mon Jan 28 00:35:10 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 28 Jan 2019 09:35:10 +0900 Subject: RFR: 8217845: SA should refer const values for JVMFlag from HotSpot In-Reply-To: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> References: <3058d9a2-59d8-5e5d-18a9-6f7657ded770@gmail.com> Message-ID: 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 david.holmes at oracle.com Mon Jan 28 01:49:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Jan 2019 11:49:59 +1000 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> <738a9af2-988a-457e-6fb2-9ff5b04b14bb@oracle.com> <03871531-75db-83b1-8f0f-ef0b3e4a6b57@oracle.com> Message-ID: <85b0762a-f74b-37de-8c92-b357e13f5e5c@oracle.com> Thanks for explaining that Dan! David On 27/01/2019 1:43 pm, Daniel D. Daugherty wrote: > On 1/26/19 7:06 PM, David Holmes wrote: >> On 27/01/2019 6:33 am, dean.long at oracle.com wrote: >>> I think there is going to be a race with resume wherever you put the >>> self-suspend, because we do it without holding SR_lock.? So you >>> should be able to move the self check and self suspend to before the >>> SR_lock. This would just be a performance optimization. > > Dean, let's see if I understand what race you're worried about. > > The JavaThread is suspending itself so it has to be resumed from > another thread. The other thread cannot reliably call ResumeThread() > until it has observed the target thread as suspended via > GetThreadStatus(). The relevant thread status bits are set here: > > open/src/hotspot/share/prims/jvmtiEnv.cpp: > > ??? if (java_thread->is_being_ext_suspended()) { > ????? state |= JVMTI_THREAD_STATE_SUSPENDED; > ??? } > > open/src/hotspot/share/runtime/thread.hpp: > > ? // utility methods to see if we are doing some kind of suspension > ? bool is_being_ext_suspended() const??????????? { > ??? MutexLockerEx ml(SR_lock(), Mutex::_no_safepoint_check_flag); > ??? return is_ext_suspended() || is_external_suspend(); > ? } > > So it looks like 'other thread' can see is_external_suspend() on the > target thread and call ResumeThread(). And yes, that ResumeThread() > can happen after the SR_lock() is dropped in java_suspend() and > before the new java_suspend_self() call. > > However, java_suspend_self() is careful and only self-suspends if > is_external_suspend() is still true (and it makes that check while > it owns the SR_lock). The code in java_suspend_self() has to be > careful in both directions. You don't want it to self-suspend > when it has been resumed by a racer and you don't want it to > resume if there was another SuspendThread() call was made and > has returned to it's caller. Check out the comments in > java_suspend_self(); they should help clarify things. > > >> I would prefer not to skip the resume checks even if they are racy. > > The existing resume checks are not racy because the SR_lock is > held. > > >> The logic is very obvious in the current form: safepoint for "other" >> thread else self-suspend. > > Agreed. > > Dan > > >> >> Thanks, >> David >> >> >>> dl >>> >>> On 1/24/19 6:46 PM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ >>>> >>>> Lots of analysis in the bug report. Bottom line: SuspendThread of >>>> the current thread was not actually suspending the thread until it >>>> hit specific thread-state transitions. That meant that SuspendThread >>>> would actually return and continue executing native code whilst >>>> suspended, in violation of the specification for it. >>>> >>>> The fix is quite simple: in java_suspend() we check for the current >>>> thread and call java_suspend_self(). >>>> >>>> Testing: >>>> ?- Any test that looked like it referred to thread suspension >>>> ? - hotspot/jtreg/vmTestbase/nsk/jvmti/* >>>> ? - jdk/ >>>> ???? com/sun/jdi/* >>>> ???? java/lang/ThreadGroup/Suspend.java >>>> java/lang/management/CompositeData/ThreadInfoCompositeData.java >>>> ???? java/lang/management/ThreadMXBean/* >>>> ???? java/nio/channels/SocketChannel/SendUrgentData.java >>>> java/util/logging/LogManager/Configuration/TestConfigurationLock.java >>>> >>>> ?- Mach 5 tiers 1-3 (in progress) >>>> >>>> Two tests were found to be erroneously relying on SuspendThread >>>> returning whilst suspended: >>>> >>>> - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp >>>> >>>> The test updated a shared counter after the SuspendThread call, but >>>> it needed to be updated before the call. >>>> >>>> - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp >>>> >>>> The test was using a 0 return value from SuspendThread as an >>>> indicator that the thread was in the suspended state - but that >>>> value can't be seen until after SuspendThread returns, which is >>>> after the thread is resumed. So I ripped out the custom state >>>> tracking logic and replaced with a simple check of GetThreadState. >>>> >>>> Thanks, >>>> David >>> > From zanglin5 at jd.com Mon Jan 28 09:49:42 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Mon, 28 Jan 2019 09:49:42 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <0cf0d209864e46a3bdcbe6a9080ec1dc@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> Message-ID: 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 dean.long at oracle.com Tue Jan 29 01:13:21 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 28 Jan 2019 17:13:21 -0800 Subject: 12 RFR(M) 8195635: [Graal] nsk/jvmti/unit/ForceEarlyReturn/earlyretbase crashes with assertion "compilation level out of bounds" Message-ID: <9b4a4594-458e-ae18-0606-9b1ecbb400ce@oracle.com> http://cr.openjdk.java.net/~dlong/8195635/webrev.5/ https://bugs.openjdk.java.net/browse/JDK-8195635 Please see the bug report for all the gory details.? Here's the short version: If we allow any safepoint to be a suspend point, we run into trouble with PopFrame and ForceEarlyReturn, which reasonably expect the top frame not to change between the suspend and when the PopFrame/ForceEarlyReturn is executed.? Normally this is not an issue, but certain safepoints cause problems, when we are about to call a new Java method.? In particular, if we safepoint and suspend in JavaCallWrapper, the top frame will still be the caller, but when we execute the PopFrame/ForceEarlyReturn we will be in the callee. The solution this patch takes is to block suspend around troublesome VM code using a new "allow_suspend" thread flag.? This means JavaThread::java_suspend can't just ask the VMThread to safepoint and be done.? Instead it has wait and allow threads to roll forward to an allowed suspend point. dl From serguei.spitsyn at oracle.com Tue Jan 29 06:48:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 28 Jan 2019 22:48:21 -0800 Subject: 12 RFR(M) 8195635: [Graal] nsk/jvmti/unit/ForceEarlyReturn/earlyretbase crashes with assertion "compilation level out of bounds" In-Reply-To: <9b4a4594-458e-ae18-0606-9b1ecbb400ce@oracle.com> References: <9b4a4594-458e-ae18-0606-9b1ecbb400ce@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From david.griffiths at gmail.com Tue Jan 29 11:24:29 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Tue, 29 Jan 2019 11:24:29 +0000 Subject: Is RegisterMap updated? Message-ID: Hi, in CompiledVFrame.createStackValue there is the following code: // First find address of value Address valueAddr = loc.isRegister() // Value was in a callee-save register ? getRegisterMap().getLocation(new VMReg(loc.getRegisterNumber())) // Else value was directly saved on the stack. The frame's original stack pointer, // before any extension by its callee (due to Compiler1 linkage on SPARC), must be used. : ((Address)fr.getUnextendedSP()).addOffsetTo(loc.getStackOffset()); It appears from what I can make out that for the register case the map is not updated and so valueAddr is null. The only thing I can see that calls setLocation is updateMapWithSavedLink. Seems like it should be possible to return the register value for the frame at the top of the stack though? Cheers, David From aph at redhat.com Tue Jan 29 13:40:40 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Jan 2019 13:40:40 +0000 Subject: Is RegisterMap updated? In-Reply-To: References: Message-ID: On 1/29/19 11:24 AM, David Griffiths wrote: > Hi, in CompiledVFrame.createStackValue there is the following code: > > // First find address of value > Address valueAddr = loc.isRegister() > // Value was in a callee-save register > ? getRegisterMap().getLocation(new VMReg(loc.getRegisterNumber())) > // Else value was directly saved on the stack. The frame's > original stack pointer, > // before any extension by its callee (due to Compiler1 > linkage on SPARC), must be used. > : ((Address)fr.getUnextendedSP()).addOffsetTo(loc.getStackOffset()); > > It appears from what I can make out that for the register case the map > is not updated and so valueAddr is null. The only thing I can see that > calls setLocation is updateMapWithSavedLink. Seems like it should be > possible to return the register value for the frame at the top of the > stack though? It could be, but we don't do that. The registers in the map are those pushed onto the stack by generated Java code. -- 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 Tue Jan 29 15:41:22 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Tue, 29 Jan 2019 15:41:22 +0000 Subject: Is RegisterMap updated? In-Reply-To: References: Message-ID: Oh, I'm looking at the jdk8u code which has the following code commented out: /* if (map.getUpdateMap()) { // Tell GC to use argument oopmaps for some runtime stubs that need it. // For C1, the runtime stub might not have oop maps, so set this flag // outside of update_register_map. map.setIncludeArgumentOops(cb.callerMustGCArguments()); if (cb.getOopMaps() != null) { OopMapSet.updateRegisterMap(this, cb, map, true); } // Since the prolog does the save and restore of EBP there is no oopmap // for it so we must fill in its location as if there was an oopmap entry // since if our caller was compiled code there could be live jvm state in it. updateMapWithSavedLink(map, savedFPAddr); } */ I see that is no longer commented out in jdk9 so maybe that's the cause. (There is nothing else that calls setLocation). Cheers, David On Tue, 29 Jan 2019 at 13:41, Andrew Haley wrote: > > On 1/29/19 11:24 AM, David Griffiths wrote: > > Hi, in CompiledVFrame.createStackValue there is the following code: > > > > // First find address of value > > Address valueAddr = loc.isRegister() > > // Value was in a callee-save register > > ? getRegisterMap().getLocation(new VMReg(loc.getRegisterNumber())) > > // Else value was directly saved on the stack. The frame's > > original stack pointer, > > // before any extension by its callee (due to Compiler1 > > linkage on SPARC), must be used. > > : ((Address)fr.getUnextendedSP()).addOffsetTo(loc.getStackOffset()); > > > > It appears from what I can make out that for the register case the map > > is not updated and so valueAddr is null. The only thing I can see that > > calls setLocation is updateMapWithSavedLink. Seems like it should be > > possible to return the register value for the frame at the top of the > > stack though? > > It could be, but we don't do that. The registers in the map are those > pushed onto the stack by generated Java code. > > -- > 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 Tue Jan 29 16:09:27 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 29 Jan 2019 11:09:27 -0500 Subject: RFR: JDK-8215550: Debugger does not work after reattach Message-ID: <5C507AB7.8090809@oracle.com> Significant protections are put in place to protect the commandLoop from multiple events that that have a suspend-all policy. The commandLoop uses a special block variable to ensure only a VirtualMachine or ThreadReference call to resume() will unblock the commandLoop. See src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c In this particular bug report, the user was stopped at a breakpoint when they sent the "exit" command. The same effect can be produced with a "quit" command or any killing of the debugger process. When the second session is started the commandLoop is still blocked, so a new breakpoint will never be dequeued from the commandQueue. The proposed workaround will ensure the commandLoop is unblocked when a new session is started. Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ All testing has been done by manually replicating the reported command sequences. I'll see if an existing breakpoint test can be enhanced to cover this scenario. From david.griffiths at gmail.com Tue Jan 29 16:17:57 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Tue, 29 Jan 2019 16:17:57 +0000 Subject: Is RegisterMap updated? In-Reply-To: References: Message-ID: Oops, ignore that last message! On Tue, 29 Jan 2019 at 15:41, David Griffiths wrote: > > Oh, I'm looking at the jdk8u code which has the following code commented out: > > /* > if (map.getUpdateMap()) { > // Tell GC to use argument oopmaps for some runtime stubs that need it. > // For C1, the runtime stub might not have oop maps, so set this flag > // outside of update_register_map. > map.setIncludeArgumentOops(cb.callerMustGCArguments()); > > if (cb.getOopMaps() != null) { > OopMapSet.updateRegisterMap(this, cb, map, true); > } > > // Since the prolog does the save and restore of EBP there is no oopmap > // for it so we must fill in its location as if there was an oopmap entry > // since if our caller was compiled code there could be live jvm > state in it. > updateMapWithSavedLink(map, savedFPAddr); > } > */ > > I see that is no longer commented out in jdk9 so maybe that's the > cause. (There is nothing else that calls setLocation). > > Cheers, > > David > > On Tue, 29 Jan 2019 at 13:41, Andrew Haley wrote: > > > > On 1/29/19 11:24 AM, David Griffiths wrote: > > > Hi, in CompiledVFrame.createStackValue there is the following code: > > > > > > // First find address of value > > > Address valueAddr = loc.isRegister() > > > // Value was in a callee-save register > > > ? getRegisterMap().getLocation(new VMReg(loc.getRegisterNumber())) > > > // Else value was directly saved on the stack. The frame's > > > original stack pointer, > > > // before any extension by its callee (due to Compiler1 > > > linkage on SPARC), must be used. > > > : ((Address)fr.getUnextendedSP()).addOffsetTo(loc.getStackOffset()); > > > > > > It appears from what I can make out that for the register case the map > > > is not updated and so valueAddr is null. The only thing I can see that > > > calls setLocation is updateMapWithSavedLink. Seems like it should be > > > possible to return the register value for the frame at the top of the > > > stack though? > > > > It could be, but we don't do that. The registers in the map are those > > pushed onto the stack by generated Java code. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From chris.plummer at oracle.com Tue Jan 29 17:17:23 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 29 Jan 2019 09:17:23 -0800 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: <5C507AB7.8090809@oracle.com> References: <5C507AB7.8090809@oracle.com> Message-ID: <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> Hi Gary, When the "exit" or "quit" is done, aren't all threads resumed at that point, and shouldn't that result in the command loop being unblocked? thanks, Chris On 1/29/19 8:09 AM, Gary Adams wrote: > Significant protections are put in place to protect the commandLoop > from multiple events that that have a suspend-all policy. The > commandLoop uses a special block variable to ensure only > a VirtualMachine or ThreadReference call to resume() will unblock > the commandLoop. See > > ? src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c > > In this particular bug report, the user was stopped at a breakpoint > when they sent the "exit" command. The same effect can be produced > with a "quit" command or any killing of the debugger process. > > When the second session is started the commandLoop is still blocked, > so a new breakpoint will never be dequeued from the commandQueue. > > The proposed workaround will ensure the commandLoop is unblocked > when a new session is started. > > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 > ? Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ > > All testing has been done by manually replicating the reported > command sequences. I'll see if an existing breakpoint test can be > enhanced to cover this scenario. From jcbeyler at google.com Tue Jan 29 17:21:13 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 29 Jan 2019 09:21:13 -0800 Subject: RFR(S) 8215113: Sampling interval not always correct In-Reply-To: References: <45A5FFFC-729A-4E50-877E-955CE17BF9FA@amazon.com> Message-ID: Hi Serguei, Sorry it took so long to answer, I just got submit repo to work with it. It passes there, I think that should be enough for now but we could do a mach5 testing if you prefer (and could you/someone do it please?) I also opened https://bugs.openjdk.java.net/browse/JDK-8217267 to really study the bias and accuracy of the sampling a bit more. So this might get revisited in the near future but this particular webrev is "important" as it fixes the tests to be doing what we want them to do. Let me know what you think, Jc On Tue, Jan 22, 2019 at 1:14 PM wrote: > > > On 1/22/19 12:54 PM, serguei.spitsyn at oracle.com wrote: > > Hi Jc, > > It looks good to me too. > > > Forgot to say that I hope it was tested well. > > Thanks, > Serguei > > > Thanks, > Serguei > > > On 1/11/19 5:07 PM, Hohensee, Paul wrote: > > Nits: > > > > memAllocator.cpp: > > > > Copyright line should read > > > > * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights > reserved. > > > > The comment > > > > // Tell tlab to forget the bytes_since if we passed it to the heap sampler. > > > > would be clearer if it read > > > > // Tell tlab to forget bytes_since_last if we passed it to the heap sampler. > > Same copyright line comment for HeapMonitor.java, > HeapMonitorArrayAllSampledTest.java and HeapMonitorStatArrayCorrectnessTest.java > as for memAllocator.cpp. > > Otherwise lgtm, no need for another webrev on my account. > > > Thanks, > > > > Paul > > > > *From: *serviceability-dev > on behalf of JC Beyler > > *Date: *Thursday, January 10, 2019 at 11:28 AM > *To: *OpenJDK Serviceability > > *Subject: *RFR(S) 8215113: Sampling interval not always correct > > > > Hi all, > > > > Could I get a review for this: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8215113/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215113 > > > > This fixes the code to do the right accounting in sampling and get the > right sample counts and sampled objects. My error percentage calculation > was wrong so the two tests I had added were false positives (my apologies). > > > > Thanks, > > Jc > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Tue Jan 29 17:55:47 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 29 Jan 2019 12:55:47 -0500 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> References: <5C507AB7.8090809@oracle.com> <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> Message-ID: <5C5093A3.3010407@oracle.com> As far as I can tell, the quit and exit commands are only handled locally on the debugger side of the connection. There is no packet sent to the libjdwp agentlib. On 1/29/19, 12:17 PM, Chris Plummer wrote: > Hi Gary, > > When the "exit" or "quit" is done, aren't all threads resumed at that > point, and shouldn't that result in the command loop being unblocked? > > thanks, > > Chris > > On 1/29/19 8:09 AM, Gary Adams wrote: >> Significant protections are put in place to protect the commandLoop >> from multiple events that that have a suspend-all policy. The >> commandLoop uses a special block variable to ensure only >> a VirtualMachine or ThreadReference call to resume() will unblock >> the commandLoop. See >> >> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >> >> In this particular bug report, the user was stopped at a breakpoint >> when they sent the "exit" command. The same effect can be produced >> with a "quit" command or any killing of the debugger process. >> >> When the second session is started the commandLoop is still blocked, >> so a new breakpoint will never be dequeued from the commandQueue. >> >> The proposed workaround will ensure the commandLoop is unblocked >> when a new session is started. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 >> Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ >> >> All testing has been done by manually replicating the reported >> command sequences. I'll see if an existing breakpoint test can be >> enhanced to cover this scenario. > > > From chris.plummer at oracle.com Tue Jan 29 19:27:45 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 29 Jan 2019 11:27:45 -0800 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: <5C5093A3.3010407@oracle.com> References: <5C507AB7.8090809@oracle.com> <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> <5C5093A3.3010407@oracle.com> Message-ID: <1032eb8d-e814-1af9-758e-45b05b638f22@oracle.com> What is the state of the threads after the detach? If they are all automatically resumed by the agent, then I think the unblocking should be done by the same code that resumes the threads. If they are still suspended, then why would we want to unblock when the next connection comes in? It should be up to the debugger to detect that all threads are suspended and act accordingly. Also, what happens if after attaching again you issue a "cont" command? Chris On 1/29/19 9:55 AM, Gary Adams wrote: > As far as I can tell, the quit and exit commands are only handled locally > on the debugger side of the connection. There is no packet sent to the > libjdwp agentlib. > > On 1/29/19, 12:17 PM, Chris Plummer wrote: >> Hi Gary, >> >> When the "exit" or "quit" is done, aren't all threads resumed at that >> point, and shouldn't that result in the command loop being unblocked? >> >> thanks, >> >> Chris >> >> On 1/29/19 8:09 AM, Gary Adams wrote: >>> Significant protections are put in place to protect the commandLoop >>> from multiple events that that have a suspend-all policy. The >>> commandLoop uses a special block variable to ensure only >>> a VirtualMachine or ThreadReference call to resume() will unblock >>> the commandLoop. See >>> >>> ? src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>> >>> In this particular bug report, the user was stopped at a breakpoint >>> when they sent the "exit" command. The same effect can be produced >>> with a "quit" command or any killing of the debugger process. >>> >>> When the second session is started the commandLoop is still blocked, >>> so a new breakpoint will never be dequeued from the commandQueue. >>> >>> The proposed workaround will ensure the commandLoop is unblocked >>> when a new session is started. >>> >>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 >>> ? Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ >>> >>> All testing has been done by manually replicating the reported >>> command sequences. I'll see if an existing breakpoint test can be >>> enhanced to cover this scenario. >> >> >> > From daniil.x.titov at oracle.com Tue Jan 29 19:40:47 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 29 Jan 2019 11:40:47 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: <36e052be-5c46-2d51-efbd-b8fb76df4ffc@oracle.com> References: <72D6EC06-48FD-4C0D-8C7B-DB51F8D8E359@oracle.com> <36e052be-5c46-2d51-efbd-b8fb76df4ffc@oracle.com> Message-ID: <4E44EBFF-FA65-40A2-BC3E-02ABC5D5814A@oracle.com> Hi JC, Could you please say are you OK with this new version of the fix? Thanks! --Daniil ?On 1/26/19, 11:35 AM, "Chris Plummer" wrote: Looks good. thanks, Chris On 1/26/19 11:23 AM, Daniil Titov wrote: > Hi Chris, > > Please review a new version of the patch that moves the disabling of the single stepping into ConstantPool::klass_at_impl(). > > Mach5 jdk_jdi, vmTestbase_nsk_jdi, vmTestbase_nsk_jdb and serviceability tests, as well as all tier1,tier2 and tier3 tests successfully passed. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks! > --Daniil > > ?On 1/24/19, 11:19 AM, "Chris Plummer" wrote: > > Hi Daniil, > > Thanks for the stack track. I was just about to send an email asking for > it when your new RFR arrived. > > The fix looks good. I think you also need to apply it here: > > InterpreterRuntime::ldc() > InterpreterRuntime::anewarray() > InterpreterRuntime::multianewarray() > InterpreterRuntime::quicken_io_cc() > > I wonder if it wouldn't be better if you moved the disabling into > ConstantPool::klass_at_impl() > > thanks, > > Chris > > On 1/24/19 10:38 AM, Daniil Titov wrote: > > Hi Chris and JC, > > > > Thank you for reviewing this change. Please review a new version of the fix that uses > > the approach Chris suggested ( disabling the single stepping during the class resolution). > > > > Just in case please find below the stack trace for this case when loadClass() method is entered. > > > > #0 SystemDictionary::load_instance_class(Symbol*, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 > > #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:853 > > #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:271 > > #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 > > #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:202 > > #5 ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 > > #6 ConstantPool::klass_at(int, Thread*) at open/src/hotspot/share/oops/constantPool.hpp:382 > > #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 > > # 8 > > .... > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > Thanks, > > Daniil > > > > ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: > > > > Hi Daniil, > > > > I don't see an explanation for why fromDepth is 1 and afterPopDepth is 4. > > > > currentDepth = getThreadFrameCount(thread); > > fromDepth = step->fromStackDepth; > > afterPopDepth = currentDepth-1; > > > > step->fromStackDepth got setup when single stepping was first setup for > > this thread. There was also a notifyFramePop() done at this time, but I > > think that's just to catch exiting from the method you were single > > stepping in, and has no bearing in the case we are looking at here, > > where we area still some # of frames below where we user last issued a > > STEP_INTO. The FRAME_POP we are receiving now is not the one for when > > step->fromStackDepth was setup, but is for when we stepped into a > > filtered method. I think this is what the "fromDepth > afterPopDepth" > > check is for. I think the current logic is correct for intended handling > > of a FRAME_POP event. Although your fix is probably solving the problem, > > I get the feeling it is enabling single stepping too soon in many cases. > > That many not turn up as an error in any tests, but could cause > > debugging performance issues, or for the user to see spurious single > > step events that they were not expecting. > > > > I think the bug actually occurs long before we ever get to this point in > > the code (and we should in fact not be getting here). In my last entry > > in the bug I mentioned JvmtiHideSingleStepping(), and how it is used to > > turn off single stepping while we are doing invoke and field resolution, > > but doesn't seem to be used during class resolution, which is what we > > are doing here. If it where used, then the agent would never even see > > the SINGLE_STEP when loadClass() is entered, therefore no > > notifyFramePop() would be done, and we would not be relying on this code > > in handleFramePopEvent(). Instead, we would receive the next SINGLE_STEP > > event after cp resolution is complete, and we are finally executing the > > now resolved opc_new opcode. > > > > I'm hoping Serguei and/or Alex can also comment on this, since I think > > they were dealing with JvmtiHideSingleStepping() last month. > > > > thanks, > > > > Chris > > > > > > > > On 1/17/19 6:08 PM, Daniil Titov wrote: > > > Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! > > > led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > > > > > > > From jcbeyler at google.com Tue Jan 29 20:09:38 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 29 Jan 2019 12:09:38 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: <4E44EBFF-FA65-40A2-BC3E-02ABC5D5814A@oracle.com> References: <72D6EC06-48FD-4C0D-8C7B-DB51F8D8E359@oracle.com> <36e052be-5c46-2d51-efbd-b8fb76df4ffc@oracle.com> <4E44EBFF-FA65-40A2-BC3E-02ABC5D5814A@oracle.com> Message-ID: Hi Daniil, I like this fix much better to be honest :) Jc On Tue, Jan 29, 2019 at 11:40 AM Daniil Titov wrote: > Hi JC, > > Could you please say are you OK with this new version of the fix? > > Thanks! > --Daniil > > > ?On 1/26/19, 11:35 AM, "Chris Plummer" wrote: > > Looks good. > > thanks, > > Chris > > On 1/26/19 11:23 AM, Daniil Titov wrote: > > Hi Chris, > > > > Please review a new version of the patch that moves the disabling of > the single stepping into ConstantPool::klass_at_impl(). > > > > Mach5 jdk_jdi, vmTestbase_nsk_jdi, vmTestbase_nsk_jdb and > serviceability tests, as well as all tier1,tier2 and tier3 tests > successfully passed. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.03/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > Thanks! > > --Daniil > > > > ?On 1/24/19, 11:19 AM, "Chris Plummer" > wrote: > > > > Hi Daniil, > > > > Thanks for the stack track. I was just about to send an email > asking for > > it when your new RFR arrived. > > > > The fix looks good. I think you also need to apply it here: > > > > InterpreterRuntime::ldc() > > InterpreterRuntime::anewarray() > > InterpreterRuntime::multianewarray() > > InterpreterRuntime::quicken_io_cc() > > > > I wonder if it wouldn't be better if you moved the disabling > into > > ConstantPool::klass_at_impl() > > > > thanks, > > > > Chris > > > > On 1/24/19 10:38 AM, Daniil Titov wrote: > > > Hi Chris and JC, > > > > > > Thank you for reviewing this change. Please review a new > version of the fix that uses > > > the approach Chris suggested ( disabling the single stepping > during the class resolution). > > > > > > Just in case please find below the stack trace for this case > when loadClass() method is entered. > > > > > > #0 SystemDictionary::load_instance_class(Symbol*, > Handle, Thread*) at > open/src/hotspot/share/classfile/systemDictionary.cpp:1502 > > > #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, > Handle, Handle, Thread*) at > open/src/hotspot/share/classfile/systemDictionary.cpp:853 > > > #2 > SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, > Handle, Thread*) at > open/src/hotspot/share/classfile/systemDictionary.cpp:271 > > > #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, > Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 > > > #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, > bool, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:202 > > > #5 ConstantPool::klass_at_impl(constantPoolHandle const&, > int, bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 > > > #6 ConstantPool::klass_at(int, Thread*) at > open/src/hotspot/share/oops/constantPool.hpp:382 > > > #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) > at open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 > > > # 8 > > > .... > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > > > Thanks, > > > Daniil > > > > > > ?On 1/23/19, 3:53 PM, "Chris Plummer" < > chris.plummer at oracle.com> wrote: > > > > > > Hi Daniil, > > > > > > I don't see an explanation for why fromDepth is 1 and > afterPopDepth is 4. > > > > > > currentDepth = getThreadFrameCount(thread); > > > fromDepth = step->fromStackDepth; > > > afterPopDepth = currentDepth-1; > > > > > > step->fromStackDepth got setup when single stepping was > first setup for > > > this thread. There was also a notifyFramePop() done at > this time, but I > > > think that's just to catch exiting from the method you > were single > > > stepping in, and has no bearing in the case we are > looking at here, > > > where we area still some # of frames below where we user > last issued a > > > STEP_INTO. The FRAME_POP we are receiving now is not the > one for when > > > step->fromStackDepth was setup, but is for when we > stepped into a > > > filtered method. I think this is what the "fromDepth > > afterPopDepth" > > > check is for. I think the current logic is correct for > intended handling > > > of a FRAME_POP event. Although your fix is probably > solving the problem, > > > I get the feeling it is enabling single stepping too > soon in many cases. > > > That many not turn up as an error in any tests, but > could cause > > > debugging performance issues, or for the user to see > spurious single > > > step events that they were not expecting. > > > > > > I think the bug actually occurs long before we ever get > to this point in > > > the code (and we should in fact not be getting here). In > my last entry > > > in the bug I mentioned JvmtiHideSingleStepping(), and > how it is used to > > > turn off single stepping while we are doing invoke and > field resolution, > > > but doesn't seem to be used during class resolution, > which is what we > > > are doing here. If it where used, then the agent would > never even see > > > the SINGLE_STEP when loadClass() is entered, therefore no > > > notifyFramePop() would be done, and we would not be > relying on this code > > > in handleFramePopEvent(). Instead, we would receive the > next SINGLE_STEP > > > event after cp resolution is complete, and we are > finally executing the > > > now resolved opc_new opcode. > > > > > > I'm hoping Serguei and/or Alex can also comment on this, > since I think > > > they were dealing with JvmtiHideSingleStepping() last > month. > > > > > > thanks, > > > > > > Chris > > > > > > > > > > > > On 1/17/19 6:08 PM, Daniil Titov wrote: > > > > Please review the change that fixes JDB stepping issue > for a specific case when the single step request was initiated earlier in > the stack, previous calls were for methods in the filtered classes (single > stepping was disabled), handleMethodEnterEvent() re-enabled stepping and > the first bytecode upon entering the current method requires resolving > constant pool entry. In this case the execution resumes in > java.lang.Classloader.loadClass() and since it is also a filtered class the > single stepping is getting disabled again (stepControl.c :593). When > loadClass() exits a notifyFramePop() is called on the loadClass() frame but > due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that > doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth > is 4) the notifyFramePop() fails to enable single stepping back. The fix > removes the excessive condition fromDepth >= afterPopDepth in > notifyFramePop() method (stepControl.c:346) to ensure that when a method > cal! > > > > led from the stepping frame (and during which we had > stepping disabled) has returned the stepping is re-enabled to continue > instructions steps in the original stepping frame. > > > > > > > > Webrev: > http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > > > > > Thanks! > > > > --Daniil > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue Jan 29 21:32:03 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Tue, 29 Jan 2019 13:32:03 -0800 Subject: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references In-Reply-To: References: <72D6EC06-48FD-4C0D-8C7B-DB51F8D8E359@oracle.com> <36e052be-5c46-2d51-efbd-b8fb76df4ffc@oracle.com> <4E44EBFF-FA65-40A2-BC3E-02ABC5D5814A@oracle.com> Message-ID: Thank you Chris and JC for reviewing this change. Best regards, Daniil From: Jean Christophe Beyler Date: Tuesday, January 29, 2019 at 12:09 PM To: Daniil Titov Cc: OpenJDK Serviceability , Chris Plummer Subject: Re: RFR 8163127: Debugger classExclusionFilter does not work correctly with method references Hi Daniil, I like this fix much better to be honest :) Jc On Tue, Jan 29, 2019 at 11:40 AM Daniil Titov wrote: Hi JC, Could you please say are you OK with this new version of the fix? Thanks! --Daniil ?On 1/26/19, 11:35 AM, "Chris Plummer" wrote: Looks good. thanks, Chris On 1/26/19 11:23 AM, Daniil Titov wrote: > Hi Chris, > > Please review a new version of the patch that moves the disabling of the single stepping into ConstantPool::klass_at_impl(). > > Mach5 jdk_jdi, vmTestbase_nsk_jdi, vmTestbase_nsk_jdb and serviceability tests, as well as all tier1,tier2 and tier3 tests successfully passed. > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.03/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > Thanks! > --Daniil > > ?On 1/24/19, 11:19 AM, "Chris Plummer" wrote: > > Hi Daniil, > > Thanks for the stack track. I was just about to send an email asking for > it when your new RFR arrived. > > The fix looks good. I think you also need to apply it here: > > InterpreterRuntime::ldc() > InterpreterRuntime::anewarray() > InterpreterRuntime::multianewarray() > InterpreterRuntime::quicken_io_cc() > > I wonder if it wouldn't be better if you moved the disabling into > ConstantPool::klass_at_impl() > > thanks, > > Chris > > On 1/24/19 10:38 AM, Daniil Titov wrote: > > Hi Chris and JC, > > > > Thank you for reviewing this change. Please review a new version of the fix that uses > > the approach Chris suggested ( disabling the single stepping during the class resolution). > > > > Just in case please find below the stack trace for this case when loadClass() method is entered. > > > > #0 SystemDictionary::load_instance_class(Symbol*, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:1502 > > #1 SystemDictionary::resolve_instance_class_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:853 > > #2 SystemDictionary::resolve_instance_class_or_null_helper(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:271 > > #3 SystemDictionary::resolve_or_null(Symbol*, Handle, Handle, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:254 > > #4 SystemDictionary::resolve_or_fail(Symbol*, Handle, Handle, bool, Thread*) at open/src/hotspot/share/classfile/systemDictionary.cpp:202 > > #5 ConstantPool::klass_at_impl(constantPoolHandle const&, int, bool, Thread*) at open/src/hotspot/share/oops/constantPool.cpp:483 > > #6 ConstantPool::klass_at(int, Thread*) at open/src/hotspot/share/oops/constantPool.hpp:382 > > #7 InterpreterRuntime::_new(JavaThread*, ConstantPool*, int) at open/src/hotspot/share/interpreter/interpreterRuntime.cpp:234 > > # 8 > > .... > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.02/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > Thanks, > > Daniil > > > > ?On 1/23/19, 3:53 PM, "Chris Plummer" wrote: > > > > Hi Daniil, > > > > I don't see an explanation for why fromDepth is 1 and afterPopDepth is 4. > > > > currentDepth = getThreadFrameCount(thread); > > fromDepth = step->fromStackDepth; > > afterPopDepth = currentDepth-1; > > > > step->fromStackDepth got setup when single stepping was first setup for > > this thread. There was also a notifyFramePop() done at this time, but I > > think that's just to catch exiting from the method you were single > > stepping in, and has no bearing in the case we are looking at here, > > where we area still some # of frames below where we user last issued a > > STEP_INTO. The FRAME_POP we are receiving now is not the one for when > > step->fromStackDepth was setup, but is for when we stepped into a > > filtered method. I think this is what the "fromDepth > afterPopDepth" > > check is for. I think the current logic is correct for intended handling > > of a FRAME_POP event. Although your fix is probably solving the problem, > > I get the feeling it is enabling single stepping too soon in many cases. > > That many not turn up as an error in any tests, but could cause > > debugging performance issues, or for the user to see spurious single > > step events that they were not expecting. > > > > I think the bug actually occurs long before we ever get to this point in > > the code (and we should in fact not be getting here). In my last entry > > in the bug I mentioned JvmtiHideSingleStepping(), and how it is used to > > turn off single stepping while we are doing invoke and field resolution, > > but doesn't seem to be used during class resolution, which is what we > > are doing here. If it where used, then the agent would never even see > > the SINGLE_STEP when loadClass() is entered, therefore no > > notifyFramePop() would be done, and we would not be relying on this code > > in handleFramePopEvent(). Instead, we would receive the next SINGLE_STEP > > event after cp resolution is complete, and we are finally executing the > > now resolved opc_new opcode. > > > > I'm hoping Serguei and/or Alex can also comment on this, since I think > > they were dealing with JvmtiHideSingleStepping() last month. > > > > thanks, > > > > Chris > > > > > > > > On 1/17/19 6:08 PM, Daniil Titov wrote: > > > Please review the change that fixes JDB stepping issue for a specific case when the single step request was initiated earlier in the stack, previous calls were for methods in the filtered classes (single stepping was disabled), handleMethodEnterEvent() re-enabled stepping and the first bytecode upon entering the current method requires resolving constant pool entry. In this case the execution resumes in java.lang.Classloader.loadClass() and since it is also a filtered class the single stepping is getting disabled again (stepControl.c :593). When loadClass() exits a notifyFramePop() is called on the loadClass() frame but due to condition fromDepth >= afterPopDepth at stepControl.c :346 (that doesn't hold in this case, in this case fromDepth is 1 and afterPopDepth is 4) the notifyFramePop() fails to enable single stepping back. The fix removes the excessive condition fromDepth >= afterPopDepth in notifyFramePop() method (stepControl.c:346) to ensure that when a method cal! > > > led from the stepping frame (and during which we had stepping disabled) has returned the stepping is re-enabled to continue instructions steps in the original stepping frame. > > > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8163127/webrev.01 > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8163127 > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Tue Jan 29 21:52:02 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Tue, 29 Jan 2019 16:52:02 -0500 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: <1032eb8d-e814-1af9-758e-45b05b638f22@oracle.com> References: <5C507AB7.8090809@oracle.com> <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> <5C5093A3.3010407@oracle.com> <1032eb8d-e814-1af9-758e-45b05b638f22@oracle.com> Message-ID: <4d415607-b8c4-1858-9f33-3ef66b178cc0@oracle.com> Issuing a "cont" in the second session does not work, because the threads are not suspended. It's interesting that the thread ids have all changed in the reconnected session. ... main[1] threads Group system: ? (java.lang.ref.Reference$ReferenceHandler)0x374 Reference Handler running ? (java.lang.ref.Finalizer$FinalizerThread)0x375 Finalizer???????? cond. waiting ? (java.lang.Thread)0x376???????????????????????? Signal Dispatcher running Group main: ? (java.lang.Thread)0x1 main????????????? running (at breakpoint) Group InnocuousThreadGroup: ? (jdk.internal.misc.InnocuousThread)0x377 Common-Cleaner??? cond. waiting main[1] exit ... > threads Group system: ? (java.lang.ref.Reference$ReferenceHandler)0x3b2 Reference Handler running ? (java.lang.ref.Finalizer$FinalizerThread)0x3b3 Finalizer???????? cond. waiting ? (java.lang.Thread)0x3b4???????????????????????? Signal Dispatcher running Group main: ? (java.lang.Thread)0x3b7 main????????????? running Group InnocuousThreadGroup: ? (jdk.internal.misc.InnocuousThread)0x3b8 Common-Cleaner??? cond. waiting > cont > Nothing suspended. On 1/29/19 2:27 PM, Chris Plummer wrote: > What is the state of the threads after the detach? If they are all > automatically resumed by the agent, then I think the unblocking should > be done by the same code that resumes the threads. If they are still > suspended, then why would we want to unblock when the next connection > comes in? It should be up to the debugger to detect that all threads > are suspended and act accordingly. > > Also, what happens if after attaching again you issue a "cont" command? > > Chris > > On 1/29/19 9:55 AM, Gary Adams wrote: >> As far as I can tell, the quit and exit commands are only handled >> locally >> on the debugger side of the connection. There is no packet sent to the >> libjdwp agentlib. >> >> On 1/29/19, 12:17 PM, Chris Plummer wrote: >>> Hi Gary, >>> >>> When the "exit" or "quit" is done, aren't all threads resumed at >>> that point, and shouldn't that result in the command loop being >>> unblocked? >>> >>> thanks, >>> >>> Chris >>> >>> On 1/29/19 8:09 AM, Gary Adams wrote: >>>> Significant protections are put in place to protect the commandLoop >>>> from multiple events that that have a suspend-all policy. The >>>> commandLoop uses a special block variable to ensure only >>>> a VirtualMachine or ThreadReference call to resume() will unblock >>>> the commandLoop. See >>>> >>>> ? src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>> >>>> In this particular bug report, the user was stopped at a breakpoint >>>> when they sent the "exit" command. The same effect can be produced >>>> with a "quit" command or any killing of the debugger process. >>>> >>>> When the second session is started the commandLoop is still blocked, >>>> so a new breakpoint will never be dequeued from the commandQueue. >>>> >>>> The proposed workaround will ensure the commandLoop is unblocked >>>> when a new session is started. >>>> >>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 >>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ >>>> >>>> All testing has been done by manually replicating the reported >>>> command sequences. I'll see if an existing breakpoint test can be >>>> enhanced to cover this scenario. >>> >>> >>> >> > > From chris.plummer at oracle.com Tue Jan 29 23:11:40 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 29 Jan 2019 15:11:40 -0800 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: <4d415607-b8c4-1858-9f33-3ef66b178cc0@oracle.com> References: <5C507AB7.8090809@oracle.com> <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> <5C5093A3.3010407@oracle.com> <1032eb8d-e814-1af9-758e-45b05b638f22@oracle.com> <4d415607-b8c4-1858-9f33-3ef66b178cc0@oracle.com> Message-ID: Ok, so you can't do a "cont" because threads are not suspended. That means someone resumed them. When/where was this done? Regarding threadIDs changing, my guess is that debugLoop_run() is re-entered when the new connection is established. This will result in commonRef_reset() being called, which invalidates all reference IDs, including threadIDs. So the first time the agent needs to send a threadID to the debugger, it needs to create a new one. Chris On 1/29/19 1:52 PM, gary.adams at oracle.com wrote: > Issuing a "cont" in the second session does not work, because > the threads are not suspended. > > It's interesting that the thread ids have all changed in > the reconnected session. > > ... > > main[1] threads > Group system: > ? (java.lang.ref.Reference$ReferenceHandler)0x374 Reference Handler > running > ? (java.lang.ref.Finalizer$FinalizerThread)0x375 Finalizer cond. waiting > ? (java.lang.Thread)0x376???????????????????????? Signal Dispatcher > running > Group main: > ? (java.lang.Thread)0x1 main????????????? running (at breakpoint) > Group InnocuousThreadGroup: > ? (jdk.internal.misc.InnocuousThread)0x377 Common-Cleaner??? cond. > waiting > main[1] exit > ... > > threads > Group system: > ? (java.lang.ref.Reference$ReferenceHandler)0x3b2 Reference Handler > running > ? (java.lang.ref.Finalizer$FinalizerThread)0x3b3 Finalizer cond. waiting > ? (java.lang.Thread)0x3b4???????????????????????? Signal Dispatcher > running > Group main: > ? (java.lang.Thread)0x3b7 main????????????? running > Group InnocuousThreadGroup: > ? (jdk.internal.misc.InnocuousThread)0x3b8 Common-Cleaner??? cond. > waiting > > cont > > Nothing suspended. > > > > > > > On 1/29/19 2:27 PM, Chris Plummer wrote: >> What is the state of the threads after the detach? If they are all >> automatically resumed by the agent, then I think the unblocking >> should be done by the same code that resumes the threads. If they are >> still suspended, then why would we want to unblock when the next >> connection comes in? It should be up to the debugger to detect that >> all threads are suspended and act accordingly. >> >> Also, what happens if after attaching again you issue a "cont" command? >> >> Chris >> >> On 1/29/19 9:55 AM, Gary Adams wrote: >>> As far as I can tell, the quit and exit commands are only handled >>> locally >>> on the debugger side of the connection. There is no packet sent to the >>> libjdwp agentlib. >>> >>> On 1/29/19, 12:17 PM, Chris Plummer wrote: >>>> Hi Gary, >>>> >>>> When the "exit" or "quit" is done, aren't all threads resumed at >>>> that point, and shouldn't that result in the command loop being >>>> unblocked? >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> On 1/29/19 8:09 AM, Gary Adams wrote: >>>>> Significant protections are put in place to protect the commandLoop >>>>> from multiple events that that have a suspend-all policy. The >>>>> commandLoop uses a special block variable to ensure only >>>>> a VirtualMachine or ThreadReference call to resume() will unblock >>>>> the commandLoop. See >>>>> >>>>> ? src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>> >>>>> In this particular bug report, the user was stopped at a breakpoint >>>>> when they sent the "exit" command. The same effect can be produced >>>>> with a "quit" command or any killing of the debugger process. >>>>> >>>>> When the second session is started the commandLoop is still blocked, >>>>> so a new breakpoint will never be dequeued from the commandQueue. >>>>> >>>>> The proposed workaround will ensure the commandLoop is unblocked >>>>> when a new session is started. >>>>> >>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 >>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ >>>>> >>>>> All testing has been done by manually replicating the reported >>>>> command sequences. I'll see if an existing breakpoint test can be >>>>> enhanced to cover this scenario. >>>> >>>> >>>> >>> >> >> > From dean.long at oracle.com Wed Jan 30 02:32:06 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 29 Jan 2019 18:32:06 -0800 Subject: 12 RFR(M) 8195635: [Graal] nsk/jvmti/unit/ForceEarlyReturn/earlyretbase crashes with assertion "compilation level out of bounds" In-Reply-To: <9b4a4594-458e-ae18-0606-9b1ecbb400ce@oracle.com> References: <9b4a4594-458e-ae18-0606-9b1ecbb400ce@oracle.com> Message-ID: I'm withdrawing this RFR for 12. dl On 1/28/19 5:13 PM, dean.long at oracle.com wrote: > http://cr.openjdk.java.net/~dlong/8195635/webrev.5/ > https://bugs.openjdk.java.net/browse/JDK-8195635 > > Please see the bug report for all the gory details.? Here's the short > version: > > If we allow any safepoint to be a suspend point, we run into trouble > with PopFrame and ForceEarlyReturn, which reasonably expect the top > frame not to change between the suspend and when the > PopFrame/ForceEarlyReturn is executed.? Normally this is not an issue, > but certain safepoints cause problems, when we are about to call a new > Java method.? In particular, if we safepoint and suspend in > JavaCallWrapper, the top frame will still be the caller, but when we > execute the PopFrame/ForceEarlyReturn we will be in the callee. > > The solution this patch takes is to block suspend around troublesome > VM code using a new "allow_suspend" thread flag.? This means > JavaThread::java_suspend can't just ask the VMThread to safepoint and > be done.? Instead it has wait and allow threads to roll forward to an > allowed suspend point. > > dl From zanglin5 at jd.com Wed Jan 30 08:17:08 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Wed, 30 Jan 2019 08:17:08 +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>, Message-ID: 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.griffiths at gmail.com Wed Jan 30 10:00:11 2019 From: david.griffiths at gmail.com (David Griffiths) Date: Wed, 30 Jan 2019 10:00:11 +0000 Subject: Is RegisterMap updated? In-Reply-To: References: Message-ID: 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? 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? Cheers, David On Tue, 29 Jan 2019 at 13:41, Andrew Haley wrote: > > On 1/29/19 11:24 AM, David Griffiths wrote: > > Hi, in CompiledVFrame.createStackValue there is the following code: > > > > // First find address of value > > Address valueAddr = loc.isRegister() > > // Value was in a callee-save register > > ? getRegisterMap().getLocation(new VMReg(loc.getRegisterNumber())) > > // Else value was directly saved on the stack. The frame's > > original stack pointer, > > // before any extension by its callee (due to Compiler1 > > linkage on SPARC), must be used. > > : ((Address)fr.getUnextendedSP()).addOffsetTo(loc.getStackOffset()); > > > > It appears from what I can make out that for the register case the map > > is not updated and so valueAddr is null. The only thing I can see that > > calls setLocation is updateMapWithSavedLink. Seems like it should be > > possible to return the register value for the frame at the top of the > > stack though? > > It could be, but we don't do that. The registers in the map are those > pushed onto the stack by generated Java code. > > -- > 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 Wed Jan 30 10:38:42 2019 From: aph at redhat.com (Andrew Haley) Date: Wed, 30 Jan 2019 10:38:42 +0000 Subject: Is RegisterMap updated? In-Reply-To: References: Message-ID: <21e8d6ff-41fa-10d6-813b-4d079196d34b@redhat.com> 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 jini.george at oracle.com Wed Jan 30 11:59:03 2019 From: jini.george at oracle.com (Jini George) Date: Wed, 30 Jan 2019 17:29:03 +0530 Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers Message-ID: 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 gary.adams at oracle.com Wed Jan 30 16:24:34 2019 From: gary.adams at oracle.com (Gary Adams) Date: Wed, 30 Jan 2019 11:24:34 -0500 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: References: <5C507AB7.8090809@oracle.com> <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> <5C5093A3.3010407@oracle.com> <1032eb8d-e814-1af9-758e-45b05b638f22@oracle.com> <4d415607-b8c4-1858-9f33-3ef66b178cc0@oracle.com> Message-ID: <5C51CFC2.4000006@oracle.com> Following the trail from debugLoop_run, at the bottom of the loop there is a path through debugInit_reset that involves eventHandler_reset and eventually eventHelper_reset. This seems like a better place to clear the flag back to original state. Revised webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.01/ On 1/29/19, 6:11 PM, Chris Plummer wrote: > Ok, so you can't do a "cont" because threads are not suspended. That > means someone resumed them. When/where was this done? > > Regarding threadIDs changing, my guess is that debugLoop_run() is > re-entered when the new connection is established. This will result in > commonRef_reset() being called, which invalidates all reference IDs, > including threadIDs. So the first time the agent needs to send a > threadID to the debugger, it needs to create a new one. > > Chris > > On 1/29/19 1:52 PM, gary.adams at oracle.com wrote: >> Issuing a "cont" in the second session does not work, because >> the threads are not suspended. >> >> It's interesting that the thread ids have all changed in >> the reconnected session. >> >> ... >> >> main[1] threads >> Group system: >> (java.lang.ref.Reference$ReferenceHandler)0x374 Reference Handler >> running >> (java.lang.ref.Finalizer$FinalizerThread)0x375 Finalizer cond. waiting >> (java.lang.Thread)0x376 Signal Dispatcher >> running >> Group main: >> (java.lang.Thread)0x1 main running (at breakpoint) >> Group InnocuousThreadGroup: >> (jdk.internal.misc.InnocuousThread)0x377 Common-Cleaner cond. >> waiting >> main[1] exit >> ... >> > threads >> Group system: >> (java.lang.ref.Reference$ReferenceHandler)0x3b2 Reference Handler >> running >> (java.lang.ref.Finalizer$FinalizerThread)0x3b3 Finalizer cond. waiting >> (java.lang.Thread)0x3b4 Signal Dispatcher >> running >> Group main: >> (java.lang.Thread)0x3b7 main running >> Group InnocuousThreadGroup: >> (jdk.internal.misc.InnocuousThread)0x3b8 Common-Cleaner cond. >> waiting >> > cont >> > Nothing suspended. >> >> >> >> >> >> >> On 1/29/19 2:27 PM, Chris Plummer wrote: >>> What is the state of the threads after the detach? If they are all >>> automatically resumed by the agent, then I think the unblocking >>> should be done by the same code that resumes the threads. If they >>> are still suspended, then why would we want to unblock when the next >>> connection comes in? It should be up to the debugger to detect that >>> all threads are suspended and act accordingly. >>> >>> Also, what happens if after attaching again you issue a "cont" command? >>> >>> Chris >>> >>> On 1/29/19 9:55 AM, Gary Adams wrote: >>>> As far as I can tell, the quit and exit commands are only handled >>>> locally >>>> on the debugger side of the connection. There is no packet sent to the >>>> libjdwp agentlib. >>>> >>>> On 1/29/19, 12:17 PM, Chris Plummer wrote: >>>>> Hi Gary, >>>>> >>>>> When the "exit" or "quit" is done, aren't all threads resumed at >>>>> that point, and shouldn't that result in the command loop being >>>>> unblocked? >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> On 1/29/19 8:09 AM, Gary Adams wrote: >>>>>> Significant protections are put in place to protect the commandLoop >>>>>> from multiple events that that have a suspend-all policy. The >>>>>> commandLoop uses a special block variable to ensure only >>>>>> a VirtualMachine or ThreadReference call to resume() will unblock >>>>>> the commandLoop. See >>>>>> >>>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>>> >>>>>> In this particular bug report, the user was stopped at a breakpoint >>>>>> when they sent the "exit" command. The same effect can be produced >>>>>> with a "quit" command or any killing of the debugger process. >>>>>> >>>>>> When the second session is started the commandLoop is still blocked, >>>>>> so a new breakpoint will never be dequeued from the commandQueue. >>>>>> >>>>>> The proposed workaround will ensure the commandLoop is unblocked >>>>>> when a new session is started. >>>>>> >>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 >>>>>> Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ >>>>>> >>>>>> All testing has been done by manually replicating the reported >>>>>> command sequences. I'll see if an existing breakpoint test can be >>>>>> enhanced to cover this scenario. >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From hohensee at amazon.com Wed Jan 30 17:30:17 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 30 Jan 2019 17:30:17 +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> Message-ID: <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.com> 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 chris.plummer at oracle.com Wed Jan 30 18:57:41 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 30 Jan 2019 10:57:41 -0800 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: <5C51CFC2.4000006@oracle.com> References: <5C507AB7.8090809@oracle.com> <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> <5C5093A3.3010407@oracle.com> <1032eb8d-e814-1af9-758e-45b05b638f22@oracle.com> <4d415607-b8c4-1858-9f33-3ef66b178cc0@oracle.com> <5C51CFC2.4000006@oracle.com> Message-ID: <66922bf7-2342-7688-95d9-cf7ad56950d4@oracle.com> This looks good. thanks, Chris On 1/30/19 8:24 AM, Gary Adams wrote: > Following the trail from debugLoop_run, at the bottom of the loop > there is a path through debugInit_reset that involves eventHandler_reset > and eventually eventHelper_reset. This seems like a better place to > clear the flag back to original state. > > ? Revised webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.01/ > > On 1/29/19, 6:11 PM, Chris Plummer wrote: >> Ok, so you can't do a "cont" because threads are not suspended. That >> means someone resumed them. When/where was this done? >> >> Regarding threadIDs changing, my guess is that debugLoop_run() is >> re-entered when the new connection is established. This will result >> in commonRef_reset() being called, which invalidates all reference >> IDs, including threadIDs. So the first time the agent needs to send a >> threadID to the debugger, it needs to create a new one. >> >> Chris >> >> On 1/29/19 1:52 PM, gary.adams at oracle.com wrote: >>> Issuing a "cont" in the second session does not work, because >>> the threads are not suspended. >>> >>> It's interesting that the thread ids have all changed in >>> the reconnected session. >>> >>> ... >>> >>> main[1] threads >>> Group system: >>> ? (java.lang.ref.Reference$ReferenceHandler)0x374 Reference Handler >>> running >>> ? (java.lang.ref.Finalizer$FinalizerThread)0x375 Finalizer cond. >>> waiting >>> ? (java.lang.Thread)0x376???????????????????????? Signal Dispatcher >>> running >>> Group main: >>> ? (java.lang.Thread)0x1 main????????????? running (at breakpoint) >>> Group InnocuousThreadGroup: >>> ? (jdk.internal.misc.InnocuousThread)0x377 Common-Cleaner cond. waiting >>> main[1] exit >>> ... >>> > threads >>> Group system: >>> ? (java.lang.ref.Reference$ReferenceHandler)0x3b2 Reference Handler >>> running >>> ? (java.lang.ref.Finalizer$FinalizerThread)0x3b3 Finalizer cond. >>> waiting >>> ? (java.lang.Thread)0x3b4???????????????????????? Signal Dispatcher >>> running >>> Group main: >>> ? (java.lang.Thread)0x3b7 main????????????? running >>> Group InnocuousThreadGroup: >>> ? (jdk.internal.misc.InnocuousThread)0x3b8 Common-Cleaner cond. waiting >>> > cont >>> > Nothing suspended. >>> >>> >>> >>> >>> >>> >>> On 1/29/19 2:27 PM, Chris Plummer wrote: >>>> What is the state of the threads after the detach? If they are all >>>> automatically resumed by the agent, then I think the unblocking >>>> should be done by the same code that resumes the threads. If they >>>> are still suspended, then why would we want to unblock when the >>>> next connection comes in? It should be up to the debugger to detect >>>> that all threads are suspended and act accordingly. >>>> >>>> Also, what happens if after attaching again you issue a "cont" >>>> command? >>>> >>>> Chris >>>> >>>> On 1/29/19 9:55 AM, Gary Adams wrote: >>>>> As far as I can tell, the quit and exit commands are only handled >>>>> locally >>>>> on the debugger side of the connection. There is no packet sent to >>>>> the >>>>> libjdwp agentlib. >>>>> >>>>> On 1/29/19, 12:17 PM, Chris Plummer wrote: >>>>>> Hi Gary, >>>>>> >>>>>> When the "exit" or "quit" is done, aren't all threads resumed at >>>>>> that point, and shouldn't that result in the command loop being >>>>>> unblocked? >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 1/29/19 8:09 AM, Gary Adams wrote: >>>>>>> Significant protections are put in place to protect the commandLoop >>>>>>> from multiple events that that have a suspend-all policy. The >>>>>>> commandLoop uses a special block variable to ensure only >>>>>>> a VirtualMachine or ThreadReference call to resume() will unblock >>>>>>> the commandLoop. See >>>>>>> >>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>>>> >>>>>>> In this particular bug report, the user was stopped at a breakpoint >>>>>>> when they sent the "exit" command. The same effect can be produced >>>>>>> with a "quit" command or any killing of the debugger process. >>>>>>> >>>>>>> When the second session is started the commandLoop is still >>>>>>> blocked, >>>>>>> so a new breakpoint will never be dequeued from the commandQueue. >>>>>>> >>>>>>> The proposed workaround will ensure the commandLoop is unblocked >>>>>>> when a new session is started. >>>>>>> >>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 >>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ >>>>>>> >>>>>>> All testing has been done by manually replicating the reported >>>>>>> command sequences. I'll see if an existing breakpoint test can be >>>>>>> enhanced to cover this scenario. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From gary.adams at oracle.com Wed Jan 30 23:03:36 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Wed, 30 Jan 2019 18:03:36 -0500 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: <66922bf7-2342-7688-95d9-cf7ad56950d4@oracle.com> References: <5C507AB7.8090809@oracle.com> <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> <5C5093A3.3010407@oracle.com> <1032eb8d-e814-1af9-758e-45b05b638f22@oracle.com> <4d415607-b8c4-1858-9f33-3ef66b178cc0@oracle.com> <5C51CFC2.4000006@oracle.com> <66922bf7-2342-7688-95d9-cf7ad56950d4@oracle.com> Message-ID: <1254325e-450a-90b5-f67b-6c0ef5e297ea@oracle.com> Second reviewer or is it trivial enough for one? On 1/30/19 1:57 PM, Chris Plummer wrote: > This looks good. > > thanks, > > Chris > > On 1/30/19 8:24 AM, Gary Adams wrote: >> Following the trail from debugLoop_run, at the bottom of the loop >> there is a path through debugInit_reset that involves eventHandler_reset >> and eventually eventHelper_reset. This seems like a better place to >> clear the flag back to original state. >> >> ? Revised webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.01/ >> >> On 1/29/19, 6:11 PM, Chris Plummer wrote: >>> Ok, so you can't do a "cont" because threads are not suspended. That >>> means someone resumed them. When/where was this done? >>> >>> Regarding threadIDs changing, my guess is that debugLoop_run() is >>> re-entered when the new connection is established. This will result >>> in commonRef_reset() being called, which invalidates all reference >>> IDs, including threadIDs. So the first time the agent needs to send >>> a threadID to the debugger, it needs to create a new one. >>> >>> Chris >>> >>> On 1/29/19 1:52 PM, gary.adams at oracle.com wrote: >>>> Issuing a "cont" in the second session does not work, because >>>> the threads are not suspended. >>>> >>>> It's interesting that the thread ids have all changed in >>>> the reconnected session. >>>> >>>> ... >>>> >>>> main[1] threads >>>> Group system: >>>> ? (java.lang.ref.Reference$ReferenceHandler)0x374 Reference Handler >>>> running >>>> ? (java.lang.ref.Finalizer$FinalizerThread)0x375 Finalizer cond. >>>> waiting >>>> ? (java.lang.Thread)0x376???????????????????????? Signal Dispatcher >>>> running >>>> Group main: >>>> ? (java.lang.Thread)0x1 main????????????? running (at breakpoint) >>>> Group InnocuousThreadGroup: >>>> ? (jdk.internal.misc.InnocuousThread)0x377 Common-Cleaner cond. >>>> waiting >>>> main[1] exit >>>> ... >>>> > threads >>>> Group system: >>>> ? (java.lang.ref.Reference$ReferenceHandler)0x3b2 Reference Handler >>>> running >>>> ? (java.lang.ref.Finalizer$FinalizerThread)0x3b3 Finalizer cond. >>>> waiting >>>> ? (java.lang.Thread)0x3b4???????????????????????? Signal Dispatcher >>>> running >>>> Group main: >>>> ? (java.lang.Thread)0x3b7 main????????????? running >>>> Group InnocuousThreadGroup: >>>> ? (jdk.internal.misc.InnocuousThread)0x3b8 Common-Cleaner cond. >>>> waiting >>>> > cont >>>> > Nothing suspended. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 1/29/19 2:27 PM, Chris Plummer wrote: >>>>> What is the state of the threads after the detach? If they are all >>>>> automatically resumed by the agent, then I think the unblocking >>>>> should be done by the same code that resumes the threads. If they >>>>> are still suspended, then why would we want to unblock when the >>>>> next connection comes in? It should be up to the debugger to >>>>> detect that all threads are suspended and act accordingly. >>>>> >>>>> Also, what happens if after attaching again you issue a "cont" >>>>> command? >>>>> >>>>> Chris >>>>> >>>>> On 1/29/19 9:55 AM, Gary Adams wrote: >>>>>> As far as I can tell, the quit and exit commands are only handled >>>>>> locally >>>>>> on the debugger side of the connection. There is no packet sent >>>>>> to the >>>>>> libjdwp agentlib. >>>>>> >>>>>> On 1/29/19, 12:17 PM, Chris Plummer wrote: >>>>>>> Hi Gary, >>>>>>> >>>>>>> When the "exit" or "quit" is done, aren't all threads resumed at >>>>>>> that point, and shouldn't that result in the command loop being >>>>>>> unblocked? >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 1/29/19 8:09 AM, Gary Adams wrote: >>>>>>>> Significant protections are put in place to protect the >>>>>>>> commandLoop >>>>>>>> from multiple events that that have a suspend-all policy. The >>>>>>>> commandLoop uses a special block variable to ensure only >>>>>>>> a VirtualMachine or ThreadReference call to resume() will unblock >>>>>>>> the commandLoop. See >>>>>>>> >>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>>>>> >>>>>>>> In this particular bug report, the user was stopped at a >>>>>>>> breakpoint >>>>>>>> when they sent the "exit" command. The same effect can be produced >>>>>>>> with a "quit" command or any killing of the debugger process. >>>>>>>> >>>>>>>> When the second session is started the commandLoop is still >>>>>>>> blocked, >>>>>>>> so a new breakpoint will never be dequeued from the commandQueue. >>>>>>>> >>>>>>>> The proposed workaround will ensure the commandLoop is unblocked >>>>>>>> when a new session is started. >>>>>>>> >>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 >>>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ >>>>>>>> >>>>>>>> All testing has been done by manually replicating the reported >>>>>>>> command sequences. I'll see if an existing breakpoint test can be >>>>>>>> enhanced to cover this scenario. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From serguei.spitsyn at oracle.com Wed Jan 30 23:12:20 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2019 15:12:20 -0800 Subject: RFR: JDK-8215550: Debugger does not work after reattach In-Reply-To: <1254325e-450a-90b5-f67b-6c0ef5e297ea@oracle.com> References: <5C507AB7.8090809@oracle.com> <49f06117-d654-b1cd-b4da-40d668beaeda@oracle.com> <5C5093A3.3010407@oracle.com> <1032eb8d-e814-1af9-758e-45b05b638f22@oracle.com> <4d415607-b8c4-1858-9f33-3ef66b178cc0@oracle.com> <5C51CFC2.4000006@oracle.com> <66922bf7-2342-7688-95d9-cf7ad56950d4@oracle.com> <1254325e-450a-90b5-f67b-6c0ef5e297ea@oracle.com> Message-ID: Hi Gary, It looks good to me. Nice discovery! Thanks, Serguei On 1/30/19 15:03, gary.adams at oracle.com wrote: > Second reviewer or is it trivial enough for one? > > On 1/30/19 1:57 PM, Chris Plummer wrote: >> This looks good. >> >> thanks, >> >> Chris >> >> On 1/30/19 8:24 AM, Gary Adams wrote: >>> Following the trail from debugLoop_run, at the bottom of the loop >>> there is a path through debugInit_reset that involves >>> eventHandler_reset >>> and eventually eventHelper_reset. This seems like a better place to >>> clear the flag back to original state. >>> >>> ? Revised webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.01/ >>> >>> On 1/29/19, 6:11 PM, Chris Plummer wrote: >>>> Ok, so you can't do a "cont" because threads are not suspended. >>>> That means someone resumed them. When/where was this done? >>>> >>>> Regarding threadIDs changing, my guess is that debugLoop_run() is >>>> re-entered when the new connection is established. This will result >>>> in commonRef_reset() being called, which invalidates all reference >>>> IDs, including threadIDs. So the first time the agent needs to send >>>> a threadID to the debugger, it needs to create a new one. >>>> >>>> Chris >>>> >>>> On 1/29/19 1:52 PM, gary.adams at oracle.com wrote: >>>>> Issuing a "cont" in the second session does not work, because >>>>> the threads are not suspended. >>>>> >>>>> It's interesting that the thread ids have all changed in >>>>> the reconnected session. >>>>> >>>>> ... >>>>> >>>>> main[1] threads >>>>> Group system: >>>>> ? (java.lang.ref.Reference$ReferenceHandler)0x374 Reference >>>>> Handler running >>>>> ? (java.lang.ref.Finalizer$FinalizerThread)0x375 Finalizer cond. >>>>> waiting >>>>> ? (java.lang.Thread)0x376???????????????????????? Signal >>>>> Dispatcher running >>>>> Group main: >>>>> ? (java.lang.Thread)0x1 main????????????? running (at breakpoint) >>>>> Group InnocuousThreadGroup: >>>>> ? (jdk.internal.misc.InnocuousThread)0x377 Common-Cleaner cond. >>>>> waiting >>>>> main[1] exit >>>>> ... >>>>> > threads >>>>> Group system: >>>>> ? (java.lang.ref.Reference$ReferenceHandler)0x3b2 Reference >>>>> Handler running >>>>> ? (java.lang.ref.Finalizer$FinalizerThread)0x3b3 Finalizer cond. >>>>> waiting >>>>> ? (java.lang.Thread)0x3b4???????????????????????? Signal >>>>> Dispatcher running >>>>> Group main: >>>>> ? (java.lang.Thread)0x3b7 main????????????? running >>>>> Group InnocuousThreadGroup: >>>>> ? (jdk.internal.misc.InnocuousThread)0x3b8 Common-Cleaner cond. >>>>> waiting >>>>> > cont >>>>> > Nothing suspended. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 1/29/19 2:27 PM, Chris Plummer wrote: >>>>>> What is the state of the threads after the detach? If they are >>>>>> all automatically resumed by the agent, then I think the >>>>>> unblocking should be done by the same code that resumes the >>>>>> threads. If they are still suspended, then why would we want to >>>>>> unblock when the next connection comes in? It should be up to the >>>>>> debugger to detect that all threads are suspended and act >>>>>> accordingly. >>>>>> >>>>>> Also, what happens if after attaching again you issue a "cont" >>>>>> command? >>>>>> >>>>>> Chris >>>>>> >>>>>> On 1/29/19 9:55 AM, Gary Adams wrote: >>>>>>> As far as I can tell, the quit and exit commands are only >>>>>>> handled locally >>>>>>> on the debugger side of the connection. There is no packet sent >>>>>>> to the >>>>>>> libjdwp agentlib. >>>>>>> >>>>>>> On 1/29/19, 12:17 PM, Chris Plummer wrote: >>>>>>>> Hi Gary, >>>>>>>> >>>>>>>> When the "exit" or "quit" is done, aren't all threads resumed >>>>>>>> at that point, and shouldn't that result in the command loop >>>>>>>> being unblocked? >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 1/29/19 8:09 AM, Gary Adams wrote: >>>>>>>>> Significant protections are put in place to protect the >>>>>>>>> commandLoop >>>>>>>>> from multiple events that that have a suspend-all policy. The >>>>>>>>> commandLoop uses a special block variable to ensure only >>>>>>>>> a VirtualMachine or ThreadReference call to resume() will unblock >>>>>>>>> the commandLoop. See >>>>>>>>> >>>>>>>>> src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c >>>>>>>>> >>>>>>>>> In this particular bug report, the user was stopped at a >>>>>>>>> breakpoint >>>>>>>>> when they sent the "exit" command. The same effect can be >>>>>>>>> produced >>>>>>>>> with a "quit" command or any killing of the debugger process. >>>>>>>>> >>>>>>>>> When the second session is started the commandLoop is still >>>>>>>>> blocked, >>>>>>>>> so a new breakpoint will never be dequeued from the commandQueue. >>>>>>>>> >>>>>>>>> The proposed workaround will ensure the commandLoop is unblocked >>>>>>>>> when a new session is started. >>>>>>>>> >>>>>>>>> ? Issue: https://bugs.openjdk.java.net/browse/JDK-8215550 >>>>>>>>> ? Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/ >>>>>>>>> >>>>>>>>> All testing has been done by manually replicating the reported >>>>>>>>> command sequences. I'll see if an existing breakpoint test can be >>>>>>>>> enhanced to cover this scenario. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From hohensee at amazon.com Thu Jan 31 00:41:30 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 31 Jan 2019 00:41:30 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <84F07D0D-F5C2-4B65-8BB6-6F7F58DB6AAC@amazon.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> Message-ID: <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.com> Also, I suspect that this change needs a CSR, since we're adding functionality to jmap's histo switch. Opinions? 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 Thu Jan 31 01:19:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 11:19:31 +1000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <97AB0547-6DDB-42C7-8172-8F80604D039A@amazon.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> Message-ID: <8c781c47-dd03-cc15-95cf-76b656fb0ff3@oracle.com> 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 alexey.menkov at oracle.com Thu Jan 31 01:27:35 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 30 Jan 2019 17:27:35 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal Message-ID: <6daa70b3-d10c-afea-b775-12e52d7e2d58@oracle.com> Hi all, Please review a fix for tck-red bug: https://bugs.openjdk.java.net/browse/JDK-8218025 webrev: http://cr.openjdk.java.net/~amenkov/tck_red_disable_caps/webrev/ ForceEarlyReturn and PopFrame JCK tests intermittently fail with Graal. Real fix for the issue is too risky for jdk12, so we have to disable pop_frame and force_early_return capabilities running with Graal (the capabilities are optional). Currently Graal is the only compiler, so the fix checks if JVMCI compiler is enabled. JCK test passes with disabled capabilities. A number of hotspot tests do not check if the capabilities are enabled (as hotspot is expected to support all capabilities) and fail with Graal - they are problem-listed until the real problem (JDK-8195635) is resolved. --alex From igor.ignatyev at oracle.com Thu Jan 31 01:34:37 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 30 Jan 2019 17:34:37 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <6daa70b3-d10c-afea-b775-12e52d7e2d58@oracle.com> References: <6daa70b3-d10c-afea-b775-12e52d7e2d58@oracle.com> Message-ID: <919AB047-1F67-45BB-80DD-205672FFE49F@oracle.com> Hi Alex, UseJVMCICompiler is declared only if INCLUDE_JVMCI is defined, so your current patch will break builds where it's undefined. the rest (esp. problem list ;) ) looks good to me. adding hotspot-compiler alias. Thanks, -- Igor > On Jan 30, 2019, at 5:27 PM, Alex Menkov wrote: > > Hi all, > > Please review a fix for tck-red bug: > https://bugs.openjdk.java.net/browse/JDK-8218025 > webrev: > http://cr.openjdk.java.net/~amenkov/tck_red_disable_caps/webrev/ > > ForceEarlyReturn and PopFrame JCK tests intermittently fail with Graal. > Real fix for the issue is too risky for jdk12, so we have to disable pop_frame and force_early_return capabilities running with Graal (the capabilities are optional). > Currently Graal is the only compiler, so the fix checks if JVMCI compiler is enabled. > JCK test passes with disabled capabilities. > A number of hotspot tests do not check if the capabilities are enabled (as hotspot is expected to support all capabilities) and fail with Graal - they are problem-listed until the real problem (JDK-8195635) is resolved. > > --alex From david.holmes at oracle.com Thu Jan 31 02:15:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 12:15:04 +1000 Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: References: Message-ID: <1b6d4030-4980-7fd0-7784-72987239647a@oracle.com> 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. > From jini.george at oracle.com Thu Jan 31 04:36:05 2019 From: jini.george at oracle.com (Jini George) Date: Thu, 31 Jan 2019 10:06:05 +0530 Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: <1b6d4030-4980-7fd0-7784-72987239647a@oracle.com> References: <1b6d4030-4980-7fd0-7784-72987239647a@oracle.com> Message-ID: 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. >> From serguei.spitsyn at oracle.com Thu Jan 31 04:46:53 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2019 20:46:53 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <919AB047-1F67-45BB-80DD-205672FFE49F@oracle.com> References: <6daa70b3-d10c-afea-b775-12e52d7e2d58@oracle.com> <919AB047-1F67-45BB-80DD-205672FFE49F@oracle.com> Message-ID: <9069d34b-ad8e-17ce-c5f4-8765730d6497@oracle.com> Hi Alex, Vladimir I. also mentioned the same as Igor. One example from the runtime/thread.cpp: #if INCLUDE_JVMCI ? bool force_JVMCI_intialization = false; ? if (EnableJVMCI) { ??? // Initialize JVMCI eagerly when it is explicitly requested. ??? // Or when JVMCIPrintProperties is enabled. ??? // The JVMCI Java initialization code will read this flag and ??? // do the printing if it's set. ??? force_JVMCI_intialization = EagerJVMCI || JVMCIPrintProperties; ??? if (!force_JVMCI_intialization) { ????? // 8145270: Force initialization of JVMCI runtime otherwise requests for blocking ????? // compilations via JVMCI will not actually block until JVMCI is initialized. ????? force_JVMCI_intialization = UseJVMCICompiler && (!UseInterpreter || !BackgroundCompilation); ??? } ? } #endif One more example from prims/jni.cpp: #if INCLUDE_JVMCI ??? if (EnableJVMCI) { ????? if (UseJVMCICompiler) { ??????? . . . ????? } ??? } #endif On 1/30/19 17:34, Igor Ignatyev wrote: > Hi Alex, > > UseJVMCICompiler is declared only if INCLUDE_JVMCI is defined, so your current patch will break builds where it's undefined. the rest (esp. problem list ;) ) looks good to me. > > adding hotspot-compiler alias. > > Thanks, > -- Igor > >> On Jan 30, 2019, at 5:27 PM, Alex Menkov wrote: >> >> Hi all, >> >> Please review a fix for tck-red bug: >> https://bugs.openjdk.java.net/browse/JDK-8218025 >> webrev: >> http://cr.openjdk.java.net/~amenkov/tck_red_disable_caps/webrev/ >> >> ForceEarlyReturn and PopFrame JCK tests intermittently fail with Graal. >> Real fix for the issue is too risky for jdk12, so we have to disable pop_frame and force_early_return capabilities running with Graal (the capabilities are optional). >> Currently Graal is the only compiler, so the fix checks if JVMCI compiler is enabled. >> JCK test passes with disabled capabilities. >> A number of hotspot tests do not check if the capabilities are enabled (as hotspot is expected to support all capabilities) and fail with Graal - they are problem-listed until the real problem (JDK-8195635) is resolved. >> >> --alex From serguei.spitsyn at oracle.com Thu Jan 31 04:59:55 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2019 20:59:55 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <9069d34b-ad8e-17ce-c5f4-8765730d6497@oracle.com> References: <6daa70b3-d10c-afea-b775-12e52d7e2d58@oracle.com> <919AB047-1F67-45BB-80DD-205672FFE49F@oracle.com> <9069d34b-ad8e-17ce-c5f4-8765730d6497@oracle.com> Message-ID: <7afec9a8-602c-9d5b-f899-b806595ad859@oracle.com> An HTML attachment was scrubbed... URL: From dean.long at oracle.com Thu Jan 31 05:18:05 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 30 Jan 2019 21:18:05 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <7afec9a8-602c-9d5b-f899-b806595ad859@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> Message-ID: <6e609bd6-ef09-3323-9225-255a0e750aa3@oracle.com> 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)) { ... } dl -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Thu Jan 31 05:22:45 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 30 Jan 2019 21:22:45 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <6e609bd6-ef09-3323-9225-255a0e750aa3@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> Message-ID: <690A8E3B-1B24-4193-9B93-F21B687FE57B@oracle.com> from my point of view, having the following code at the end of JvmtiManageCapabilities::init_onload_capabilities is much clear and easier to understand: > // Workaround for 8195635: disable pop_frame and force_early_return capabilities > #if INCLUDE_JVMCI > if (UseJVMCICompiler) { > jc.can_pop_frame = 0; > jc.can_force_early_return = 0; > } > #endif // INCLUDE_JVMCI Thanks, -- Igor > On Jan 30, 2019, at 9: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)) { > ... > } > > dl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Jan 31 05:24:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 15:24:37 +1000 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <6e609bd6-ef09-3323-9225-255a0e750aa3@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> Message-ID: <95ed0aa0-7d8c-b448-fd0d-c25b930cafcb@oracle.com> 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 David > dl > From serguei.spitsyn at oracle.com Thu Jan 31 05:31:39 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2019 21:31:39 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <95ed0aa0-7d8c-b448-fd0d-c25b930cafcb@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> Message-ID: <148c8531-6f2b-142d-cae0-a4d5bc2de970@oracle.com> 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 serguei.spitsyn at oracle.com Thu Jan 31 05:52:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2019 21:52:51 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <690A8E3B-1B24-4193-9B93-F21B687FE57B@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> <690A8E3B-1B24-4193-9B93-F21B687FE57B@oracle.com> Message-ID: <9abeb866-43a5-cec9-27be-cae0642d5835@oracle.com> An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Thu Jan 31 06:42:33 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Thu, 31 Jan 2019 06:42:33 +0000 Subject: [RFR]8215622: Add dump to file support for jmap histo In-Reply-To: <8c781c47-dd03-cc15-95cf-76b656fb0ff3@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> Message-ID: <4c797f80a87748c5bb260ea5715be75e@jd.com> 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 Thu Jan 31 06:46:47 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Jan 2019 22:46:47 -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> Message-ID: Daniil and David, Just wanted to let you know that I'm reviewing this. 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 guess, the main David's concern is new file ? src/jdk.jcmd/linux/classes/sun/tools/ProcessHelper.java which includes introduced by Daniil command-line processing. Thanks, Serguei > > 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" 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" >> 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" >> 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 goetz.lindenmaier at sap.com Thu Jan 31 11:54:11 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 31 Jan 2019 11:54:11 +0000 Subject: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: References: Message-ID: <023938dc65604c7494719a7f3dc90810@sap.com> 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 goetz.lindenmaier at sap.com Thu Jan 31 13:17:12 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 31 Jan 2019 13:17:12 +0000 Subject: HotSpot Serviceability Agent (SA) Survey In-Reply-To: References: Message-ID: Hi, any news on this? We get questions for the results by the people I made participate in this :) Best regards, Goetz. > -----Original Message----- > From: serviceability-dev On > Behalf Of Stephen Fitch > Sent: Dienstag, 3. Juli 2018 14:18 > To: Per Liden ; serviceability-dev at openjdk.java.net > Subject: Re: HotSpot Serviceability Agent (SA) Survey > > Hi Per, > > Sadly delayed by other things; I'll put some further solid effort > into a published summary ASAP, ideally before the end of July, if > not before. > > It's not forgotten, but behind other priorities. > > Regards, > > ?Stephen > > On 7/3/18 1:47 AM, Per Liden wrote: > > Hi Stephen, > > > > On 03/21/2018 07:14 PM, Stephen Fitch wrote: > >> Hi, > >> > >> The HotSpot Serviceability Agent (SA) is a set of APIs and tools for > >> debugging HotSpot Virtual Machine and has been a part of the JVM/JDK for > a > >> long time, however we don't have a lot of data about how it is used in > >> practice, especially outside of Oracle. Therefore, we have created an initial > >> survey to gather more information and help us evaluate and understand > how > >> others are using it. > >> > >> If you have used, or have (support) processes that utilize the Serviceability > >> Agent or related APIs, then we would definitely appreciate if you would > >> complete this survey: > >> > >> https://www.surveymonkey.com/r/CF3MYDL > >> > >> We are specifically interested in your use-cases and how SA is effective for > >> you in resolving JVM issues. > >> > >> The survey will remain open through March 31st. The results of the survey > >> will be made public after the survey closes. > > > > Have the results been published yet? > > > > cheers, > > Per > > > >> > >> Regards, Stephen > >> > >> ??Java Platform Group - JVM - Sustaining Engineering From goetz.lindenmaier at sap.com Thu Jan 31 15:11:20 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 31 Jan 2019 15:11:20 +0000 Subject: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers In-Reply-To: <023938dc65604c7494719a7f3dc90810@sap.com> References: <023938dc65604c7494719a7f3dc90810@sap.com> Message-ID: ... 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 stephen.fitch at oracle.com Thu Jan 31 16:16:30 2019 From: stephen.fitch at oracle.com (Stephen Fitch) Date: Thu, 31 Jan 2019 08:16:30 -0800 Subject: HotSpot Serviceability Agent (SA) Survey In-Reply-To: References: Message-ID: <8e396c54-1c95-20c3-131f-0125ca71d551@oracle.com> Hi Goetz, I will sync with Raga, my fellow manager in this (SA) domain, and get more effort into getting the summary out ASAP. Apologies for the delay. Regards, ?Stephen -- On 1/31/19 05:17, Lindenmaier, Goetz wrote: > Hi, > > any news on this? > We get questions for the results by the people I made > participate in this :) > > Best regards, > Goetz. > From alexey.menkov at oracle.com Thu Jan 31 18:38:20 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 31 Jan 2019 10:38:20 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <148c8531-6f2b-142d-cae0-a4d5bc2de970@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> Message-ID: 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 igor.ignatyev at oracle.com Thu Jan 31 18:52:05 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 31 Jan 2019 10:52:05 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: 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> Message-ID: <3CD7BD6E-5FEE-4A0E-9A60-993B69DFA695@oracle.com> Hi Alex, you have 'if INCLUDE_JVMCI' inside 'ifndef ZERO', although we currently don't have zero builds w/ JVMCI (and I don't think such builds would make much sense), it's better not to rely on that. not a blocker from my point of view though. Thanks, -- Igor > On Jan 31, 2019, at 10:38 AM, 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 alexey.menkov at oracle.com Thu Jan 31 18:59:46 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 31 Jan 2019 10:59:46 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <3CD7BD6E-5FEE-4A0E-9A60-993B69DFA695@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> <3CD7BD6E-5FEE-4A0E-9A60-993B69DFA695@oracle.com> Message-ID: <5cf35843-1781-4b16-0309-bf2545a11208@oracle.com> On 01/31/2019 10:52, Igor Ignatyev wrote: > Hi Alex, > > you have 'if INCLUDE_JVMCI' inside 'ifndef ZERO', although we currently don't have zero builds w/ JVMCI (and I don't think such builds would make much sense), it's better not to rely on that. not a blocker from my point of view though. can_pop_frame & can_force_early_return are set only if ZERO is not defined (for zero builds the capabilities are not supported), so I added disabling logic in the same block. --alex > > Thanks, > -- Igor > >> On Jan 31, 2019, at 10:38 AM, 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 igor.ignatyev at oracle.com Thu Jan 31 19:09:04 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 31 Jan 2019 11:09:04 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: <5cf35843-1781-4b16-0309-bf2545a11208@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> <3CD7BD6E-5FEE-4A0E-9A60-993B69DFA695@oracle.com> <5cf35843-1781-4b16-0309-bf2545a11208@oracle.com> Message-ID: <9A426E4F-99BD-4B77-9C99-39783B64135B@oracle.com> Hi Alex, sure I understand that, but let's say we decide to add these capabilities to ZERO or remove all ZERO-specific code. I am *not* saying we are going to do that, just speculating. In such cases, your code[1] will require more effort to figure that should be changed comparing to the almost identical code[2]. but as I said I'm fine w/ your current code. Thanks, -- Igor [1] > #ifndef ZERO > jc.can_pop_frame = 1; > jc.can_force_early_return = 1; > + // Workaround for 8195635: > + // disable pop_frame and force_early_return capabilities with Graal > +#if INCLUDE_JVMCI > + if (UseJVMCICompiler) { > + jc.can_pop_frame = 0; > + jc.can_force_early_return = 0; > + } > +#endif // INCLUDE_JVMCI > #endif // !ZERO [2] > #ifndef ZERO > jc.can_pop_frame = 1; > jc.can_force_early_return = 1; > #endif // !ZERO > + // Workaround for 8195635: > + // disable pop_frame and force_early_return capabilities with Graal > +#if INCLUDE_JVMCI > + if (UseJVMCICompiler) { > + jc.can_pop_frame = 0; > + jc.can_force_early_return = 0; > + } > +#endif // INCLUDE_JVMCI > On Jan 31, 2019, at 10:59 AM, Alex Menkov wrote: > > > > On 01/31/2019 10:52, Igor Ignatyev wrote: >> Hi Alex, >> you have 'if INCLUDE_JVMCI' inside 'ifndef ZERO', although we currently don't have zero builds w/ JVMCI (and I don't think such builds would make much sense), it's better not to rely on that. not a blocker from my point of view though. > > can_pop_frame & can_force_early_return are set only if ZERO is not defined (for zero builds the capabilities are not supported), so I added disabling logic in the same block. > > --alex > >> Thanks, >> -- Igor >>> On Jan 31, 2019, at 10:38 AM, 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 >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu Jan 31 19:39:35 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jan 2019 11:39:35 -0800 Subject: RFR (12) JDK-8218025: disable pop_frame and force_early_return caps for Graal In-Reply-To: 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> Message-ID: <79d984ba-f3bd-b329-4d5f-4ba2083e9628@oracle.com> 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 serguei.spitsyn at oracle.com Thu Jan 31 21:23:28 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 31 Jan 2019 13:23:28 -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> Message-ID: <9cfcd666-e114-b508-d253-fb89b7cdc83b@oracle.com> An HTML attachment was scrubbed... URL: