From jcbeyler at google.com Wed May 1 00:00:19 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 17:00:19 -0700 Subject: RFR (S) 8223146 [TESTBUG] new test vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/ fails on Windows Message-ID: Hi all, (second day in a row is a "charm"; my apologies for the double post) I figured out the problem for this test bug, I put additional data in the bug itself for tracking. Webrev: http://cr.openjdk.java.net/~jcbeyler/8223146/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223146 Note: If this solution is ok to all, I'll drop the problem list webrev and push this one; if this lingers and I get LGTMs for the problem list, I'll push that one and then we can work out this problem/solution. (I've tested this as much as I could and have pushed this on the submit-repo but I'm unsure that would test this test on Windows; if someone could test it, that would be perhaps a good idea as well). Thanks for your help, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed May 1 00:10:05 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Apr 2019 17:10:05 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: Message-ID: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> Hi Jc, I'd suggest to change the bug title to be: ?? Add a AsyncGetCallTrace test I'm not sure about the test names. Maybe, it is Okay to keep the AGCT abbreviation. But I'd like to hear other opinions. Thanks, Serguei On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: > Hi all, > > As I start looking at working on the AGCT bugs, I wanted to at least > start creating a baseline of tests for AGCT. This is an attempt to > just have a "base" test (and infrastructure) that tries to call AGCT > and get back some sane information. > > Next step will be to add a few more tests that will be exposing the > limitations of https://bugs.openjdk.java.net/browse/JDK-8178287?for > example. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 > > This passed the test on my linux machine (the test is only for linux > due to the dlsym) and the submit-repo. > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed May 1 00:28:23 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Apr 2019 17:28:23 -0700 Subject: RFR (S) 8223146 [TESTBUG] new test vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/ fails on Windows In-Reply-To: References: Message-ID: Hi Jc, The fix looks good to me. On 4/30/19 5:00 PM, Jean Christophe Beyler wrote: > Hi all, > > (second day in a row is a "charm"; my apologies for the double post) > > I figured out the problem for this test bug, I put additional data in > the bug itself for tracking. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223146/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223146 > > Note: If this solution is ok to all, I'll drop the problem list webrev > and push this one; if this lingers and I get LGTMs for the problem > list, I'll push that one and then we can work out this problem/solution. I'd go with this fix (if testing is good). > (I've tested this as much as I could and have pushed this on the > submit-repo but I'm unsure that would test this test on Windows; if > someone could test it, that would be perhaps a good idea as well). I have no experience yet with the submit-repo but hope it tests on all normal platforms. Or you are asking about Windows 32-bit platform? Thanks, Serguei > > Thanks for your help, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed May 1 00:54:43 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 May 2019 10:54:43 +1000 Subject: RFR (S) 8223146 [TESTBUG] new test vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/ fails on Windows In-Reply-To: References: Message-ID: <18725642-b5cb-8590-2e63-ed53009b65c7@oracle.com> Hi Jc, On 1/05/2019 10:00 am, Jean Christophe Beyler wrote: > Hi all, > > (second day in a row is a "charm"; my apologies for the double post) > > I figured out the problem for this test bug, I put additional data in > the bug itself for tracking. Yep - never use "long" as its size will vary. :) > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223146/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223146 Change looks okay to me. Only query is where the INT32_MIN definition is coming from? I see it in stdint.h which isn't included. > Note: If this solution is ok to all, I'll drop the problem list webrev > and push this one; if this lingers and I get LGTMs for the problem list, > I'll push that one and then we can work out this problem/solution. Yep that's a good plan. Better to fix the bug than ProblemList. > (I've tested this as much as I could and have pushed this on the > submit-repo but I'm unsure that would test this test on Windows; if > someone could test it, that would be perhaps a good idea as well). I can't test on Windows either. I'll check the jdk-submit job to see that it does run the test on Windows as expected. Thanks, David > Thanks for your help, > Jc From serguei.spitsyn at oracle.com Wed May 1 00:57:44 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 30 Apr 2019 17:57:44 -0700 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> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> Message-ID: <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> Dear Lin, I looked at your CSR and have comments/questions below. > Add the options "chunkcount=" and "maxfilesize=" to JMap -histo to improve JMap's ability Ability to what? The statement above is no complete, it even does not have a dot. Most likely it should have something like: ? ... to improve JMap with the ability to dump heap histogram incrementally. > Currently the "JMap -histo" tool doesn't support to dump intermediate result, > which is useful when heap is large and dump whole heap with "jmap -histo" cause stuck. A suggestion is to rephrase it to something like: ? Now, the "jmap -histo" command can not dump intermediate result, which is useful if the heap is large and dumping the whole heap ? can be stuck. > Add "chunkcount=" and "maxfilesize=" option that let JMap -histo to dump intermediate result incrementally. A suggestion is to rephrase to something like: ? Add two new command options to control incremental dumping of intermediary data: ??? chunkcount=,? ? ? maxfilesize=, You need to explain now this parameters are going to be used and their semantics. Q1: Then what is the expected behavior of this incremental dump? Q2: What happens if just one of options is used? Q3: What are default values? Q4: Does enabling incremental dump disable full dump? This is still good to have as additional explanation for new options: * If new options "chunkcount=" and "maxfilesize=" options are not set then the jmap -histo behaves as before * Negative values or values larger than the max of uintx for "chunkcount" and "maxfilesize" are not allowed Please, be consistent with having or missing dots at the end of statements. |System.err.println(" incremental dump support:"); + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); | From this description is not clear at all what does the chunkcount mean. Is it to define how many heap objects are dumped in one chunk? If so, would it better to name it chunksize instead where chunksize is measured in heap objects? Then would it better to use the same units to define the maxfilesize as well? (I'm not insisting on this, just asking.) |+ System.err.println(" Specify chunkcont to non-zero will enable incremental dump."); Does it make sense to consider some reasonable default values for |||chunkcont| and |||maxfilesize|? Then they could be used with no value: "chunkcount" or "chunkcount=". + System.err.println(" The incremental data file is named \"Histo_Dump_Temp.dump\" under the same path specified by \"file=\" option.");| I don't like that "Dump/dump" suffix is used twice. At least, this is worth to consider something like this: |\"IncrementalHisto.dump\". |Also, I'd suggest to re-design all this a little bit. What about adding new option to force incremental dump: ? incremental{=} with the default file name |\"IncrementalHisto.dump\".| With this option, the options chunkcount and maxfilesize can be omitted implying default values. But we need to look at the overall jmap design to make sure this suggestion is aligned with other options.|| Thanks, Serguei On 4/14/19 7:54 PM, ?? wrote: > Dear Jc, > ? ? ? ?Thanks a lot for your suggestions, I have updated the CSR. > > Hi All, > ? ? ? ?May I get more review about the webrev and CSR, > ? ? ? ?Webrev: > http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ > > ? ? ? ?CSR: https://bugs.openjdk.java.net/browse/JDK-8222319. > > BRs, > Lin > >> ? 2019?4?13????2:15?Jean Christophe Beyler > > ??? >> >> Hi Lin, >> >> You could state in the CSR: >> ? - That not using the new flags makes the system behave as before; >> so it is a nop if you don't use the new flags >> ? - What happens if the flags are passed negative values? >> ? - What happens if the flags are passed crazy big numbers? >> >> Finally, I'd put a link to the current webrev if someone wanted more >> information. >> >> Apart from that, it looks good to me (I might skip the diff as you >> put the output below) the text could just say: here is the? new usage >> text (maxchunk and maxfilesize are new) >> >> Thanks, >> Jc >> >> On Wed, Apr 10, 2019 at 11:56 PM ?? > > wrote: >> >> Dear All, >> ? ? I have created a CSR at >> https://bugs.openjdk.java.net/browse/JDK-8222319. >> ? ? May I ask your help to review it? Thanks! >> >> >> BRs, >> Lin >> >>> ? 2019?4?11????11:22??? >> > ??? >>> >>> Sorry, it should be CSR ticket >>> >>> Thanks? >>> Lin >>> >>>> ? 2019?4?11????11:16??? >>> > ??? >>>> >>>> Also realized it requires a JCP ticket, I will create it. >>>> >>>> >>>> Cheers, >>>> Lin >>>> >>>>> ? 2019?4?11????10:26??? >>>> > ??? >>>>> >>>>> >>>>> Dear JC, >>>>> ? ?Thanks so much, I suddenly realized your way is exactly >>>>> what I want. >>>>> ? ?And here is new wehbrev. >>>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.06/ >>>>> >>>>> >>>>> BRs, >>>>> Lin >>>>> >>>>>> ? 2019?4?11????4:40?Jean Christophe Beyler >>>>>> > ??? >>>>>> >>>>>> Hi Lin, >>>>>> >>>>>> What I meant about the helper method was to not do this: >>>>>> >>>>>> >>>>>> + ? private static String add_option(String cmd, String opt) { >>>>>> + ? ? if (opt.equals("")) { >>>>>> + ? ? ? return cmd; >>>>>> + ? ? } >>>>>> + ? ? return cmd + opt + ","; >>>>>> + ? } >>>>>> + >>>>>> >>>>>> but to do this: >>>>>> >>>>>> + ? private static String add_option(String cmd, String opt) { >>>>>> + ? ? if (cmd.isEmpty()) { >>>>>> + ? ? ? return opt; >>>>>> + ? ? } >>>>>> + ? ? return cmd + "," + opt; >>>>>> + ? } >>>>>> + >>>>>> >>>>>> That way you only put the ',' when needed, >>>>>> Jc >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Apr 10, 2019 at 5:33 AM ?? >>>>> > wrote: >>>>>> >>>>>> Dear Jc, >>>>>> ? ?Thanks a lot for your comments, here is the refined >>>>>> webrev. May I ask your help to review again? >>>>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.05/ >>>>>> >>>>>> >>>>>> BRs, >>>>>> Lin >>>>>> >>>>>>> ? 2019?4?4????4:57?Jean Christophe Beyler >>>>>>> > ??? >>>>>>> >>>>>>> Hi Lin, >>>>>>> >>>>>>> Just a few nits to be honest: >>>>>>> >>>>>>> - >>>>>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/hotspot/share/utilities/ostream.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> -> I don't think it's a good idea to just pass a char* >>>>>>> and implicitly imagine it is 256 in length >>>>>>> -> Should we not add that length as a parameter? btw, >>>>>>> the test you have len > 255 is a bit too restrictive no? >>>>>>> Technically you should wait until you find the last '/' >>>>>>> and then test there no? >>>>>>> ?(technically we could use?strrchr, no?) >>>>>>> >>>>>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java.udiff.html >>>>>>> >>>>>>> -> the adding of the "," seems a bit off; I think it >>>>>>> would be smarter to just have a helper add_option to >>>>>>> cmdline that checks if it is not empty, then add "," and >>>>>>> the new option >>>>>>> ? ?-> otherwise you always end the "," if there are more >>>>>>> options even if you are ignoring them, no? >>>>>>> >>>>>>> Finally: >>>>>>> } else if (subopt.equals("live")) { >>>>>>> - liveopt = "-live"; >>>>>>> + // Add '-' for compatibility. >>>>>>> + cmdline += "-" + subopt; >>>>>>> >>>>>>> for consistency with how you do it for "all", should >>>>>>> this not be: >>>>>>> } else if (subopt.equals("live")) { >>>>>>> - liveopt = "-live"; >>>>>>> + // Add '-' for compatibility. >>>>>>> + cmdline += "-live"; >>>>>>> >>>>>>> Thanks, >>>>>>> Jc >>>>>>> >>>>>>> On Mon, Apr 1, 2019 at 5:18 AM ?? >>>>>> > wrote: >>>>>>> >>>>>>> Dear All? >>>>>>> ? ? Here I updated the latest changeset which did >>>>>>> the following refine: >>>>>>> ? ? * fixed the compatibility issues so that old >>>>>>> version of jmap can work normally with latest changeset. >>>>>>> ? ? * revised the code for parsing the jmap histo >>>>>>> arguments. >>>>>>> ? ? * revised the logic for incremental dumping of >>>>>>> jmap histo. >>>>>>> ? ? The main change of this webrev is making all >>>>>>> arguments passed to virtual machine as one line. So >>>>>>> there is no need to care about the max argument >>>>>>> count limitation. And hence resolved the >>>>>>> compatibility issues as discussed in >>>>>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-March/027338.html >>>>>>> >>>>>>> ? ? May I ?ask your help to review? >>>>>>> http://cr.openjdk.java.net/~lzang/jmap-8214535/8215623/webrev.04/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> BRs, >>>>>>> Lin >>>>>>> >>>>>>>> ? 2019?2?26????10:50??? >>>>>>> > ??? >>>>>>>> >>>>>>>> Dear All, >>>>>>>> ????????I have revised the webrev at >>>>>>>> http://cr.openjdk.java.net/~xiaofeya/8215623/webrev.02/ >>>>>>>> . >>>>>>>> >>>>>>>> ????????May I ask your help for reviewing? Thanks >>>>>>>> >>>>>>>> >>>>>>>> BRs, >>>>>>>> Lin >>>>>>>>> -----Original Message----- >>>>>>>>> From: ?? >>>>>>>>> Sent: Friday, January 25, 2019 9:01 AM >>>>>>>>> To: Hohensee, Paul >>>>>>>> >; serviceability- >>>>>>>>> dev at openjdk.java.net >>>>>>>>> Subject: Re: [RFR]8215623: Add incremental dump >>>>>>>>> for jmap histo >>>>>>>>> >>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>>>> 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 >>>>>>>> bounces at openjdk.java.net >>>>>>>>> >>>>>>>> >>>>>>>>> bounces at openjdk.java.net >>>>>>>>> >> on behalf of ?? >>>>>>>>> >>>>>>>> >>>>>>>> >> >>>>>>>>> Date: Thursday, December 20, 2018 at 11:13 PM >>>>>>>>> To: "serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>> >>>>>>>>> dev at openjdk.java.net >>>>>>>>> >" >>>>>>>> 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 ?histo. >>>>>>>>> >>>>>>>>> It adds the ?incremental? arguments that allow >>>>>>>>> jmap ?histo 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thanks, >>>>>>> Jc >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc >>>>> >>>> >>> >> >> >> >> -- >> >> Thanks, >> Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manc at google.com Wed May 1 01:51:39 2019 From: manc at google.com (Man Cao) Date: Tue, 30 Apr 2019 18:51:39 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking Message-ID: Hi all, Can I have reviews for this small change that adds memory fences for double-checked locking? We found this race while working on the Java ThreadSanitizer project. Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 -Man -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed May 1 02:36:27 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 19:36:27 -0700 Subject: RFR (S) 8223146 [TESTBUG] new test vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/ fails on Windows In-Reply-To: <18725642-b5cb-8590-2e63-ed53009b65c7@oracle.com> References: <18725642-b5cb-8590-2e63-ed53009b65c7@oracle.com> Message-ID: Hi David & Serguei, @Serguei: I know from experience that submit-repo builds on various platforms but I'm never sure what tests are actually run. Since this is a testbug for windows, I'm just wondering if we could/should confirm it fixed that case; I'm fairly confident since my tests with the right options show the same exact failure on linux before the patch but still... @David: Thanks for the review, the inclusion path is this actually test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h -> /usr/include/inttypes.h -> /usr/lib/gcc/x86_64-linux-gnu/7/include/stdint.h -> /usr/include/stdint.h I've added an explicit inclusion to the c++ file in my local branch, seemed cleaner :) The submit repo passed so if you could check if it did run on windows, that would be great; or I can just submit and push and we can see, whichever you prefer. Thanks both for the review! Jc On Tue, Apr 30, 2019 at 5:54 PM David Holmes wrote: > Hi Jc, > > On 1/05/2019 10:00 am, Jean Christophe Beyler wrote: > > Hi all, > > > > (second day in a row is a "charm"; my apologies for the double post) > > > > I figured out the problem for this test bug, I put additional data in > > the bug itself for tracking. > > Yep - never use "long" as its size will vary. :) > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223146/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223146 > > Change looks okay to me. Only query is where the INT32_MIN definition is > coming from? I see it in stdint.h which isn't included. > > > Note: If this solution is ok to all, I'll drop the problem list webrev > > and push this one; if this lingers and I get LGTMs for the problem list, > > I'll push that one and then we can work out this problem/solution. > > Yep that's a good plan. Better to fix the bug than ProblemList. > > > (I've tested this as much as I could and have pushed this on the > > submit-repo but I'm unsure that would test this test on Windows; if > > someone could test it, that would be perhaps a good idea as well). > > I can't test on Windows either. I'll check the jdk-submit job to see > that it does run the test on Windows as expected. > > Thanks, > David > > > Thanks for your help, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed May 1 03:21:56 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 May 2019 13:21:56 +1000 Subject: RFR (S) 8223146 [TESTBUG] new test vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/ fails on Windows In-Reply-To: References: <18725642-b5cb-8590-2e63-ed53009b65c7@oracle.com> Message-ID: Hi Jc, On 1/05/2019 12:36 pm, Jean Christophe Beyler wrote: > Hi David & Serguei, > > @Serguei: I know from experience that submit-repo builds on various > platforms but I'm never sure what tests are actually run. Since this is > a testbug for windows, I'm just wondering if we could/should confirm it > fixed that case; I'm fairly confident since my tests with the right > options show the same exact failure on linux before the patch but still... > > @David: Thanks for the review, the inclusion path is this actually > > ?test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h -> > ?/usr/include/inttypes.h -> > /usr/lib/gcc/x86_64-linux-gnu/7/include/stdint.h -> > ?/usr/include/stdint.h > > I've added an explicit inclusion to the c++ file in my local branch, > seemed cleaner :) Okay - thanks! > The submit repo passed so if you could check if it did run on windows, > that would be great; or I can just submit and push and we can see, > whichever you prefer. AFAICS these tests are not run in jdk-submit. We saw the failure in tier5 testing. But I used your jdk-submit build to run this test on Windows and it passed. So please go ahead and push the fix. jib > -------------------------------------------------- jib > TEST: vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/TestDescription.java jib > build: 1.282 seconds jib > compile: 1.266 seconds jib > driver: 0.593 seconds jib > build: 0.11 seconds jib > compile: 0.11 seconds jib > main: 0.203 seconds jib > TEST RESULT: Passed. Execution successful jib > -------------------------------------------------- I also just noticed this test is located in nsk/share/ - why is that? AFAIK "share" is for utility classes not for actual tests. ?? Thanks, David ----- > Thanks both for the review! > Jc > > On Tue, Apr 30, 2019 at 5:54 PM David Holmes > wrote: > > Hi Jc, > > On 1/05/2019 10:00 am, Jean Christophe Beyler wrote: > > Hi all, > > > > (second day in a row is a "charm"; my apologies for the double post) > > > > I figured out the problem for this test bug, I put additional > data in > > the bug itself for tracking. > > Yep - never use "long" as its size will vary. :) > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223146/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223146 > > Change looks okay to me. Only query is where the INT32_MIN > definition is > coming from? I see it in stdint.h which isn't included. > > > Note: If this solution is ok to all, I'll drop the problem list > webrev > > and push this one; if this lingers and I get LGTMs for the > problem list, > > I'll push that one and then we can work out this problem/solution. > > Yep that's a good plan. Better to fix the bug than ProblemList. > > > (I've tested this as much as I could and have pushed this on the > > submit-repo but I'm unsure that would test this test on Windows; if > > someone could test it, that would be perhaps a good idea as well). > > I can't test on Windows either. I'll check the jdk-submit job to see > that it does run the test on Windows as expected. > > Thanks, > David > > > Thanks for your help, > > Jc > > > > -- > > Thanks, > Jc From jcbeyler at google.com Wed May 1 03:32:02 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 30 Apr 2019 20:32:02 -0700 Subject: RFR (S) 8223146 [TESTBUG] new test vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/ fails on Windows In-Reply-To: References: <18725642-b5cb-8590-2e63-ed53009b65c7@oracle.com> Message-ID: Hi David, Thanks for checking, I've pushed it so you would not get failures anymore due to that. Now regarding the placement of the test, when I added it I had pondered for a while where it should go; the thing is that I felt that the exception code should be tested (with good reason as it failed here due to a bug :-)) but the code it is testing is actually in the nsk/share/jni directory. So when we did it I thought I asked if it should go there or not. If you have a better placement for the test, I'll happily move it out; it just felt weird to move out the test code of the nsk/share folder when what it was testing was the nsk/share code... (If that makes sense). Anyway, I will happily move this test out to somewhere else; I just had not seen any spot where we tested this particular part of the test infrastructure. Thanks again for the reviews, Jc On Tue, Apr 30, 2019 at 8:22 PM David Holmes wrote: > Hi Jc, > > On 1/05/2019 12:36 pm, Jean Christophe Beyler wrote: > > Hi David & Serguei, > > > > @Serguei: I know from experience that submit-repo builds on various > > platforms but I'm never sure what tests are actually run. Since this is > > a testbug for windows, I'm just wondering if we could/should confirm it > > fixed that case; I'm fairly confident since my tests with the right > > options show the same exact failure on linux before the patch but > still... > > > > @David: Thanks for the review, the inclusion path is this actually > > > > test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.h -> > > /usr/include/inttypes.h -> > > /usr/lib/gcc/x86_64-linux-gnu/7/include/stdint.h -> > > /usr/include/stdint.h > > > > I've added an explicit inclusion to the c++ file in my local branch, > > seemed cleaner :) > > Okay - thanks! > > > The submit repo passed so if you could check if it did run on windows, > > that would be great; or I can just submit and push and we can see, > > whichever you prefer. > > AFAICS these tests are not run in jdk-submit. We saw the failure in > tier5 testing. But I used your jdk-submit build to run this test on > Windows and it passed. So please go ahead and push the fix. > > jib > -------------------------------------------------- > jib > TEST: > > vmTestbase/nsk/share/ExceptionCheckingJniEnv/exceptionjni001/TestDescription.java > jib > build: 1.282 seconds > jib > compile: 1.266 seconds > jib > driver: 0.593 seconds > jib > build: 0.11 seconds > jib > compile: 0.11 seconds > jib > main: 0.203 seconds > jib > TEST RESULT: Passed. Execution successful > jib > -------------------------------------------------- > > I also just noticed this test is located in nsk/share/ - why is that? > AFAIK "share" is for utility classes not for actual tests. ?? > > Thanks, > David > ----- > > > Thanks both for the review! > > Jc > > > > On Tue, Apr 30, 2019 at 5:54 PM David Holmes > > wrote: > > > > Hi Jc, > > > > On 1/05/2019 10:00 am, Jean Christophe Beyler wrote: > > > Hi all, > > > > > > (second day in a row is a "charm"; my apologies for the double > post) > > > > > > I figured out the problem for this test bug, I put additional > > data in > > > the bug itself for tracking. > > > > Yep - never use "long" as its size will vary. :) > > > > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223146/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223146 > > > > Change looks okay to me. Only query is where the INT32_MIN > > definition is > > coming from? I see it in stdint.h which isn't included. > > > > > Note: If this solution is ok to all, I'll drop the problem list > > webrev > > > and push this one; if this lingers and I get LGTMs for the > > problem list, > > > I'll push that one and then we can work out this problem/solution. > > > > Yep that's a good plan. Better to fix the bug than ProblemList. > > > > > (I've tested this as much as I could and have pushed this on the > > > submit-repo but I'm unsure that would test this test on Windows; > if > > > someone could test it, that would be perhaps a good idea as well). > > > > I can't test on Windows either. I'll check the jdk-submit job to see > > that it does run the test on Windows as expected. > > > > Thanks, > > David > > > > > Thanks for your help, > > > Jc > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed May 1 11:02:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 1 May 2019 21:02:27 +1000 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: References: Message-ID: <00b5c71f-10a9-ab73-8304-65383051010d@oracle.com> Hi Man, On 1/05/2019 11:51 am, Man Cao wrote: > Hi all, > > Can I have reviews for this small change that adds memory fences for > double-checked locking? > We found this race while working on the Java ThreadSanitizer project. > > Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 Looks fine. One query in jvmtiTagMap.cpp - Was there a particular reason you moved the set_tag_map out of the constructor? (It's a common pattern when objects are bi-directionally linked to do it in the constructor.) Thanks, David > -Man From alexey.menkov at oracle.com Wed May 1 17:54:16 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 1 May 2019 10:54:16 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> Message-ID: Hi all, I created CSR for the feature: https://bugs.openjdk.java.net/browse/JDK-8223104 The latest webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ --alex From manc at google.com Wed May 1 18:05:39 2019 From: manc at google.com (Man Cao) Date: Wed, 1 May 2019 11:05:39 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: <00b5c71f-10a9-ab73-8304-65383051010d@oracle.com> References: <00b5c71f-10a9-ab73-8304-65383051010d@oracle.com> Message-ID: Thanks for the review. I moved set_tag_map out of the constructor because the release store is only required in the double-checked locking pattern. If the constructor is called in a single-threaded context, or if _tag_map is always protected by a lock, then it could use the normal store instead. Currently it doesn't matter since the constructor is only called inside the double-checked locking. I'm OK either way. Do you prefer to keep it inside the constructor? -Man On Wed, May 1, 2019 at 4:02 AM David Holmes wrote: > Hi Man, > > On 1/05/2019 11:51 am, Man Cao wrote: > > Hi all, > > > > Can I have reviews for this small change that adds memory fences for > > double-checked locking? > > We found this race while working on the Java ThreadSanitizer project. > > > > Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 > > Looks fine. One query in jvmtiTagMap.cpp - Was there a particular reason > you moved the set_tag_map out of the constructor? (It's a common pattern > when objects are bi-directionally linked to do it in the constructor.) > > Thanks, > David > > > -Man > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manc at google.com Wed May 1 20:25:25 2019 From: manc at google.com (Man Cao) Date: Wed, 1 May 2019 13:25:25 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: References: <00b5c71f-10a9-ab73-8304-65383051010d@oracle.com> Message-ID: I have moved the set_tag_map back to the constructor: https://cr.openjdk.java.net/~manc/8223177/webrev.01/ -Man On Wed, May 1, 2019 at 11:05 AM Man Cao wrote: > Thanks for the review. > I moved set_tag_map out of the constructor because the release store is > only required in the double-checked locking pattern. > If the constructor is called in a single-threaded context, or if _tag_map > is always protected by a lock, then it could use the normal store instead. > Currently it doesn't matter since the constructor is only called inside > the double-checked locking. > I'm OK either way. Do you prefer to keep it inside the constructor? > > -Man > > > On Wed, May 1, 2019 at 4:02 AM David Holmes > wrote: > >> Hi Man, >> >> On 1/05/2019 11:51 am, Man Cao wrote: >> > Hi all, >> > >> > Can I have reviews for this small change that adds memory fences for >> > double-checked locking? >> > We found this race while working on the Java ThreadSanitizer project. >> > >> > Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ >> > Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 >> >> Looks fine. One query in jvmtiTagMap.cpp - Was there a particular reason >> you moved the set_tag_map out of the constructor? (It's a common pattern >> when objects are bi-directionally linked to do it in the constructor.) >> >> Thanks, >> David >> >> > -Man >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Wed May 1 21:35:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 May 2019 07:35:55 +1000 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: References: <00b5c71f-10a9-ab73-8304-65383051010d@oracle.com> Message-ID: <0aedf420-b1a5-2b70-dde1-9362bb46ef62@oracle.com> On 2/05/2019 6:25 am, Man Cao wrote: > I have moved the set_tag_map back to the constructor: > https://cr.openjdk.java.net/~manc/8223177/webrev.01/ Looks good - thanks. I doubt there will be any additional use of this constructor. David ----- > -Man > > > On Wed, May 1, 2019 at 11:05 AM Man Cao > wrote: > > Thanks for the review. > I moved set_tag_map out of the constructor because the release store > is only required in the double-checked locking pattern. > If the constructor is called in a single-threaded context, or if > _tag_map is always protected by a lock, then it could use the normal > store instead. > Currently it doesn't matter since the constructor is only called > inside the double-checked locking. > I'm OK either way. Do you prefer to keep it inside the constructor? > > -Man > > > On Wed, May 1, 2019 at 4:02 AM David Holmes > wrote: > > Hi Man, > > On 1/05/2019 11:51 am, Man Cao wrote: > > Hi all, > > > > Can I have reviews for this small change that adds memory > fences for > > double-checked locking? > > We found this race while working on the Java ThreadSanitizer > project. > > > > Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 > > Looks fine. One query in jvmtiTagMap.cpp - Was there a > particular reason > you moved the set_tag_map out of the constructor? (It's a common > pattern > when objects are bi-directionally linked to do it in the > constructor.) > > Thanks, > David > > > -Man > From jcbeyler at google.com Wed May 1 22:11:15 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 1 May 2019 15:11:15 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: <0aedf420-b1a5-2b70-dde1-9362bb46ef62@oracle.com> References: <00b5c71f-10a9-ab73-8304-65383051010d@oracle.com> <0aedf420-b1a5-2b70-dde1-9362bb46ef62@oracle.com> Message-ID: Hi Man, Not surprisingly, this looks good to me, though I'm not an official reviewer :), Jc On Wed, May 1, 2019 at 2:36 PM David Holmes wrote: > On 2/05/2019 6:25 am, Man Cao wrote: > > I have moved the set_tag_map back to the constructor: > > https://cr.openjdk.java.net/~manc/8223177/webrev.01/ > > Looks good - thanks. I doubt there will be any additional use of this > constructor. > > David > ----- > > > -Man > > > > > > On Wed, May 1, 2019 at 11:05 AM Man Cao > > wrote: > > > > Thanks for the review. > > I moved set_tag_map out of the constructor because the release store > > is only required in the double-checked locking pattern. > > If the constructor is called in a single-threaded context, or if > > _tag_map is always protected by a lock, then it could use the normal > > store instead. > > Currently it doesn't matter since the constructor is only called > > inside the double-checked locking. > > I'm OK either way. Do you prefer to keep it inside the constructor? > > > > -Man > > > > > > On Wed, May 1, 2019 at 4:02 AM David Holmes > > wrote: > > > > Hi Man, > > > > On 1/05/2019 11:51 am, Man Cao wrote: > > > Hi all, > > > > > > Can I have reviews for this small change that adds memory > > fences for > > > double-checked locking? > > > We found this race while working on the Java ThreadSanitizer > > project. > > > > > > Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 > > > > Looks fine. One query in jvmtiTagMap.cpp - Was there a > > particular reason > > you moved the set_tag_map out of the constructor? (It's a common > > pattern > > when objects are bi-directionally linked to do it in the > > constructor.) > > > > Thanks, > > David > > > > > -Man > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 2 00:21:20 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 1 May 2019 17:21:20 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: References: Message-ID: <0030533b-74f0-9572-d28a-fc99ebfbcafc@oracle.com> An HTML attachment was scrubbed... URL: From manc at google.com Thu May 2 01:00:04 2019 From: manc at google.com (Man Cao) Date: Wed, 1 May 2019 18:00:04 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: <0030533b-74f0-9572-d28a-fc99ebfbcafc@oracle.com> References: <0030533b-74f0-9572-d28a-fc99ebfbcafc@oracle.com> Message-ID: Thank everyone for the review! Renamed and final webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.02/ -Man On Wed, May 1, 2019 at 5:21 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Man, > > Looks good to me. > > Minor comment: > I'd suggest to rename tag_map_acquire to acquire_tag_map to be consistent > with release_set_tag_map. > > > Thanks, > Serguei > > > On 4/30/19 18:51, Man Cao wrote: > > Hi all, > > Can I have reviews for this small change that adds memory fences for > double-checked locking? > We found this race while working on the Java ThreadSanitizer project. > > Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 > > -Man > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Thu May 2 01:07:38 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 01 May 2019 18:07:38 -0700 Subject: RFR: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" Message-ID: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> Please review the change that fixes the test that intermittently fails with Graal on. The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 Thanks! --Daniil From jcbeyler at google.com Thu May 2 02:39:05 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 1 May 2019 19:39:05 -0700 Subject: RFR (L) 8220747: Message-ID: Hi all, I want to move the libHeapMonitorTest.c to C++ and here is the first "step" towards that. There are two parts to this: move the file to C++ and move some of the C-style to C++-style code. But this webrev failed on solaris; Igor helped me figure it out and his solution was to add the change to the JtregNativeHotspot.gmk for solstudio. We are not sure this is the "right" solution to this and hence have added both the serviceability and build lists to review both file changes and figure out what is best :) This does pass the submit-repo testing and the tests on my local dev machine. Bug: https://bugs.openjdk.java.net/browse/JDK-8220747 Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.02/ Thanks all for your help, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu May 2 02:40:56 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 1 May 2019 19:40:56 -0700 Subject: RFR: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> Message-ID: Hi Daniil, Looks good to me :) Jc On Wed, May 1, 2019 at 6:08 PM Daniil Titov wrote: > Please review the change that fixes the test that intermittently fails > with Graal on. > > The test tests addThreadFilter() method for > com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates > ThreadStartRequest, enables it, and calls addThreadFilter(). The test also > uses breakpoints to synchronize with the debuggee, but the problem here is > that while waiting for a breakpoint event, occasionally, when Graal is on, > the event the test receives is a ThreadStartEvent for " > HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint > event. The test doesn't expect it and fails. > > The fix takes this into account and makes the test keep waiting for a > breakpoint event instead of failing. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Daniil > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 2 02:42:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 May 2019 12:42:50 +1000 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: References: <0030533b-74f0-9572-d28a-fc99ebfbcafc@oracle.com> Message-ID: On 2/05/2019 11:00 am, Man Cao wrote: > Thank everyone for the review! > Renamed and final webrev: > https://cr.openjdk.java.net/~manc/8223177/webrev.02/ No do not rename! Sorry Serguei but for these accesses with OrderAccess semantics the placement of the acquire/release reflects the barrier semantics of load_acquire and release_store. So we use foo_acquire to load foo with acquire semantics; while release_set_foo performs a release barrier followed by set_foo. This convention is used throughout the VM for these kinds of methods. David ----- > -Man > > > On Wed, May 1, 2019 at 5:21 PM serguei.spitsyn at oracle.com > > wrote: > > Hi Man, > > Looks good to me. > > Minor comment: > I'd suggest to rename tag_map_acquire to acquire_tag_map to be > consistent with release_set_tag_map. > > > Thanks, > Serguei > > > On 4/30/19 18:51, Man Cao wrote: >> Hi all, >> >> Can I have reviews for this small change that adds memory fences >> for double-checked locking? >> We found this race while working on the Java ThreadSanitizer project. >> >> Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 >> >> -Man > From jcbeyler at google.com Thu May 2 03:08:26 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 1 May 2019 20:08:26 -0700 Subject: RFR (L) 8220747: Migrate data structures to being more C++ Message-ID: Hi all, Re-sending with the full title.... (OK... so JC will promise to go around the block 3 times before submitting a review request; and will do any item you would like to redeem myself; I apologize profusely and feel horrible...) I want to move the libHeapMonitorTest.c to C++ and here is the first "step" towards that. There are two parts to this: move the file to C++ and move some of the C-style to C++-style code. But this webrev failed on solaris; Igor helped me figure it out and his solution was to add the change to the JtregNativeHotspot.gmk for solstudio. We are not sure this is the "right" solution to this and hence have added both the serviceability and build lists to review both file changes and figure out what is best :) This does pass the submit-repo testing and the tests on my local dev machine. Bug: https://bugs.openjdk.java.net/browse/JDK-8220747 Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.02/ Thanks all for your help, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From manc at google.com Thu May 2 03:29:34 2019 From: manc at google.com (Man Cao) Date: Wed, 1 May 2019 20:29:34 -0700 Subject: RFR (XS): 8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase Message-ID: Hi all, Can I have reviews for this cleanup following up JDK-8223177: Webrev: https://cr.openjdk.java.net/~manc/8223227/webrev.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8223227 See http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/027882.html for context. -Man -------------- next part -------------- An HTML attachment was scrubbed... URL: From manc at google.com Thu May 2 03:30:27 2019 From: manc at google.com (Man Cao) Date: Wed, 1 May 2019 20:30:27 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: References: <0030533b-74f0-9572-d28a-fc99ebfbcafc@oracle.com> Message-ID: Thanks for the clarification. I have pushed this change, but I have created and sent out RFR for https://bugs.openjdk.java.net/browse/JDK-8223227. -Man On Wed, May 1, 2019 at 7:42 PM David Holmes wrote: > On 2/05/2019 11:00 am, Man Cao wrote: > > Thank everyone for the review! > > Renamed and final webrev: > > https://cr.openjdk.java.net/~manc/8223177/webrev.02/ > > No do not rename! Sorry Serguei but for these accesses with OrderAccess > semantics the placement of the acquire/release reflects the barrier > semantics of load_acquire and release_store. So we use foo_acquire to > load foo with acquire semantics; while release_set_foo performs a > release barrier followed by set_foo. This convention is used throughout > the VM for these kinds of methods. > > David > ----- > > > -Man > > > > > > On Wed, May 1, 2019 at 5:21 PM serguei.spitsyn at oracle.com > > > > wrote: > > > > Hi Man, > > > > Looks good to me. > > > > Minor comment: > > I'd suggest to rename tag_map_acquire to acquire_tag_map to be > > consistent with release_set_tag_map. > > > > > > Thanks, > > Serguei > > > > > > On 4/30/19 18:51, Man Cao wrote: > >> Hi all, > >> > >> Can I have reviews for this small change that adds memory fences > >> for double-checked locking? > >> We found this race while working on the Java ThreadSanitizer > project. > >> > >> Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 > >> > >> -Man > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu May 2 03:35:51 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 1 May 2019 20:35:51 -0700 Subject: RFR (XS): 8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase In-Reply-To: References: Message-ID: Hi Man, Looks good to me :), Jc On Wed, May 1, 2019 at 8:30 PM Man Cao wrote: > Hi all, > > Can I have reviews for this cleanup following up JDK-8223177: > Webrev: https://cr.openjdk.java.net/~manc/8223227/webrev.00/ > RFE: https://bugs.openjdk.java.net/browse/JDK-8223227 > > See > http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/027882.html for > context. > > -Man > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 2 04:04:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 May 2019 14:04:29 +1000 Subject: RFR (XS): 8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase In-Reply-To: References: Message-ID: <6c7ac0fa-8b44-292c-fe6e-328d265a3de6@oracle.com> Looks good. Thanks for cleaning it up. David On 2/05/2019 1:29 pm, Man Cao wrote: > Hi all, > > Can I have reviews for this cleanup following up JDK-8223177: > Webrev: https://cr.openjdk.java.net/~manc/8223227/webrev.00/ > RFE: https://bugs.openjdk.java.net/browse/JDK-8223227 > > See > http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/027882.html?for > context. > > -Man From david.holmes at oracle.com Thu May 2 05:22:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 May 2019 15:22:07 +1000 Subject: RFR (L) 8220747: Migrate data structures to being more C++ In-Reply-To: References: Message-ID: <4927d1b1-49ad-9be7-d2ca-483e521f7b18@oracle.com> Hi Jc, I just a had a quick look at this so not a full review - sorry. I'm not sure it makes sense to define classes within "extern C {". The extern C is intended to define an interface for this C++ library to be used from a C program - as discussed here for your Solaris issue: https://docs.oracle.com/cd/E18659_01/html/821-1383/bkamu.html Cheers, David On 2/05/2019 1:08 pm, Jean Christophe Beyler wrote: > Hi all, > > Re-sending with the full title.... > > (OK... so JC will promise to go around the block 3 times before submitting > a review request; and will do any item you would like to redeem myself; I > apologize profusely and feel horrible...) > > I want to move the libHeapMonitorTest.c to C++ and here is the first "step" > towards that. There are two parts to this: move the file to C++ and move > some of the C-style to C++-style code. > > But this webrev failed on solaris; Igor helped me figure it out and his > solution was to add the change to the JtregNativeHotspot.gmk for solstudio. > We are not sure this is the "right" solution to this and hence have added > both the serviceability and build lists to review both file changes and > figure out what is best :) > > This does pass the submit-repo testing and the tests on my local dev > machine. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220747 > Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.02/ > > Thanks all for your help, > Jc > From sundararajan.athijegannathan at oracle.com Thu May 2 05:47:13 2019 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Thu, 02 May 2019 11:17:13 +0530 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> <5CB55AD2.70106@oracle.com> <5CB93441.9080508@oracle.com> Message-ID: <5CCA8461.3070806@oracle.com> Hi Yasumasa, Sorry for delayed response. Your webrev looks like a good start! Unfortunately, dependency on nashorn is inevitable. But there is a similar (but different) object API for Graal.js. In future, someone may have to do some porting work. Thanks, -Sundar On 19/04/19, 6:37 PM, Yasumasa Suenaga wrote: > Hi Sundar, > > I tried to implement JSObject for SA. > Following webrev is not completed, but it can get VM object > and Debugger in it from sa.js: > > http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/jsobject.work/ > > It is not completed (error will occur when CLSDB is attached.) > but I want to hear your opinion. So I share it. > > AFAIK JSObject impl. idea needs to use AbstractJSObject, but it is > provided by jdk.scripting.nashorn module. > However Nashorn has been deprecated by JEP 335 and it might be removed. > > Can we fix this issue not to depend on jdk.scripting.nashorn module? > If it can't, is it allowed to use deprecated module? > > I guess Nashorn might be replaced to Graal.js in the future. > So I concern it is not better to depend on Nashorn. > > > Thanks, > > Yasumasa > > > On 2019/04/19 11:36, Sundararajan Athijegannathan wrote: >> Hi Yasumasa >> >> Thanks for confirming that we've the same issue with Graal.js as >> well. I think JSObject impl. idea should be investigated. I think >> there is similar (script) reflective API in Graal.js as well. >> >> Thanks >> -Sundar >> >> On 17/04/19, 7:37 PM, Yasumasa Suenaga wrote: >>> Hi Sundar, >>> >>> On 2019/04/16 13:32, Sundararajan Athijegannathan wrote: >>>> Hi Yasumasa, >>>> >>>> Response comments inlined below.. >>>> >>>> >>>> On 16/04/19, 5:21 AM, Yasumasa Suenaga wrote: >>>>> Hi Sundar, >>>>> >>>>> On 2019/04/15 16:58, Sundararajan Athijegannathan wrote: >>>>>> Both options are hacks :( Personally I'm not comfortable with either >>>>>> option. >>>>>> >>>>>> JSObject wrapper suggested in the bug is not impossible to do. >>>>>> >>>>>> VM.getVM() would the "initial object" -- a JSObject impl. that walks >>>>>> through objects is possible. JSObject impls. can cache >>>>>> fields/methods >>>>>> reflectively and invoke those as needed. If SA class is needed, >>>>>> we can >>>>>> add JSClassObject impl. (which would a JSObject impl. that'd support >>>>>> static method/field access). >>>>> >>>>> I guess SA classes will be added / modified due to HotSpot >>>>> improvement (e.g. GC, JIT, etc...) >>>>> So I think it is not reasonable to add JSClassObject implementations. >>>> >>>> We need to add only *one* JSClassObject class (which can expose >>>> static fields/methods of a given java.lang.Class which is >>>> maintained as an instance field). >>>> >>>> Also, we may need to add a hook for looking for a class (like >>>> Java.type - but constructs JSClassObject instance instead). >>>>> >>>>> In addition, I guess this restriction is on Nashorn only. >>>>> Nashorn might be replaced to Graal.js . >>>> >>>> I'm not sure. If a JS implementation is module aware, it'll have >>>> the same issue. The core issue issue here we don't want >>>> public/exposed API from hotspot module. But we want to allow access >>>> to hotspot types, methods *only* from scripts => we need some sort >>>> of backdoor. I'd like JS reflection (JSObject) based backdoors >>>> rather than breaking module boundary using JNI code. >>>> >>>>> >>>>> Do we see this issue with other JS Engine? >>>>> If not so, I want to use other JS Engine (e,g, Graal). >>>> >>>> Yes, definitely no harm trying to see if other impls. have the same >>>> issue or not. >>> >>> I tried to use Graal in CLHSDB, but it did not work well. >>> Graal.js uses j.l.r.Proxy which is defined by dynamic module. >>> So I saw IllegalAccessError when CLHSDB attempt to call VM.getVM(). >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>>> Thanks, >>>> -Sundar >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> -Sundar >>>>>> >>>>>> On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I saw the message when I attached CLHSDB to target VM as below: >>>>>>> >>>>>>> ---- >>>>>>> javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM >>>>>>> is not >>>>>>> a function in sa.js at line number 54 >>>>>>> Warning! JS Engine can't start, some commands will not be >>>>>>> available. >>>>>>> ---- >>>>>>> >>>>>>> It has been reported as JDK-8157947. >>>>>>> >>>>>>> >>>>>>> It is caused that jdk.hotspot.agent module is not exported to >>>>>>> nashorn dynamic module. >>>>>>> The comment in JDK-8157947 says that it will be fixed if we >>>>>>> implement >>>>>>> JSObject, but I think it is difficult because we cannot know >>>>>>> what classes in SA are used in user scripts. >>>>>>> >>>>>>> So I think two approaches for this issue: >>>>>>> >>>>>>> >>>>>>> 1. Open all packages in module-info in jdk.hotspot.agent >>>>>>> I filed suggested fix to JBS, but it is not smart... >>>>>>> >>>>>>> 2. Open all packages in JSJavaScriptEngine:: >>>>>>> Opens all packages to Module.EVERYONE_MODULE. >>>>>>> But EVERYONE_MODULE is private field, so we need to access >>>>>>> from JNI code. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ >>>>>>> This change has passed serviceability/sa jtreg tests. >>>>>>> >>>>>>> >>>>>>> Both ideas is hackish, but I prefer to 2. to fix it. >>>>>>> If 2. is accepted I will push it to submit repo and send review >>>>>>> request. >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa From Alan.Bateman at oracle.com Thu May 2 06:30:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 May 2019 07:30:40 +0100 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: <5CCA8461.3070806@oracle.com> References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> <5CB55AD2.70106@oracle.com> <5CB93441.9080508@oracle.com> <5CCA8461.3070806@oracle.com> Message-ID: <002293ad-a845-07f3-2cd1-7473614c10f5@oracle.com> On 02/05/2019 06:47, Sundararajan Athijegannathan wrote: > Hi Yasumasa, > > Sorry for delayed response. Your webrev looks like a good start! > Unfortunately, dependency on nashorn is inevitable. But there is a > similar (but different) object API for Graal.js. In future, someone > may have to do some porting work. This exports sun.jvm.hotspot.utilities.soql.wrapper unconditionally so it's adding a JDK-specific API. Would it be possible re-outline the problem and/or include the exception that is being observed? If jdk.hotspot.agent is going to export an API then it will need a lot of javadoc work and of course a CSR (and no guarantee that the CSR would be approved because we agreed in JDK 9 that jdk.hotspot.agent would be a supported interface). -Alan From Alan.Bateman at oracle.com Thu May 2 06:59:19 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 2 May 2019 07:59:19 +0100 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: <002293ad-a845-07f3-2cd1-7473614c10f5@oracle.com> References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> <5CB55AD2.70106@oracle.com> <5CB93441.9080508@oracle.com> <5CCA8461.3070806@oracle.com> <002293ad-a845-07f3-2cd1-7473614c10f5@oracle.com> Message-ID: <060248a8-ceb1-71bb-f20a-fdde9052786f@oracle.com> On 02/05/2019 07:30, Alan Bateman wrote: > (and no guarantee that the CSR would be approved because we agreed in > JDK 9 that jdk.hotspot.agent would be a supported interface). This should say "would not be a supported interface" of course. From yasuenag at gmail.com Thu May 2 08:35:46 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Thu, 2 May 2019 17:35:46 +0900 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: <002293ad-a845-07f3-2cd1-7473614c10f5@oracle.com> References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> <5CB55AD2.70106@oracle.com> <5CB93441.9080508@oracle.com> <5CCA8461.3070806@oracle.com> <002293ad-a845-07f3-2cd1-7473614c10f5@oracle.com> Message-ID: > Would it be possible re-outline the problem and/or include the exception that is being observed? We can see TypeError thrown by Nashorn when we attach CLHSDB. It means JS in jdk.hotspot.agent (sa.js) could not call sun.jvm.hotspot.runtime.VM::getVM . It is caused that jdk.hotspot.agent does not export to jdk.scripting.nashorn.scripts module. I tried to open all SA packages to everyone, it works fine [1]. IMHO it would be convenience that module API provides method(s) to open to everyone, or --add-opens option can open modules to everyone. Anyway, I think this issue may occur any applications that JS calls Java world. Thus I hope this issue would be resolved in scripting API or module system. If so, SA should use it :-) Thanks, Yasumasa [1] http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/ On 2019/05/02 15:30, Alan Bateman wrote: > On 02/05/2019 06:47, Sundararajan Athijegannathan wrote: >> Hi Yasumasa, >> >> Sorry for delayed response. Your webrev looks like a good start! >> Unfortunately, dependency on nashorn is inevitable. But there is a >> similar (but different) object API for Graal.js. In future, someone >> may have to do some porting work. > This exports sun.jvm.hotspot.utilities.soql.wrapper unconditionally so > it's adding a JDK-specific API. Would it be possible re-outline the > problem and/or include the exception that is being observed? If > jdk.hotspot.agent is going to export an API then it will need a lot of > javadoc work and of course a CSR (and no guarantee that the CSR would be > approved because we agreed in JDK 9 that jdk.hotspot.agent would be a > supported interface). > > -Alan From gary.adams at oracle.com Thu May 2 11:56:42 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 02 May 2019 07:56:42 -0400 Subject: RFR: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> Message-ID: <5CCADAFA.2060802@oracle.com> It would be good to include a comment that the thread start is being allowed because of graal. Now that we have a series of graal specific alterations in the tests, it might be useful to provide some reusable filters. $.02 On 5/1/19, 9:07 PM, Daniil Titov wrote: > Please review the change that fixes the test that intermittently fails with Graal on. > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Daniil > > From daniil.x.titov at oracle.com Thu May 2 16:48:26 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 02 May 2019 09:48:26 -0700 Subject: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <5CCADAFA.2060802@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> <5CCADAFA.2060802@oracle.com> Message-ID: <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> Hi Gary, Please review a new version of the webrev that adds the comment you mentioned. Regarding the reusable filters I think it makes sense to create them when we will find that they could be reused more than in one place and this test is a quite specific, it creates ThreadStartRequest and enables it before restricting it to the test thread only (by calling addThreadFilter()) since it is exactly what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 Thanks! --Danill ?On 5/2/19, 4:56 AM, "Gary Adams" wrote: It would be good to include a comment that the thread start is being allowed because of graal. Now that we have a series of graal specific alterations in the tests, it might be useful to provide some reusable filters. $.02 On 5/1/19, 9:07 PM, Daniil Titov wrote: > Please review the change that fixes the test that intermittently fails with Graal on. > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Daniil > > From gary.adams at oracle.com Thu May 2 17:08:30 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 02 May 2019 13:08:30 -0400 Subject: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> <5CCADAFA.2060802@oracle.com> <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> Message-ID: <5CCB240E.7010903@oracle.com> Looks good to me. BTW, how did you track down this failure. Did you use some tracing option, or did you add a diagnostic to dump the stray event? On 5/2/19, 12:48 PM, Daniil Titov wrote: > Hi Gary, > > Please review a new version of the webrev that adds the comment you mentioned. > > Regarding the reusable filters I think it makes sense to create them when we will find that they could be reused more than in one place and this test is a quite specific, it creates ThreadStartRequest and enables it before restricting it to the test thread only (by calling addThreadFilter()) since it is exactly what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Danill > > ?On 5/2/19, 4:56 AM, "Gary Adams" wrote: > > It would be good to include a comment that the thread start is being > allowed because of graal. > > Now that we have a series of graal specific alterations in the tests, > it might be useful to provide some reusable filters. $.02 > > On 5/1/19, 9:07 PM, Daniil Titov wrote: > > Please review the change that fixes the test that intermittently fails with Graal on. > > > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > Thanks! > > --Daniil > > > > > > > > > From daniil.x.titov at oracle.com Thu May 2 17:14:37 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 02 May 2019 10:14:37 -0700 Subject: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <5CCB240E.7010903@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> <5CCADAFA.2060802@oracle.com> <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> <5CCB240E.7010903@oracle.com> Message-ID: <711FEC20-CED0-473E-AA2C-166D7108CF02@oracle.com> Hi Gary, Thank you for reviewing this. I added a diagnostic that dumped this unexpected event and printed the thread name that caused it. Best regards, Daniil ?On 5/2/19, 10:08 AM, "Gary Adams" wrote: Looks good to me. BTW, how did you track down this failure. Did you use some tracing option, or did you add a diagnostic to dump the stray event? On 5/2/19, 12:48 PM, Daniil Titov wrote: > Hi Gary, > > Please review a new version of the webrev that adds the comment you mentioned. > > Regarding the reusable filters I think it makes sense to create them when we will find that they could be reused more than in one place and this test is a quite specific, it creates ThreadStartRequest and enables it before restricting it to the test thread only (by calling addThreadFilter()) since it is exactly what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Danill > > ?On 5/2/19, 4:56 AM, "Gary Adams" wrote: > > It would be good to include a comment that the thread start is being > allowed because of graal. > > Now that we have a series of graal specific alterations in the tests, > it might be useful to provide some reusable filters. $.02 > > On 5/1/19, 9:07 PM, Daniil Titov wrote: > > Please review the change that fixes the test that intermittently fails with Graal on. > > > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > Thanks! > > --Daniil > > > > > > > > > From chris.plummer at oracle.com Thu May 2 17:18:02 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 2 May 2019 10:18:02 -0700 Subject: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> <5CCADAFA.2060802@oracle.com> <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> Message-ID: <4e7c53b1-484b-f7a3-ffd5-49609f74e400@oracle.com> Looks good. Chris On 5/2/19 9:48 AM, Daniil Titov wrote: > Hi Gary, > > Please review a new version of the webrev that adds the comment you mentioned. > > Regarding the reusable filters I think it makes sense to create them when we will find that they could be reused more than in one place and this test is a quite specific, it creates ThreadStartRequest and enables it before restricting it to the test thread only (by calling addThreadFilter()) since it is exactly what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Danill > > ?On 5/2/19, 4:56 AM, "Gary Adams" wrote: > > It would be good to include a comment that the thread start is being > allowed because of graal. > > Now that we have a series of graal specific alterations in the tests, > it might be useful to provide some reusable filters. $.02 > > On 5/1/19, 9:07 PM, Daniil Titov wrote: > > Please review the change that fixes the test that intermittently fails with Graal on. > > > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > Thanks! > > --Daniil > > > > > > > > > From serguei.spitsyn at oracle.com Thu May 2 19:30:35 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 May 2019 12:30:35 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: References: <0030533b-74f0-9572-d28a-fc99ebfbcafc@oracle.com> Message-ID: <3cf853d4-0153-2ec0-8f4d-6ff4c02fc93d@oracle.com> Hi David and Nan, Sorry, my suggestion was not aligned with usual practice and added some extra work. :( Thanks, Serguei On 5/1/19 19:42, David Holmes wrote: > On 2/05/2019 11:00 am, Man Cao wrote: >> Thank everyone for the review! >> Renamed and final webrev: >> https://cr.openjdk.java.net/~manc/8223177/webrev.02/ > > No do not rename! Sorry Serguei but for these accesses with > OrderAccess semantics the placement of the acquire/release reflects > the barrier semantics of load_acquire and release_store. So we use > foo_acquire to load foo with acquire semantics; while release_set_foo > performs a release barrier followed by set_foo. This convention is > used throughout the VM for these kinds of methods. > > David > ----- > >> -Man >> >> >> On Wed, May 1, 2019 at 5:21 PM serguei.spitsyn at oracle.com >> > > wrote: >> >> ??? Hi Man, >> >> ??? Looks good to me. >> >> ??? Minor comment: >> ??? I'd suggest to rename tag_map_acquire to acquire_tag_map to be >> ??? consistent with release_set_tag_map. >> >> >> ??? Thanks, >> ??? Serguei >> >> >> ??? On 4/30/19 18:51, Man Cao wrote: >>> ??? Hi all, >>> >>> ??? Can I have reviews for this small change that adds memory fences >>> ??? for double-checked locking? >>> ??? We found this race while working on the Java ThreadSanitizer >>> project. >>> >>> ??? Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ >>> ??? Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 >>> >>> ??? -Man >> From manc at google.com Thu May 2 19:49:50 2019 From: manc at google.com (Man Cao) Date: Thu, 2 May 2019 12:49:50 -0700 Subject: RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking In-Reply-To: <3cf853d4-0153-2ec0-8f4d-6ff4c02fc93d@oracle.com> References: <0030533b-74f0-9572-d28a-fc99ebfbcafc@oracle.com> <3cf853d4-0153-2ec0-8f4d-6ff4c02fc93d@oracle.com> Message-ID: No worries. This helps clarify the naming practices so we are on the same page in the future. -Man On Thu, May 2, 2019 at 12:30 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi David and Nan, > > Sorry, my suggestion was not aligned with usual practice and added some > extra work. :( > > Thanks, > Serguei > > > On 5/1/19 19:42, David Holmes wrote: > > On 2/05/2019 11:00 am, Man Cao wrote: > >> Thank everyone for the review! > >> Renamed and final webrev: > >> https://cr.openjdk.java.net/~manc/8223177/webrev.02/ > > > > No do not rename! Sorry Serguei but for these accesses with > > OrderAccess semantics the placement of the acquire/release reflects > > the barrier semantics of load_acquire and release_store. So we use > > foo_acquire to load foo with acquire semantics; while release_set_foo > > performs a release barrier followed by set_foo. This convention is > > used throughout the VM for these kinds of methods. > > > > David > > ----- > > > >> -Man > >> > >> > >> On Wed, May 1, 2019 at 5:21 PM serguei.spitsyn at oracle.com > >> >> > wrote: > >> > >> Hi Man, > >> > >> Looks good to me. > >> > >> Minor comment: > >> I'd suggest to rename tag_map_acquire to acquire_tag_map to be > >> consistent with release_set_tag_map. > >> > >> > >> Thanks, > >> Serguei > >> > >> > >> On 4/30/19 18:51, Man Cao wrote: > >>> Hi all, > >>> > >>> Can I have reviews for this small change that adds memory fences > >>> for double-checked locking? > >>> We found this race while working on the Java ThreadSanitizer > >>> project. > >>> > >>> Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/ > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223177 > >>> > >>> -Man > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manc at google.com Thu May 2 19:50:39 2019 From: manc at google.com (Man Cao) Date: Thu, 2 May 2019 12:50:39 -0700 Subject: RFR (XS): 8223227: Rename acquire_tag_map() to tag_map_acquire() in jvmtiEnvBase In-Reply-To: <6c7ac0fa-8b44-292c-fe6e-328d265a3de6@oracle.com> References: <6c7ac0fa-8b44-292c-fe6e-328d265a3de6@oracle.com> Message-ID: Thank both for the review. -Man -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu May 2 23:03:33 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 2 May 2019 16:03:33 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> Message-ID: Hi Serguei, Thanks for the review, I fixed the bug name but have not yet changed the webrev. Does anyone else have an opinion of the naming of the tests? Thanks all! Jc On Tue, Apr 30, 2019 at 5:10 PM wrote: > Hi Jc, > > I'd suggest to change the bug title to be: > Add a AsyncGetCallTrace test > > I'm not sure about the test names. > Maybe, it is Okay to keep the AGCT abbreviation. > But I'd like to hear other opinions. > > Thanks, > Serguei > > On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: > > Hi all, > > As I start looking at working on the AGCT bugs, I wanted to at least start > creating a baseline of tests for AGCT. This is an attempt to just have a > "base" test (and infrastructure) that tries to call AGCT and get back some > sane information. > > Next step will be to add a few more tests that will be exposing the > limitations of https://bugs.openjdk.java.net/browse/JDK-8178287 for > example. > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 > > This passed the test on my linux machine (the test is only for linux due > to the dlsym) and the submit-repo. > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 2 23:23:30 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 May 2019 16:23:30 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> Message-ID: <00c9ff0d-3c5b-06f6-f006-67bc005f2b7d@oracle.com> Hi Jc, I've not reviewed it yet but it is on my list. Thanks, Serguei On 5/2/19 4:03 PM, Jean Christophe Beyler wrote: > Hi Serguei, > > Thanks for the review, I fixed the bug name but have not yet changed > the webrev. Does anyone else have an opinion of the naming of the tests? > > Thanks all! > Jc > > On Tue, Apr 30, 2019 at 5:10 PM > wrote: > > Hi Jc, > > I'd suggest to change the bug title to be: > ?? Add a AsyncGetCallTrace test > > I'm not sure about the test names. > Maybe, it is Okay to keep the AGCT abbreviation. > But I'd like to hear other opinions. > > Thanks, > Serguei > > On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >> Hi all, >> >> As I start looking at working on the AGCT bugs, I wanted to at >> least start creating a baseline of tests for AGCT. This is an >> attempt to just have a "base" test (and infrastructure) that >> tries to call AGCT and get back some sane information. >> >> Next step will be to add a few more tests that will be exposing >> the limitations of >> https://bugs.openjdk.java.net/browse/JDK-8178287?for example. >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >> >> This passed the test on my linux machine (the test is only for >> linux due to the dlsym) and the submit-repo. >> >> Thanks, >> Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Thu May 2 23:55:07 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 May 2019 19:55:07 -0400 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> Message-ID: I would use "AsyncGetCallTrace" for the top level directory name. That would make it easier for someone searching the test space... Dan On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: > Hi Serguei, > > Thanks for the review, I fixed the bug name but have not yet changed > the webrev. Does anyone else have an opinion of the naming of the tests? > > Thanks all! > Jc > > On Tue, Apr 30, 2019 at 5:10 PM > wrote: > > Hi Jc, > > I'd suggest to change the bug title to be: > ?? Add a AsyncGetCallTrace test > > I'm not sure about the test names. > Maybe, it is Okay to keep the AGCT abbreviation. > But I'd like to hear other opinions. > > Thanks, > Serguei > > On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >> Hi all, >> >> As I start looking at working on the AGCT bugs, I wanted to at >> least start creating a baseline of tests for AGCT. This is an >> attempt to just have a "base" test (and infrastructure) that >> tries to call AGCT and get back some sane information. >> >> Next step will be to add a few more tests that will be exposing >> the limitations of >> https://bugs.openjdk.java.net/browse/JDK-8178287?for example. >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >> >> This passed the test on my linux machine (the test is only for >> linux due to the dlsym) and the submit-repo. >> >> Thanks, >> Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 3 00:13:48 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 May 2019 17:13:48 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> Message-ID: <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> God suggestion! Thanks, Serguei On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: > I would use "AsyncGetCallTrace" for the top level directory name. > That would make it easier for someone searching the test space... > > Dan > > > On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: >> Hi Serguei, >> >> Thanks for the review, I fixed the bug name but have not yet changed >> the webrev. Does anyone else have an opinion of the naming of the tests? >> >> Thanks all! >> Jc >> >> On Tue, Apr 30, 2019 at 5:10 PM > > wrote: >> >> Hi Jc, >> >> I'd suggest to change the bug title to be: >> ?? Add a AsyncGetCallTrace test >> >> I'm not sure about the test names. >> Maybe, it is Okay to keep the AGCT abbreviation. >> But I'd like to hear other opinions. >> >> Thanks, >> Serguei >> >> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >>> Hi all, >>> >>> As I start looking at working on the AGCT bugs, I wanted to at >>> least start creating a baseline of tests for AGCT. This is an >>> attempt to just have a "base" test (and infrastructure) that >>> tries to call AGCT and get back some sane information. >>> >>> Next step will be to add a few more tests that will be exposing >>> the limitations of >>> https://bugs.openjdk.java.net/browse/JDK-8178287?for example. >>> >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>> >>> This passed the test on my linux machine (the test is only for >>> linux due to the dlsym) and the submit-repo. >>> >>> Thanks, >>> Jc >> >> >> >> -- >> >> Thanks, >> Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 3 00:16:22 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 May 2019 17:16:22 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> Message-ID: <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> On 5/2/19 5:13 PM, serguei.spitsyn at oracle.com wrote: > God suggestion! Above is a typo, I wanted to say "Good suggestion". But the typo is funny. :) Thanks, Serguei > > Thanks, > Serguei > > On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: >> I would use "AsyncGetCallTrace" for the top level directory name. >> That would make it easier for someone searching the test space... >> >> Dan >> >> >> On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: >>> Hi Serguei, >>> >>> Thanks for the review, I fixed the bug name but have not yet changed >>> the webrev. Does anyone else have an opinion of the naming of the >>> tests? >>> >>> Thanks all! >>> Jc >>> >>> On Tue, Apr 30, 2019 at 5:10 PM >> > wrote: >>> >>> Hi Jc, >>> >>> I'd suggest to change the bug title to be: >>> ?? Add a AsyncGetCallTrace test >>> >>> I'm not sure about the test names. >>> Maybe, it is Okay to keep the AGCT abbreviation. >>> But I'd like to hear other opinions. >>> >>> Thanks, >>> Serguei >>> >>> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >>>> Hi all, >>>> >>>> As I start looking at working on the AGCT bugs, I wanted to at >>>> least start creating a baseline of tests for AGCT. This is an >>>> attempt to just have a "base" test (and infrastructure) that >>>> tries to call AGCT and get back some sane information. >>>> >>>> Next step will be to add a few more tests that will be exposing >>>> the limitations of >>>> https://bugs.openjdk.java.net/browse/JDK-8178287?for example. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>>> >>>> This passed the test on my linux machine (the test is only for >>>> linux due to the dlsym) and the submit-repo. >>>> >>>> Thanks, >>>> Jc >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 3 00:24:57 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 May 2019 17:24:57 -0700 Subject: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> <5CCADAFA.2060802@oracle.com> <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> Message-ID: <6dbf8f96-cc0f-fefb-ef21-c0254a9608db@oracle.com> Hi Daniil, Could you, please, replace 'e' with 'event'? I've never liked one-letter identifiers. Other than that it looks good to me. Thanks, Serguei On 5/2/19 9:48 AM, Daniil Titov wrote: > Hi Gary, > > Please review a new version of the webrev that adds the comment you mentioned. > > Regarding the reusable filters I think it makes sense to create them when we will find that they could be reused more than in one place and this test is a quite specific, it creates ThreadStartRequest and enables it before restricting it to the test thread only (by calling addThreadFilter()) since it is exactly what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Danill > > ?On 5/2/19, 4:56 AM, "Gary Adams" wrote: > > It would be good to include a comment that the thread start is being > allowed because of graal. > > Now that we have a series of graal specific alterations in the tests, > it might be useful to provide some reusable filters. $.02 > > On 5/1/19, 9:07 PM, Daniil Titov wrote: > > Please review the change that fixes the test that intermittently fails with Graal on. > > > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > Thanks! > > --Daniil > > > > > > > > > From jcbeyler at google.com Fri May 3 00:28:36 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 2 May 2019 17:28:36 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> Message-ID: :) Sounds good to me and here is the new webrev with that naming scheme: Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 Thanks for your help! Jc On Thu, May 2, 2019 at 5:16 PM wrote: > > > On 5/2/19 5:13 PM, serguei.spitsyn at oracle.com wrote: > > God suggestion! > > > Above is a typo, I wanted to say "Good suggestion". > But the typo is funny. :) > > Thanks, > Serguei > > > Thanks, > Serguei > > On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: > > I would use "AsyncGetCallTrace" for the top level directory name. > That would make it easier for someone searching the test space... > > Dan > > > On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: > > Hi Serguei, > > Thanks for the review, I fixed the bug name but have not yet changed the > webrev. Does anyone else have an opinion of the naming of the tests? > > Thanks all! > Jc > > On Tue, Apr 30, 2019 at 5:10 PM wrote: > >> Hi Jc, >> >> I'd suggest to change the bug title to be: >> Add a AsyncGetCallTrace test >> >> I'm not sure about the test names. >> Maybe, it is Okay to keep the AGCT abbreviation. >> But I'd like to hear other opinions. >> >> Thanks, >> Serguei >> >> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >> >> Hi all, >> >> As I start looking at working on the AGCT bugs, I wanted to at least >> start creating a baseline of tests for AGCT. This is an attempt to just >> have a "base" test (and infrastructure) that tries to call AGCT and get >> back some sane information. >> >> Next step will be to add a few more tests that will be exposing the >> limitations of https://bugs.openjdk.java.net/browse/JDK-8178287 for >> example. >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >> >> This passed the test on my linux machine (the test is only for linux due >> to the dlsym) and the submit-repo. >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Fri May 3 01:09:18 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 02 May 2019 18:09:18 -0700 Subject: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <6dbf8f96-cc0f-fefb-ef21-c0254a9608db@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> <5CCADAFA.2060802@oracle.com> <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> <6dbf8f96-cc0f-fefb-ef21-c0254a9608db@oracle.com> Message-ID: <621618A0-75BF-4453-8C92-915FF161C0C8@oracle.com> Hi Serguei, Please review a new version of the fix that includes the changes you suggested. Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.03 Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 Thanks! --Daniil ?On 5/2/19, 5:24 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, Could you, please, replace 'e' with 'event'? I've never liked one-letter identifiers. Other than that it looks good to me. Thanks, Serguei On 5/2/19 9:48 AM, Daniil Titov wrote: > Hi Gary, > > Please review a new version of the webrev that adds the comment you mentioned. > > Regarding the reusable filters I think it makes sense to create them when we will find that they could be reused more than in one place and this test is a quite specific, it creates ThreadStartRequest and enables it before restricting it to the test thread only (by calling addThreadFilter()) since it is exactly what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Danill > > ?On 5/2/19, 4:56 AM, "Gary Adams" wrote: > > It would be good to include a comment that the thread start is being > allowed because of graal. > > Now that we have a series of graal specific alterations in the tests, > it might be useful to provide some reusable filters. $.02 > > On 5/1/19, 9:07 PM, Daniil Titov wrote: > > Please review the change that fixes the test that intermittently fails with Graal on. > > > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > Thanks! > > --Daniil > > > > > > > > > From serguei.spitsyn at oracle.com Fri May 3 01:13:23 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 2 May 2019 18:13:23 -0700 Subject: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: <621618A0-75BF-4453-8C92-915FF161C0C8@oracle.com> References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> <5CCADAFA.2060802@oracle.com> <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> <6dbf8f96-cc0f-fefb-ef21-c0254a9608db@oracle.com> <621618A0-75BF-4453-8C92-915FF161C0C8@oracle.com> Message-ID: Hi Daniil, Looks good. Thank you for the update. Sorry, I forgot to tell no new webrev is needed if you fix this. :) Thanks, Serguei On 5/2/19 6:09 PM, Daniil Titov wrote: > Hi Serguei, > > Please review a new version of the fix that includes the changes you suggested. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.03 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Daniil > > ?On 5/2/19, 5:24 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > Could you, please, replace 'e' with 'event'? > I've never liked one-letter identifiers. > Other than that it looks good to me. > > Thanks, > Serguei > > On 5/2/19 9:48 AM, Daniil Titov wrote: > > Hi Gary, > > > > Please review a new version of the webrev that adds the comment you mentioned. > > > > Regarding the reusable filters I think it makes sense to create them when we will find that they could be reused more than in one place and this test is a quite specific, it creates ThreadStartRequest and enables it before restricting it to the test thread only (by calling addThreadFilter()) since it is exactly what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > Thanks! > > --Danill > > > > ?On 5/2/19, 4:56 AM, "Gary Adams" wrote: > > > > It would be good to include a comment that the thread start is being > > allowed because of graal. > > > > Now that we have a series of graal specific alterations in the tests, > > it might be useful to provide some reusable filters. $.02 > > > > On 5/1/19, 9:07 PM, Daniil Titov wrote: > > > Please review the change that fixes the test that intermittently fails with Graal on. > > > > > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > > > > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > > > > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > > > > > > From Alan.Bateman at oracle.com Fri May 3 09:41:13 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 3 May 2019 10:41:13 +0100 Subject: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent In-Reply-To: References: <313584f3-6596-f7e8-7739-4fa571774922@gmail.com> <5CB439C3.6020105@oracle.com> <5CB55AD2.70106@oracle.com> <5CB93441.9080508@oracle.com> <5CCA8461.3070806@oracle.com> <002293ad-a845-07f3-2cd1-7473614c10f5@oracle.com> Message-ID: On 02/05/2019 09:35, Yasumasa Suenaga wrote: > > Would it be possible re-outline the problem and/or include the > exception that is being observed? > > We can see TypeError thrown by Nashorn when we attach CLHSDB. > It means JS in jdk.hotspot.agent (sa.js) could not call > sun.jvm.hotspot.runtime.VM::getVM . > > It is caused that jdk.hotspot.agent does not export to > jdk.scripting.nashorn.scripts module. > I tried to open all SA packages to everyone, it works fine [1]. > > IMHO it would be convenience that module API provides method(s) to > open to everyone, or --add-opens option can open modules to everyone. > > Anyway, I think this issue may occur any applications that JS calls > Java world. Thus I hope this issue would be resolved in scripting API > or module system. > If so, SA should use it :-) This version seems to be hacking into a native method used by the Module API. This is not maintainable. Sundar - do you have the IAE that Yasumasa is seeing? Is this code generated by Nashorn that can't be accessed or is it that the clhsdb launcher needs to be compiled with --add-exports or --add-opens options. From sgehwolf at redhat.com Fri May 3 12:56:16 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 03 May 2019 14:56:16 +0200 Subject: [11u] RFR: 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode Message-ID: Hi, Could I please get reviews for this JDK 11 backport? The JDK 12 change does not apply cleanly unfortunately. One hunk in ProblemList.txt didn't apply because of changed context lines. That's the only difference. Bug: https://bugs.openjdk.java.net/browse/JDK-8204308 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204308/01/webrev/ Testing: New regression test, tier1 tests on Linux x86_64 Thanks, Severin From shade at redhat.com Fri May 3 14:21:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 3 May 2019 16:21:38 +0200 Subject: [11u] RFR: 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode In-Reply-To: References: Message-ID: <42b6e702-497c-3e2f-8539-ca7b31f2b13a@redhat.com> On 5/3/19 2:56 PM, Severin Gehwolf wrote: > Hi, > > Could I please get reviews for this JDK 11 backport? The JDK 12 change > does not apply cleanly unfortunately. One hunk in ProblemList.txt > didn't apply because of changed context lines. That's the only > difference. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204308 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204308/01/webrev/ The backport looks fine. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jianglizhou at google.com Fri May 3 14:45:47 2019 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 3 May 2019 07:45:47 -0700 Subject: [11u] RFR: 8204308: SA: serviceability/sa/TestInstanceKlassSize*.java fails when running in CDS mode In-Reply-To: <42b6e702-497c-3e2f-8539-ca7b31f2b13a@redhat.com> References: <42b6e702-497c-3e2f-8539-ca7b31f2b13a@redhat.com> Message-ID: +1 Best, Jiangli *From: *Aleksey Shipilev *Date: *Fri, May 3, 2019, 7:22 AM *To: *Severin Gehwolf, jdk-updates-dev at openjdk.java.net *Cc: *serviceability-dev On 5/3/19 2:56 PM, Severin Gehwolf wrote: > > Hi, > > > > Could I please get reviews for this JDK 11 backport? The JDK 12 change > > does not apply cleanly unfortunately. One hunk in ProblemList.txt > > didn't apply because of changed context lines. That's the only > > difference. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8204308 > > webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8204308/01/webrev/ > > The backport looks fine. > > -Aleksey > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Fri May 3 14:59:43 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 3 May 2019 10:59:43 -0400 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> Message-ID: On 5/2/19 8:28 PM, Jean Christophe Beyler wrote: > :) > > Sounds good to me and here is the new webrev with that naming scheme: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/ make/test/JtregNativeHotspot.gmk ??? No comments. test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java ??? L38: ????? System.loadLibrary("AsyncGetCallTraceTest"); ??? L40: ????? System.err.println("Could not load Agct library"); ??????? The name in the error message should match the actual library name. test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp ??? L79: ? // OnClassPrepare callback to prime the jmethods for ASGCT. ??????? ASGCT used here, but never spelled out before. ??????? Also, you've been using AGCT elsewhere... ??? L107: ? if (jvmti->AddCapabilities(&caps) != JVMTI_ERROR_NONE) { ??????? Missing an error message: ????????? fprintf(stderr, "Problem adding the capabilities\n"); ??? L118: ??? fprintf(stderr, "Problem adding the capabilities\n"); ??????? typo: s/capabilities/callbacks/ ??? L125: ??? fprintf(stderr, "Problem setting the class loading event.\n"); ??????? typo: s/loading/load/ ??? L132: ??? fprintf(stderr, "Problem setting the class loading event.\n"); ??????? typo: s/loading/prepare/ ??? L161: // A copy of the ASGCT data structures. ??????? I thought I put a copy of the header file into the repo... ??? L165: } ASGCT_CallFrame; ??????? I screwed up when I used "ASGCT_" years ago... Can't fix it now. Your call on whether to fix the minor issues above. I don't need to see a new webrev if you do. Thumbs up. Dan > Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 > > Thanks for your help! > Jc > > On Thu, May 2, 2019 at 5:16 PM > wrote: > > > > On 5/2/19 5:13 PM, serguei.spitsyn at oracle.com > wrote: >> God suggestion! > > Above is a typo, I wanted to say "Good suggestion". > But the typo is funny. :) > > Thanks, > Serguei > >> >> Thanks, >> Serguei >> >> On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: >>> I would use "AsyncGetCallTrace" for the top level directory name. >>> That would make it easier for someone searching the test space... >>> >>> Dan >>> >>> >>> On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: >>>> Hi Serguei, >>>> >>>> Thanks for the review, I fixed the bug name but have not yet >>>> changed the webrev. Does anyone else have an opinion of the >>>> naming of the tests? >>>> >>>> Thanks all! >>>> Jc >>>> >>>> On Tue, Apr 30, 2019 at 5:10 PM >>> > wrote: >>>> >>>> Hi Jc, >>>> >>>> I'd suggest to change the bug title to be: >>>> ?? Add a AsyncGetCallTrace test >>>> >>>> I'm not sure about the test names. >>>> Maybe, it is Okay to keep the AGCT abbreviation. >>>> But I'd like to hear other opinions. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >>>>> Hi all, >>>>> >>>>> As I start looking at working on the AGCT bugs, I wanted >>>>> to at least start creating a baseline of tests for AGCT. >>>>> This is an attempt to just have a "base" test (and >>>>> infrastructure) that tries to call AGCT and get back some >>>>> sane information. >>>>> >>>>> Next step will be to add a few more tests that will be >>>>> exposing the limitations of >>>>> https://bugs.openjdk.java.net/browse/JDK-8178287?for example. >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>>>> >>>>> This passed the test on my linux machine (the test is only >>>>> for linux due to the dlsym) and the submit-repo. >>>>> >>>>> Thanks, >>>>> Jc >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >> > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri May 3 16:37:58 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 09:37:58 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages Message-ID: The (optional) specs and man pages should have the same copyright footer as the generated API docs. This patch adds the logic to add such footers. It also removes the existing footer in jvmti.html. Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html /Erik From daniil.x.titov at oracle.com Fri May 3 16:52:44 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 03 May 2019 09:52:44 -0700 Subject: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint" In-Reply-To: References: <3ADF62FE-002B-4323-A483-B3EDF6C2B3A5@oracle.com> <5CCADAFA.2060802@oracle.com> <9100B457-29A7-4F46-88FE-41A7C843BB2F@oracle.com> <6dbf8f96-cc0f-fefb-ef21-c0254a9608db@oracle.com> <621618A0-75BF-4453-8C92-915FF161C0C8@oracle.com> Message-ID: Thank you, Serguei, Chris, JC, and Gary, for reviewing this change. Best regards, Daniil ?On 5/2/19, 6:13 PM, "serguei.spitsyn at oracle.com" wrote: Hi Daniil, Looks good. Thank you for the update. Sorry, I forgot to tell no new webrev is needed if you fix this. :) Thanks, Serguei On 5/2/19 6:09 PM, Daniil Titov wrote: > Hi Serguei, > > Please review a new version of the fix that includes the changes you suggested. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.03 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > Thanks! > --Daniil > > ?On 5/2/19, 5:24 PM, "serguei.spitsyn at oracle.com" wrote: > > Hi Daniil, > > Could you, please, replace 'e' with 'event'? > I've never liked one-letter identifiers. > Other than that it looks good to me. > > Thanks, > Serguei > > On 5/2/19 9:48 AM, Daniil Titov wrote: > > Hi Gary, > > > > Please review a new version of the webrev that adds the comment you mentioned. > > > > Regarding the reusable filters I think it makes sense to create them when we will find that they could be reused more than in one place and this test is a quite specific, it creates ThreadStartRequest and enables it before restricting it to the test thread only (by calling addThreadFilter()) since it is exactly what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > Thanks! > > --Danill > > > > ?On 5/2/19, 4:56 AM, "Gary Adams" wrote: > > > > It would be good to include a comment that the thread start is being > > allowed because of graal. > > > > Now that we have a series of graal specific alterations in the tests, > > it might be useful to provide some reusable filters. $.02 > > > > On 5/1/19, 9:07 PM, Daniil Titov wrote: > > > Please review the change that fixes the test that intermittently fails with Graal on. > > > > > > The test tests addThreadFilter() method for com.sun.jdi.ThreadStartRequest class. It starts a debuggee, creates ThreadStartRequest, enables it, and calls addThreadFilter(). The test also uses breakpoints to synchronize with the debuggee, but the problem here is that while waiting for a breakpoint event, occasionally, when Graal is on, the event the test receives is a ThreadStartEvent for " HotSpotGraalManagement Bean Registration" thread, rather than a breakpoint event. The test doesn't expect it and fails. > > > > > > The fix takes this into account and makes the test keep waiting for a breakpoint event instead of failing. > > > > > > Webrev:http://cr.openjdk.java.net/~dtitov/8222667/webrev.01/ > > > Bug:https://bugs.openjdk.java.net/browse/JDK-8222667 > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > > > > > > > > > From iris.clark at oracle.com Fri May 3 16:53:23 2019 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 3 May 2019 09:53:23 -0700 (PDT) Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: References: Message-ID: <04a8b0c5-2984-41a9-8829-59782d7ac261@default> Hi, Erik. I'm happy to see this change go in. It looks good. Just one comment. When removing the footer in jvmit.html, I suspect that you also need to make changes to jvmti.xsl, which was also modified when the copyright footer was inserted in this changeset: http://hg.openjdk.java.net/jdk/jdk/rev/9884b717f2ed Thanks, iris -----Original Message----- From: Erik Joelsson Sent: Friday, May 3, 2019 9:38 AM To: build-dev ; OpenJDK Serviceability Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages The (optional) specs and man pages should have the same copyright footer as the generated API docs. This patch adds the logic to add such footers. It also removes the existing footer in jvmti.html. Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html /Erik From erik.joelsson at oracle.com Fri May 3 17:05:02 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 10:05:02 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: <04a8b0c5-2984-41a9-8829-59782d7ac261@default> References: <04a8b0c5-2984-41a9-8829-59782d7ac261@default> Message-ID: <0080c925-b766-7ff0-4d06-0fecd3e4066f@oracle.com> Thanks Iris! I did not think about jvmti.xsl, but have removed those lines as well now. New webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.02/ /Erik On 2019-05-03 09:53, Iris Clark wrote: > Hi, Erik. > > I'm happy to see this change go in. It looks good. > > Just one comment. When removing the footer in jvmit.html, I suspect that you also need to make changes to jvmti.xsl, which was also modified when the copyright footer was inserted in this changeset: > > http://hg.openjdk.java.net/jdk/jdk/rev/9884b717f2ed > > Thanks, > iris > > -----Original Message----- > From: Erik Joelsson > Sent: Friday, May 3, 2019 9:38 AM > To: build-dev ; OpenJDK Serviceability > Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages > > The (optional) specs and man pages should have the same copyright footer as the generated API docs. This patch adds the logic to add such footers. It also removes the existing footer in jvmti.html. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 > > Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html > > /Erik > From serguei.spitsyn at oracle.com Fri May 3 17:26:49 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 10:26:49 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: References: Message-ID: Hi Erik, Could you, please, show a simple diff for jvmti.html and jdwp-protocol.html? Thanks, Serguei On 5/3/19 09:37, Erik Joelsson wrote: > The (optional) specs and man pages should have the same copyright > footer as the generated API docs. This patch adds the logic to add > such footers. It also removes the existing footer in jvmti.html. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 > > Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html > > /Erik > From erik.joelsson at oracle.com Fri May 3 18:50:08 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 11:50:08 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: References: Message-ID: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> The new footer looks exactly like on the api docs today. jvmti.html: 36481,36484c36481 --- >????
Copyright © 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.
DRAFT 13-internal+0-2019-04-29-1349399.erik.null jdwp-protocolhtml: 4071c4071 < --- >
Copyright © 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject to license terms and the documentation redistribution policy.
DRAFT 13-internal+0-2019-04-29-1349399.erik.null /Erik On 2019-05-03 10:26, serguei.spitsyn at oracle.com wrote: > Hi Erik, > > Could you, please, show a simple diff for jvmti.html and > jdwp-protocol.html? > > Thanks, > Serguei > > > On 5/3/19 09:37, Erik Joelsson wrote: >> The (optional) specs and man pages should have the same copyright >> footer as the generated API docs. This patch adds the logic to add >> such footers. It also removes the existing footer in jvmti.html. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html >> >> /Erik >> > From iris.clark at oracle.com Fri May 3 19:20:07 2019 From: iris.clark at oracle.com (Iris Clark) Date: Fri, 3 May 2019 12:20:07 -0700 (PDT) Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: <0080c925-b766-7ff0-4d06-0fecd3e4066f@oracle.com> References: <04a8b0c5-2984-41a9-8829-59782d7ac261@default> <0080c925-b766-7ff0-4d06-0fecd3e4066f@oracle.com> Message-ID: Hi, Erik. > New webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.02/ The revised webrev looks good. Thank you! Iris From jcbeyler at google.com Fri May 3 20:22:19 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 3 May 2019 13:22:19 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> Message-ID: Hi Dan, Thanks for the feedback, I fixed up all the issues you saw. Thanks! Any other reviews? Thanks all for your help! Jc On Fri, May 3, 2019 at 7:59 AM Daniel D. Daugherty < daniel.daugherty at oracle.com> wrote: > On 5/2/19 8:28 PM, Jean Christophe Beyler wrote: > > :) > > Sounds good to me and here is the new webrev with that naming scheme: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/ > > > make/test/JtregNativeHotspot.gmk > No comments. > > > test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java > L38: System.loadLibrary("AsyncGetCallTraceTest"); > L40: System.err.println("Could not load Agct library"); > The name in the error message should match the actual library name. > > > test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp > L79: // OnClassPrepare callback to prime the jmethods for ASGCT. > ASGCT used here, but never spelled out before. > Also, you've been using AGCT elsewhere... > > L107: if (jvmti->AddCapabilities(&caps) != JVMTI_ERROR_NONE) { > Missing an error message: > > fprintf(stderr, "Problem adding the capabilities\n"); > > L118: fprintf(stderr, "Problem adding the capabilities\n"); > typo: s/capabilities/callbacks/ > > L125: fprintf(stderr, "Problem setting the class loading > event.\n"); > typo: s/loading/load/ > > L132: fprintf(stderr, "Problem setting the class loading > event.\n"); > typo: s/loading/prepare/ > > L161: // A copy of the ASGCT data structures. > I thought I put a copy of the header file into the repo... > > L165: } ASGCT_CallFrame; > I screwed up when I used "ASGCT_" years ago... Can't fix it now. > > > Your call on whether to fix the minor issues above. I don't need to > see a new webrev if you do. > > Thumbs up. > > Dan > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 > > Thanks for your help! > Jc > > On Thu, May 2, 2019 at 5:16 PM wrote: > >> >> >> On 5/2/19 5:13 PM, serguei.spitsyn at oracle.com wrote: >> >> God suggestion! >> >> >> Above is a typo, I wanted to say "Good suggestion". >> But the typo is funny. :) >> >> Thanks, >> Serguei >> >> >> Thanks, >> Serguei >> >> On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: >> >> I would use "AsyncGetCallTrace" for the top level directory name. >> That would make it easier for someone searching the test space... >> >> Dan >> >> >> On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: >> >> Hi Serguei, >> >> Thanks for the review, I fixed the bug name but have not yet changed the >> webrev. Does anyone else have an opinion of the naming of the tests? >> >> Thanks all! >> Jc >> >> On Tue, Apr 30, 2019 at 5:10 PM wrote: >> >>> Hi Jc, >>> >>> I'd suggest to change the bug title to be: >>> Add a AsyncGetCallTrace test >>> >>> I'm not sure about the test names. >>> Maybe, it is Okay to keep the AGCT abbreviation. >>> But I'd like to hear other opinions. >>> >>> Thanks, >>> Serguei >>> >>> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >>> >>> Hi all, >>> >>> As I start looking at working on the AGCT bugs, I wanted to at least >>> start creating a baseline of tests for AGCT. This is an attempt to just >>> have a "base" test (and infrastructure) that tries to call AGCT and get >>> back some sane information. >>> >>> Next step will be to add a few more tests that will be exposing the >>> limitations of https://bugs.openjdk.java.net/browse/JDK-8178287 for >>> example. >>> >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>> >>> This passed the test on my linux machine (the test is only for linux due >>> to the dlsym) and the submit-repo. >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 3 20:35:11 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 13:35:11 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> References: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> Message-ID: <9485ec04-4860-7c78-4073-a3caaaa06608@oracle.com> Thank you, Erik. Is it the same with the jdwp-protocol.html? If so then I'm Okay with the fix. Thanks, Serguei On 5/3/19 11:50 AM, Erik Joelsson wrote: > The new footer looks exactly like on the api docs today. > > jvmti.html: > > 36481,36484c36481 > > rights reserved. > > > --- > >????
Copyright © > 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood > Shores, CA 94065 USA.
All rights reserved. Use is subject to href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license > terms and the href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation > redistribution policy.
DRAFT > 13-internal+0-2019-04-29-1349399.erik.null > > jdwp-protocolhtml: > > 4071c4071 > < > --- > >
Copyright © 1993, > 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood > Shores, CA 94065 USA.
All rights reserved. Use is subject to href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license > terms and the href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation > redistribution policy.
DRAFT > 13-internal+0-2019-04-29-1349399.erik.null > > /Erik > > On 2019-05-03 10:26, serguei.spitsyn at oracle.com wrote: >> Hi Erik, >> >> Could you, please, show a simple diff for jvmti.html and >> jdwp-protocol.html? >> >> Thanks, >> Serguei >> >> >> On 5/3/19 09:37, Erik Joelsson wrote: >>> The (optional) specs and man pages should have the same copyright >>> footer as the generated API docs. This patch adds the logic to add >>> such footers. It also removes the existing footer in jvmti.html. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html >>> >>> /Erik >>> >> From erik.joelsson at oracle.com Fri May 3 21:00:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 May 2019 14:00:44 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: <9485ec04-4860-7c78-4073-a3caaaa06608@oracle.com> References: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> <9485ec04-4860-7c78-4073-a3caaaa06608@oracle.com> Message-ID: I posted the diff for jdwp-protocol.html below too (but I forgot the dot in the filename). That file currently does not have any copyright visible in html, but the new footer looks the same (except for having a different relative path in the link to copyright.html). /Erik On 2019-05-03 13:35, serguei.spitsyn at oracle.com wrote: > Thank you, Erik. > Is it the same with the jdwp-protocol.html? > If so then I'm Okay with the fix. > > Thanks, > Serguei > > > On 5/3/19 11:50 AM, Erik Joelsson wrote: >> The new footer looks exactly like on the api docs today. >> >> jvmti.html: >> >> 36481,36484c36481 >> >> > rights reserved. >> >> >> --- >> >????
Copyright © >> 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood >> Shores, CA 94065 USA.
All rights reserved. Use is subject to > href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license >> terms and the > href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation >> redistribution policy.
DRAFT >> 13-internal+0-2019-04-29-1349399.erik.null >> >> jdwp-protocolhtml: >> >> 4071c4071 >> < >> --- >> >
Copyright © >> 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, Redwood >> Shores, CA 94065 USA.
All rights reserved. Use is subject to > href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license >> terms and the > href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation >> redistribution policy.
DRAFT >> 13-internal+0-2019-04-29-1349399.erik.null >> >> /Erik >> >> On 2019-05-03 10:26, serguei.spitsyn at oracle.com wrote: >>> Hi Erik, >>> >>> Could you, please, show a simple diff for jvmti.html and >>> jdwp-protocol.html? >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/3/19 09:37, Erik Joelsson wrote: >>>> The (optional) specs and man pages should have the same copyright >>>> footer as the generated API docs. This patch adds the logic to add >>>> such footers. It also removes the existing footer in jvmti.html. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html >>>> >>>> /Erik >>>> >>> > From serguei.spitsyn at oracle.com Fri May 3 21:50:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 14:50:51 -0700 Subject: RFR: JDK-8223319: Add copyright footer to specs and man pages In-Reply-To: References: <18495294-3cd0-abee-90fe-500949fd8b08@oracle.com> <9485ec04-4860-7c78-4073-a3caaaa06608@oracle.com> Message-ID: <51ade44c-1e18-d7fd-fcf7-8fc257d953a5@oracle.com> On 5/3/19 2:00 PM, Erik Joelsson wrote: > I posted the diff for jdwp-protocol.html below too (but I forgot the > dot in the filename). That file currently does not have any copyright > visible in html, but the new footer looks the same (except for having > a different relative path in the link to copyright.html). Oh, thanks! I overlooked the second file name. So, I'm Okay with the fix. Thanks, Serguei > > /Erik > > On 2019-05-03 13:35, serguei.spitsyn at oracle.com wrote: >> Thank you, Erik. >> Is it the same with the jdwp-protocol.html? >> If so then I'm Okay with the fix. >> >> Thanks, >> Serguei >> >> >> On 5/3/19 11:50 AM, Erik Joelsson wrote: >>> The new footer looks exactly like on the api docs today. >>> >>> jvmti.html: >>> >>> 36481,36484c36481 >>> >>> >> rights reserved. >>> >>> >>> --- >>> >????
Copyright © >>> 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, >>> Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject >>> to >> href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license >>> terms and the >> href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation >>> redistribution policy.
DRAFT >>> 13-internal+0-2019-04-29-1349399.erik.null >>> >>> jdwp-protocolhtml: >>> >>> 4071c4071 >>> < >>> --- >>> >
Copyright © >>> 1993, 2019, Oracle and/or its affiliates, 500 Oracle Parkway, >>> Redwood Shores, CA 94065 USA.
All rights reserved. Use is subject >>> to >> href="https://www.oracle.com/technetwork/java/javase/terms/license/java13speclicense.html">license >>> terms and the >> href="https://www.oracle.com/technetwork/java/redist-137594.html">documentation >>> redistribution policy.
DRAFT >>> 13-internal+0-2019-04-29-1349399.erik.null >>> >>> /Erik >>> >>> On 2019-05-03 10:26, serguei.spitsyn at oracle.com wrote: >>>> Hi Erik, >>>> >>>> Could you, please, show a simple diff for jvmti.html and >>>> jdwp-protocol.html? >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/3/19 09:37, Erik Joelsson wrote: >>>>> The (optional) specs and man pages should have the same copyright >>>>> footer as the generated API docs. This patch adds the logic to add >>>>> such footers. It also removes the existing footer in jvmti.html. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223319 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~erikj/8223319/webrev.01/index.html >>>>> >>>>> /Erik >>>>> >>>> >> From serguei.spitsyn at oracle.com Fri May 3 22:53:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 15:53:36 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> Message-ID: Hi Jc, Thank you a lot for taking care about this! It is the first test, and, probably, you will add more. So, I want to know about the naming approach for AsyncGetCallTrace**tests. Name suffixes will be needed for new tests. So, you can keep generic name for this one or name it as AsyncGetCallTraceBaseTest. New tests may take arbitrary names or be named as AsyncGetCallTraceTest.java (which look long). As you already have a specific folder the test names with suffixes can be shortened with something like: ?? ASGCTBaseTest.java, ASGCTTest.java, etc. I'm Okay with any approach but wanted to highlight we have some choices here. Some minor comments: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/raw_files/new/test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java System.err.println("Could not load Agct library"); Would it better to print real library name? : System.err.println("Could not load AsyncGetCallTraceTest library"); http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp.html If JVMTI GetClassMethods ever returns an error it is better to be printed. Also, the locals method_count and class_count need to be initialized (with 0 or -1). 81 if (jvmti->GetLoadedClasses(&class_count, classes.get_addr()) != JVMTI_ERROR_NONE) { 82 fprintf(stderr, "Problem getting all loaded classes\n"); 83 return; 84 } I'd suggest more explicit style to report JVMTI errors to provide a better context: jvmtiError err; err = jvmti->GetLoadedClasses(&class_count, classes.get_addr()); if (err != JVMTI_ERROR_NONE) { fprintf(stderr, "OnVMInit: Error in GetLoadedClasses: %d\n", err); return; } 195 fprintf(stderr, "the num_frames is negative: %d\n", trace.num_frames); Better to replace "is negative" with "must be positive". 199 if (trace.frames[0].lineno != -3) { 200 fprintf(stderr, "lineno is not -3 as expected: %d\n", trace.frames[0].lineno); 201 return false; 202 } ?Why lineno is expected to be -3? ?Could be nice to add a comment with a simple explanation. 210 jvmti->GetMethodName(trace.frames[0].method_id, name.get_addr(), NULL, NULL); The returned jvmtiError needs to be checked and handled. Also, it would be nice to check and print the frames returned by ASGCT. Thanks, Serguei On 5/3/19 1:22 PM, Jean Christophe Beyler wrote: > Hi Dan, > > Thanks for the feedback, I fixed up all the issues you saw. Thanks! > > Any other reviews? > > Thanks all for your help! > Jc > > On Fri, May 3, 2019 at 7:59 AM Daniel D. Daugherty > > wrote: > > On 5/2/19 8:28 PM, Jean Christophe Beyler wrote: >> :) >> >> Sounds good to me and here is the new webrev with that naming scheme: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/ >> > > make/test/JtregNativeHotspot.gmk > ??? No comments. > > test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java > ??? L38: System.loadLibrary("AsyncGetCallTraceTest"); > ??? L40: ????? System.err.println("Could not load Agct library"); > ??????? The name in the error message should match the actual > library name. > > test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp > ??? L79: ? // OnClassPrepare callback to prime the jmethods for ASGCT. > ??????? ASGCT used here, but never spelled out before. > ??????? Also, you've been using AGCT elsewhere... > > ??? L107: ? if (jvmti->AddCapabilities(&caps) != JVMTI_ERROR_NONE) { > ??????? Missing an error message: > > ????????? fprintf(stderr, "Problem adding the capabilities\n"); > > ??? L118: ??? fprintf(stderr, "Problem adding the capabilities\n"); > ??????? typo: s/capabilities/callbacks/ > > ??? L125: ??? fprintf(stderr, "Problem setting the class loading > event.\n"); > ??????? typo: s/loading/load/ > > ??? L132: ??? fprintf(stderr, "Problem setting the class loading > event.\n"); > ??????? typo: s/loading/prepare/ > > ??? L161: // A copy of the ASGCT data structures. > ??????? I thought I put a copy of the header file into the repo... > > ??? L165: } ASGCT_CallFrame; > ??????? I screwed up when I used "ASGCT_" years ago... Can't fix > it now. > > > Your call on whether to fix the minor issues above. I don't need to > see a new webrev if you do. > > Thumbs up. > > Dan > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >> >> Thanks for your help! >> Jc >> >> On Thu, May 2, 2019 at 5:16 PM > > wrote: >> >> >> >> On 5/2/19 5:13 PM, serguei.spitsyn at oracle.com >> wrote: >>> God suggestion! >> >> Above is a typo, I wanted to say "Good suggestion". >> But the typo is funny. :) >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> Serguei >>> >>> On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: >>>> I would use "AsyncGetCallTrace" for the top level directory >>>> name. >>>> That would make it easier for someone searching the test >>>> space... >>>> >>>> Dan >>>> >>>> >>>> On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: >>>>> Hi Serguei, >>>>> >>>>> Thanks for the review, I fixed the bug name but have not >>>>> yet changed the webrev. Does anyone else have an opinion >>>>> of the naming of the tests? >>>>> >>>>> Thanks all! >>>>> Jc >>>>> >>>>> On Tue, Apr 30, 2019 at 5:10 PM >>>>> >>>> > wrote: >>>>> >>>>> Hi Jc, >>>>> >>>>> I'd suggest to change the bug title to be: >>>>> ?? Add a AsyncGetCallTrace test >>>>> >>>>> I'm not sure about the test names. >>>>> Maybe, it is Okay to keep the AGCT abbreviation. >>>>> But I'd like to hear other opinions. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >>>>>> Hi all, >>>>>> >>>>>> As I start looking at working on the AGCT bugs, I >>>>>> wanted to at least start creating a baseline of tests >>>>>> for AGCT. This is an attempt to just have a "base" >>>>>> test (and infrastructure) that tries to call AGCT and >>>>>> get back some sane information. >>>>>> >>>>>> Next step will be to add a few more tests that will >>>>>> be exposing the limitations of >>>>>> https://bugs.openjdk.java.net/browse/JDK-8178287?for >>>>>> example. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>>>>> >>>>>> This passed the test on my linux machine (the test is >>>>>> only for linux due to the dlsym) and the submit-repo. >>>>>> >>>>>> Thanks, >>>>>> Jc >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc >>>> >>> >> >> >> >> -- >> >> Thanks, >> Jc > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 3 23:58:21 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 16:58:21 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> Message-ID: <7726d13f-a34f-eb01-c7ec-a173a9ae9404@oracle.com> On 5/3/19 7:59 AM, Daniel D. Daugherty wrote: > On 5/2/19 8:28 PM, Jean Christophe Beyler wrote: >> :) >> >> Sounds good to me and here is the new webrev with that naming scheme: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/ >> > > make/test/JtregNativeHotspot.gmk > ??? No comments. > > test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java > ??? L38: ????? System.loadLibrary("AsyncGetCallTraceTest"); > ??? L40: ????? System.err.println("Could not load Agct library"); > ??????? The name in the error message should match the actual library > name. > > test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp > ??? L79: ? // OnClassPrepare callback to prime the jmethods for ASGCT. > ??????? ASGCT used here, but never spelled out before. > ??????? Also, you've been using AGCT elsewhere... > > ??? L107: ? if (jvmti->AddCapabilities(&caps) != JVMTI_ERROR_NONE) { > ??????? Missing an error message: > > ????????? fprintf(stderr, "Problem adding the capabilities\n"); > > ??? L118: ??? fprintf(stderr, "Problem adding the capabilities\n"); > ??????? typo: s/capabilities/callbacks/ > > ??? L125: ??? fprintf(stderr, "Problem setting the class loading > event.\n"); > ??????? typo: s/loading/load/ > > ??? L132: ??? fprintf(stderr, "Problem setting the class loading > event.\n"); > ??????? typo: s/loading/prepare/ > > ??? L161: // A copy of the ASGCT data structures. > ??????? I thought I put a copy of the header file into the repo... > > ??? L165: } ASGCT_CallFrame; > ??????? I screwed up when I used "ASGCT_" years ago... Can't fix it now. I've already used to it, so would prefer to keep it everywhere. :) But never mind. Thanks, Serguei > Your call on whether to fix the minor issues above. I don't need to > see a new webrev if you do. > > Thumbs up. > > Dan > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >> >> Thanks for your help! >> Jc >> >> On Thu, May 2, 2019 at 5:16 PM > > wrote: >> >> >> >> On 5/2/19 5:13 PM, serguei.spitsyn at oracle.com >> wrote: >>> God suggestion! >> >> Above is a typo, I wanted to say "Good suggestion". >> But the typo is funny. :) >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> Serguei >>> >>> On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: >>>> I would use "AsyncGetCallTrace" for the top level directory name. >>>> That would make it easier for someone searching the test space... >>>> >>>> Dan >>>> >>>> >>>> On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: >>>>> Hi Serguei, >>>>> >>>>> Thanks for the review, I fixed the bug name but have not yet >>>>> changed the webrev. Does anyone else have an opinion of the >>>>> naming of the tests? >>>>> >>>>> Thanks all! >>>>> Jc >>>>> >>>>> On Tue, Apr 30, 2019 at 5:10 PM >>>> > wrote: >>>>> >>>>> Hi Jc, >>>>> >>>>> I'd suggest to change the bug title to be: >>>>> ?? Add a AsyncGetCallTrace test >>>>> >>>>> I'm not sure about the test names. >>>>> Maybe, it is Okay to keep the AGCT abbreviation. >>>>> But I'd like to hear other opinions. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >>>>>> Hi all, >>>>>> >>>>>> As I start looking at working on the AGCT bugs, I wanted >>>>>> to at least start creating a baseline of tests for AGCT. >>>>>> This is an attempt to just have a "base" test (and >>>>>> infrastructure) that tries to call AGCT and get back some >>>>>> sane information. >>>>>> >>>>>> Next step will be to add a few more tests that will be >>>>>> exposing the limitations of >>>>>> https://bugs.openjdk.java.net/browse/JDK-8178287?for example. >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>>>>> >>>>>> This passed the test on my linux machine (the test is >>>>>> only for linux due to the dlsym) and the submit-repo. >>>>>> >>>>>> Thanks, >>>>>> Jc >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc >>>> >>> >> >> >> >> -- >> >> Thanks, >> Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat May 4 01:14:41 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 3 May 2019 18:14:41 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> Message-ID: <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> Hi Alex, Thank you for creating the CSR! I've added myself as a reviewer and corrected a couple of places. Feel free to change my changes if necessary. :) It would be nice to get one more CSR review if possible, so I've added the net-dev mailing list. I hope to finish the webrev review soon. Thanks, Serguei On 5/1/19 10:54 AM, Alex Menkov wrote: > Hi all, > > I created CSR for the feature: > https://bugs.openjdk.java.net/browse/JDK-8223104 > > The latest webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ > > --alex From jcbeyler at google.com Sat May 4 03:42:54 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 3 May 2019 20:42:54 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> Message-ID: Hi Serguei, Here is an updated webrev with the fixes from your and Dan's comments: Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 Below are the inlined answers to your comments. On Fri, May 3, 2019 at 3:53 PM wrote: > Hi Jc, > > Thank you a lot for taking care about this! > > It is the first test, and, probably, you will add more. > Oh yes, the plan is to get to a point where we can test the failures in certain of the open bugs and then fix them and have a test that shows it is fixed... > So, I want to know about the naming approach for AsyncGetCallTrace tests. > > Name suffixes will be needed for new tests. > So, you can keep generic name for this one or name it as > AsyncGetCallTraceBaseTest. > New tests may take arbitrary names or be named as AsyncGetCallTraceTest.java > (which look long). > > As you already have a specific folder the test names with suffixes can be > shortened with something like: > ASGCTBaseTest.java, ASGCTTest.java, etc. > Done :) But I never know if I prefer AGCT or ASGCT. Right now I put ASGCT, let me know what you think. > > I'm Okay with any approach but wanted to highlight we have some choices > here. > > Some minor comments: > > > http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/raw_files/new/test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java > > System.err.println("Could not load Agct library"); > > Would it better to print real library name? : > System.err.println("Could not load AsyncGetCallTraceTest library"); > > Fixed since Dan commented about it too :) > > > http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp.html > > If JVMTI GetClassMethods ever returns an error it is better to be printed. > Done. > Also, the locals method_count and class_count need to be initialized (with > 0 or -1). > > Done. > 81 if (jvmti->GetLoadedClasses(&class_count, classes.get_addr()) != JVMTI_ERROR_NONE) { > 82 fprintf(stderr, "Problem getting all loaded classes\n"); > 83 return; > 84 } > > I'd suggest more explicit style to report JVMTI errors to provide a better context: > > jvmtiError err; > > err = jvmti->GetLoadedClasses(&class_count, classes.get_addr()); > > if (err != JVMTI_ERROR_NONE) { > fprintf(stderr, "OnVMInit: Error in GetLoadedClasses: %d\n", err); > return; > } > > Done for all calls. > > 195 fprintf(stderr, "the num_frames is negative: %d\n", trace.num_frames); > > Better to replace "is negative" with "must be positive". > > > Done > 199 if (trace.frames[0].lineno != -3) { > 200 fprintf(stderr, "lineno is not -3 as expected: %d\n", trace.frames[0].lineno); > 201 return false; > 202 } > > Why lineno is expected to be -3? > Convention of AGCT, for native frames it returns -3; I added a comment. > Could be nice to add a comment with a simple explanation. > > 210 jvmti->GetMethodName(trace.frames[0].method_id, name.get_addr(), NULL, NULL); > > The returned jvmtiError needs to be checked and handled. > > Done. > > Also, it would be nice to check and print the frames returned by ASGCT. > > That actually is a second more complete test that will test a different stack trace and check all lines; it will do something like the HeapMonitor tests where we provide the frames in Java land that we would expect to see (class/method/line number) and then ask AGCT to confirm it sees that. In this base test, I really just wanted the first frame to be checked and we leave it at that; basically the sanity check. Let me know if you'd still like to have the frames checked in this first test :-) Thanks for the review! Jc > Thanks, > Serguei > > > On 5/3/19 1:22 PM, Jean Christophe Beyler wrote: > > Hi Dan, > > Thanks for the feedback, I fixed up all the issues you saw. Thanks! > > Any other reviews? > > Thanks all for your help! > Jc > > On Fri, May 3, 2019 at 7:59 AM Daniel D. Daugherty < > daniel.daugherty at oracle.com> wrote: > >> On 5/2/19 8:28 PM, Jean Christophe Beyler wrote: >> >> :) >> >> Sounds good to me and here is the new webrev with that naming scheme: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/ >> >> >> make/test/JtregNativeHotspot.gmk >> No comments. >> >> >> test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java >> L38: System.loadLibrary("AsyncGetCallTraceTest"); >> L40: System.err.println("Could not load Agct library"); >> The name in the error message should match the actual library >> name. >> >> >> test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp >> L79: // OnClassPrepare callback to prime the jmethods for ASGCT. >> ASGCT used here, but never spelled out before. >> Also, you've been using AGCT elsewhere... >> >> L107: if (jvmti->AddCapabilities(&caps) != JVMTI_ERROR_NONE) { >> Missing an error message: >> >> fprintf(stderr, "Problem adding the capabilities\n"); >> >> L118: fprintf(stderr, "Problem adding the capabilities\n"); >> typo: s/capabilities/callbacks/ >> >> L125: fprintf(stderr, "Problem setting the class loading >> event.\n"); >> typo: s/loading/load/ >> >> L132: fprintf(stderr, "Problem setting the class loading >> event.\n"); >> typo: s/loading/prepare/ >> >> L161: // A copy of the ASGCT data structures. >> I thought I put a copy of the header file into the repo... >> >> L165: } ASGCT_CallFrame; >> I screwed up when I used "ASGCT_" years ago... Can't fix it now. >> >> >> Your call on whether to fix the minor issues above. I don't need to >> see a new webrev if you do. >> >> Thumbs up. >> >> Dan >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >> >> Thanks for your help! >> Jc >> >> On Thu, May 2, 2019 at 5:16 PM wrote: >> >>> >>> >>> On 5/2/19 5:13 PM, serguei.spitsyn at oracle.com wrote: >>> >>> God suggestion! >>> >>> >>> Above is a typo, I wanted to say "Good suggestion". >>> But the typo is funny. :) >>> >>> Thanks, >>> Serguei >>> >>> >>> Thanks, >>> Serguei >>> >>> On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: >>> >>> I would use "AsyncGetCallTrace" for the top level directory name. >>> That would make it easier for someone searching the test space... >>> >>> Dan >>> >>> >>> On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: >>> >>> Hi Serguei, >>> >>> Thanks for the review, I fixed the bug name but have not yet changed the >>> webrev. Does anyone else have an opinion of the naming of the tests? >>> >>> Thanks all! >>> Jc >>> >>> On Tue, Apr 30, 2019 at 5:10 PM wrote: >>> >>>> Hi Jc, >>>> >>>> I'd suggest to change the bug title to be: >>>> Add a AsyncGetCallTrace test >>>> >>>> I'm not sure about the test names. >>>> Maybe, it is Okay to keep the AGCT abbreviation. >>>> But I'd like to hear other opinions. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >>>> >>>> Hi all, >>>> >>>> As I start looking at working on the AGCT bugs, I wanted to at least >>>> start creating a baseline of tests for AGCT. This is an attempt to just >>>> have a "base" test (and infrastructure) that tries to call AGCT and get >>>> back some sane information. >>>> >>>> Next step will be to add a few more tests that will be exposing the >>>> limitations of https://bugs.openjdk.java.net/browse/JDK-8178287 for >>>> example. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>>> >>>> This passed the test on my linux machine (the test is only for linux >>>> due to the dlsym) and the submit-repo. >>>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sat May 4 09:53:52 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 4 May 2019 02:53:52 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> Message-ID: <451fdea5-c0bc-32b6-b1f3-998aa8145128@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Sat May 4 21:01:59 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Sat, 4 May 2019 14:01:59 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: <451fdea5-c0bc-32b6-b1f3-998aa8145128@oracle.com> References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> <451fdea5-c0bc-32b6-b1f3-998aa8145128@oracle.com> Message-ID: On Sat, May 4, 2019 at 2:53 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Jc, > > Thank you for the update! > It looks good to me. > > One question is why the .cpp name does not match the .java. > (I expected it to be libASGCTBaseTest.cpp to match ASGCTBaseTest.java). > Do you plan to keep one native agent library for all tests? > For now, I expect to do like the HeapMonitor suite because I expect a lot of code to be shared across the tests. If I'm wrong, we can divide it up later (an alternative view would be to make them match now and separate later; I'm open to both if you really have a preference) > > A couple of really minor comments (it is up to you if it need to be > handled). > > Inconsistent jvmtiEnv* parameter name (jvmti_env vs jvmti): > > 69 static void JNICALL OnClassLoad(jvmtiEnv **jvmti_env*, JNIEnv *jni_env, > 73 static void JNICALL OnClassPrepare(jvmtiEnv **jvmti_env*, JNIEnv *jni_env, > > but: > 79 static void JNICALL OnVMInit(jvmtiEnv **jvmti*, JNIEnv *jni_env, jthread thread) { > > > Our internal code this is based on is inconsistent it seems :); fixed to jvmti for all. > One more inconsistency ("Error with" vs "Error in"): > > 64 fprintf(stderr, "GetJMethodIDs: *Error with* GetClassMethods: %d\n", err); > > but: > 87 fprintf(stderr, "OnVMInit: *Error in* GetLoadedClasses: %d\n", err); > 116 fprintf(stderr, "AgentInitialize: *Error in* AddCapabilities: %d\n", err); > > > Fixed to be Error in. > No need in new webrev if you decide to fix anything from above. > Sounds good, then I'll wait to see if there are other reviews before publishing a new one :) > > Thanks, > Thank you for the reviews! > Serguei > > > On 5/3/19 20:42, Jean Christophe Beyler wrote: > > Hi Serguei, > > Here is an updated webrev with the fixes from your and Dan's comments: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 > > Below are the inlined answers to your comments. > > On Fri, May 3, 2019 at 3:53 PM wrote: > >> Hi Jc, >> >> Thank you a lot for taking care about this! >> >> It is the first test, and, probably, you will add more. >> > > Oh yes, the plan is to get to a point where we can test the failures in > certain of the open bugs and then fix them and have a test that shows it is > fixed... > > >> So, I want to know about the naming approach for AsyncGetCallTrace tests. >> >> Name suffixes will be needed for new tests. >> So, you can keep generic name for this one or name it as >> AsyncGetCallTraceBaseTest. >> New tests may take arbitrary names or be named as >> AsyncGetCallTraceTest.java (which look long). >> >> As you already have a specific folder the test names with suffixes can be >> shortened with something like: >> ASGCTBaseTest.java, ASGCTTest.java, etc. >> > > Done :) But I never know if I prefer AGCT or ASGCT. Right now I put ASGCT, > let me know what you think. > > >> >> I'm Okay with any approach but wanted to highlight we have some choices >> here. >> >> Some minor comments: >> >> >> http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/raw_files/new/test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java >> >> System.err.println("Could not load Agct library"); >> >> Would it better to print real library name? : >> System.err.println("Could not load AsyncGetCallTraceTest library"); >> >> > Fixed since Dan commented about it too :) > > >> >> >> http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp.html >> >> If JVMTI GetClassMethods ever returns an error it is better to be printed. >> > > Done. > > >> Also, the locals method_count and class_count need to be initialized >> (with 0 or -1). >> >> > Done. > > >> 81 if (jvmti->GetLoadedClasses(&class_count, classes.get_addr()) != JVMTI_ERROR_NONE) { >> 82 fprintf(stderr, "Problem getting all loaded classes\n"); >> 83 return; >> 84 } >> >> I'd suggest more explicit style to report JVMTI errors to provide a better context: >> >> jvmtiError err; >> >> err = jvmti->GetLoadedClasses(&class_count, classes.get_addr()); >> >> if (err != JVMTI_ERROR_NONE) { >> fprintf(stderr, "OnVMInit: Error in GetLoadedClasses: %d\n", err); >> return; >> } >> >> > Done for all calls. > > >> 195 fprintf(stderr, "the num_frames is negative: %d\n", trace.num_frames); >> >> Better to replace "is negative" with "must be positive". >> >> >> > Done > > >> 199 if (trace.frames[0].lineno != -3) { >> 200 fprintf(stderr, "lineno is not -3 as expected: %d\n", trace.frames[0].lineno); >> 201 return false; >> 202 } >> >> Why lineno is expected to be -3? >> > > Convention of AGCT, for native frames it returns -3; I added a comment. > > >> Could be nice to add a comment with a simple explanation. >> >> 210 jvmti->GetMethodName(trace.frames[0].method_id, name.get_addr(), NULL, NULL); >> >> The returned jvmtiError needs to be checked and handled. >> >> Done. > > >> Also, it would be nice to check and print the frames returned by ASGCT. >> >> > That actually is a second more complete test that will test a different > stack trace and check all lines; it will do something like the HeapMonitor > tests where we provide the frames in Java land that we would expect to see > (class/method/line number) and then ask AGCT to confirm it sees that. > > In this base test, I really just wanted the first frame to be checked and > we leave it at that; basically the sanity check. Let me know if you'd still > like to have the frames checked in this first test :-) > > Thanks for the review! > Jc > >> Thanks, >> Serguei >> >> >> On 5/3/19 1:22 PM, Jean Christophe Beyler wrote: >> >> Hi Dan, >> >> Thanks for the feedback, I fixed up all the issues you saw. Thanks! >> >> Any other reviews? >> >> Thanks all for your help! >> Jc >> >> On Fri, May 3, 2019 at 7:59 AM Daniel D. Daugherty < >> daniel.daugherty at oracle.com> wrote: >> >>> On 5/2/19 8:28 PM, Jean Christophe Beyler wrote: >>> >>> :) >>> >>> Sounds good to me and here is the new webrev with that naming scheme: >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.01/ >>> >>> >>> make/test/JtregNativeHotspot.gmk >>> No comments. >>> >>> >>> test/hotspot/jtreg/serviceability/AsyncGetCallTrace/MyPackage/AsyncGetCallTraceTest.java >>> L38: System.loadLibrary("AsyncGetCallTraceTest"); >>> L40: System.err.println("Could not load Agct library"); >>> The name in the error message should match the actual library >>> name. >>> >>> >>> test/hotspot/jtreg/serviceability/AsyncGetCallTrace/libAsyncGetCallTraceTest.cpp >>> L79: // OnClassPrepare callback to prime the jmethods for ASGCT. >>> ASGCT used here, but never spelled out before. >>> Also, you've been using AGCT elsewhere... >>> >>> L107: if (jvmti->AddCapabilities(&caps) != JVMTI_ERROR_NONE) { >>> Missing an error message: >>> >>> fprintf(stderr, "Problem adding the capabilities\n"); >>> >>> L118: fprintf(stderr, "Problem adding the capabilities\n"); >>> typo: s/capabilities/callbacks/ >>> >>> L125: fprintf(stderr, "Problem setting the class loading >>> event.\n"); >>> typo: s/loading/load/ >>> >>> L132: fprintf(stderr, "Problem setting the class loading >>> event.\n"); >>> typo: s/loading/prepare/ >>> >>> L161: // A copy of the ASGCT data structures. >>> I thought I put a copy of the header file into the repo... >>> >>> L165: } ASGCT_CallFrame; >>> I screwed up when I used "ASGCT_" years ago... Can't fix it now. >>> >>> >>> Your call on whether to fix the minor issues above. I don't need to >>> see a new webrev if you do. >>> >>> Thumbs up. >>> >>> Dan >>> >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>> >>> Thanks for your help! >>> Jc >>> >>> On Thu, May 2, 2019 at 5:16 PM wrote: >>> >>>> >>>> >>>> On 5/2/19 5:13 PM, serguei.spitsyn at oracle.com wrote: >>>> >>>> God suggestion! >>>> >>>> >>>> Above is a typo, I wanted to say "Good suggestion". >>>> But the typo is funny. :) >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> On 5/2/19 4:55 PM, Daniel D. Daugherty wrote: >>>> >>>> I would use "AsyncGetCallTrace" for the top level directory name. >>>> That would make it easier for someone searching the test space... >>>> >>>> Dan >>>> >>>> >>>> On 5/2/19 7:03 PM, Jean Christophe Beyler wrote: >>>> >>>> Hi Serguei, >>>> >>>> Thanks for the review, I fixed the bug name but have not yet changed >>>> the webrev. Does anyone else have an opinion of the naming of the tests? >>>> >>>> Thanks all! >>>> Jc >>>> >>>> On Tue, Apr 30, 2019 at 5:10 PM wrote: >>>> >>>>> Hi Jc, >>>>> >>>>> I'd suggest to change the bug title to be: >>>>> Add a AsyncGetCallTrace test >>>>> >>>>> I'm not sure about the test names. >>>>> Maybe, it is Okay to keep the AGCT abbreviation. >>>>> But I'd like to hear other opinions. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> On 4/30/19 3:47 PM, Jean Christophe Beyler wrote: >>>>> >>>>> Hi all, >>>>> >>>>> As I start looking at working on the AGCT bugs, I wanted to at least >>>>> start creating a baseline of tests for AGCT. This is an attempt to just >>>>> have a "base" test (and infrastructure) that tries to call AGCT and get >>>>> back some sane information. >>>>> >>>>> Next step will be to add a few more tests that will be exposing the >>>>> limitations of https://bugs.openjdk.java.net/browse/JDK-8178287 for >>>>> example. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223040/webrev.00/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223040 >>>>> >>>>> This passed the test on my linux machine (the test is only for linux >>>>> due to the dlsym) and the submit-repo. >>>>> >>>>> Thanks, >>>>> Jc >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Sat May 4 21:12:27 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Sat, 4 May 2019 14:12:27 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> Message-ID: Hi Chris and Serguei, Then the new webrev is here: Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 Let me know if now it looks good for you; @Serguei, you had said it looks good but had comments; you never answered my comment about naming; would you like me to rename all the environments to ec_jni_env? I'd do another webrev for the ones not done in this webrev but that are already under the ExceptionCheckingJniEnvPtr, let me know :) Finally, does anyone else have comments? Thanks, Jc On Tue, Apr 30, 2019 at 3:46 PM Chris Plummer wrote: > On 4/30/19 3:36 PM, Jean Christophe Beyler wrote: > > You are right I was overthinking the naming, so I did this now: > > - loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, > TRACE_JNI_CALL, className); > + loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, > TRACE_VARARGS(className)); > > Ok. I like this. > > > Question now is: this variadic won't work if there are no arguments in a > portable way, so if there are no arguments for the call, should we use a > TRACE_JNI_CALL such as: > jni_env->CallVoidMethod(thread, methodID, TRACE_JNI_CALL); > > or should I create a TRACE_VARARGS for no arguments: > jni_env->CallVoidMethod(thread, methodID, TRACE_EMPTY_VARARGS()); > > Advantage of the latter is that you would know it is a VARARG at least and > you can see it; draw-back is yet another macro. > > > What do you think? > > In general we don't know it is vararg when looking at a callsite, so I > don't feel the need to advertise it as such with TRACE_EMPTY_VARARGS(). I'd > recommend just directly passing TRACE_JNI_CALL. > > Chris > > Jc > > > > On Tue, Apr 30, 2019 at 11:37 AM Chris Plummer > wrote: > >> Hi JC, >> >> I'm not sure why you are suggesting TRACED_JNI_CALL instead of >> TRACED_VARARGS. How are they different? Are you suggesting non-varargs >> calls would just end up using an empty TRACED_JNI_CALL()? >> >> Chris >> >> On 4/30/19 10:05 AM, Jean Christophe Beyler wrote: >> >> I do have more of these coming and there are 86 CallXMethod cases where >> this will occur and 49 NewObject cases. So it would be good to figure out >> something that does not hurt our eyes too many times. >> >> I think I would go with the TRACED_VARARGS, it at least has the advantage >> of not being too bad. I would move toward doing: >> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >> methodID, TRACED_JNI_CALL(className)); >> >> To be consisted with the non-vararg cases, what do you think? >> >> Jc >> >> On Tue, Apr 30, 2019 at 9:51 AM Chris Plummer >> wrote: >> >>> The advantage of the TRACED_VARARGS approach (or leaving it as-is) is >>> that there are limited APIs and callsites affected (only 1 of each in this >>> review, but it's unclear to me if you have more of these changes coming). >>> >>> Chris >>> >>> On 4/29/19 9:49 PM, Jean Christophe Beyler wrote: >>> >>> Yes I would fix them all in the next webrev and then continue the >>> porting. I 100% agree to which is less offensive. I find that >>> >>> 73 loadedClass = (jclass) jni_env->CALLOBJECTMETHODTRACED(loader, >>> methodID, className); >>> >>> to be offensive as well. >>> >>> So perhaps the TRACED_VARARGS is best: >>> >>> >>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>> methodID, TRACED_VARARGS(className)); >>> >>> What do you think? >>> >>> >>> On Mon, Apr 29, 2019 at 9:44 PM Chris Plummer >>> wrote: >>> >>>> Hi JC, >>>> >>>> On 4/29/19 4:25 PM, Jean Christophe Beyler wrote: >>>> >>>> Hi Chris, >>>> >>>> I agree it's not ideal, how about putting it first? >>>> >>>> 73 loadedClass = (jclass) >>>> jni_env->CallObjectMethod(TRACE_JNI_CALL, loader, methodID, className); >>>> >>>> It's not consistent with other uses, or are you suggesting changing >>>> them all? >>>> >>>> >>>> I find that less awkward than the VAR_ARGS, no? >>>> >>>> Or something like: >>>> 73 loadedClass = (jclass) jni_env->CallObjectMethodTraced(loader, >>>> methodID, className); >>>> >>>> Where CallObjectMethodTraced is actually a define in the exception >>>> handling system that adds the line and filename... >>>> >>>> I don't like macroizing a method call in this manner (macros should be >>>> all upper case, right?). Also it's inconsistent with the other tracing >>>> calls, unless you plan on doing it to all of them. >>>> >>>> >>>> Which looks better? >>>> >>>> Not sure. I wouldn't ask which is better. I'd ask which is less >>>> offensive. :) >>>> >>>> thanks, >>>> >>>> Chris >>>> >>>> >>>> Thanks again, >>>> Jc >>>> >>>> On Mon, Apr 29, 2019 at 3:40 PM Chris Plummer >>>> wrote: >>>> >>>>> Ok. I only half heatedly suggest the following >>>>> >>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>>> methodID, VAR_ARGS(className)); >>>>> >>>>> And then VAR_ARGS can contain the reference to TRACE_JNI_CALL. >>>>> >>>>> Chris >>>>> >>>>> On 4/29/19 2:58 PM, Jean Christophe Beyler wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> Thanks for the review! It is the only issue I have with the system now >>>>> and I had not found a good solution for: >>>>> >>>>> as CallObjectMethod is a variadic method, I can't put TRACE_JNI_CALL >>>>> at the end; so I put right before the end; that allows me to do this: >>>>> >>>>> >>>>> +jobject ExceptionCheckingJniEnv::CallObjectMethod(jobject obj, jmethodID methodID, int line,+ const char* file_name, ...) {+ JNIVerifier<> marker(this, "CallObjectMethod", obj, methodID, line, file_name);++ va_list args;+ va_start(args, file_name);+ jobject result = _jni_env->CallObjectMethodV(obj, methodID, args);+ va_end(args);+ return result;+} >>>>> >>>>> Putting it at the end would mean I would have to play with the va_list to remove the last one, and from what I have understood with va_list, it's kind of a no-no to do so. So I left at this. >>>>> >>>>> Do you have any better suggestion? >>>>> >>>>> Thanks! >>>>> >>>>> Jc >>>>> >>>>> >>>>> On Mon, Apr 29, 2019 at 10:38 AM Chris Plummer < >>>>> chris.plummer at oracle.com> wrote: >>>>> >>>>>> Hi JC, >>>>>> >>>>>> In em01t002.cpp, is this correct? >>>>>> >>>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>>>> methodID, TRACE_JNI_CALL, className); >>>>>> >>>>>> Shouldn't the TRACE_JNI_CALL arg be last? If so, can you look into >>>>>> why this test didn't fail as a result. >>>>>> >>>>>> Other than that the changes look good. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> (Re-sending with subject line complete :-)) >>>>>> >>>>>> Since JDK-8213501 finally merged (sorry it took so long), I am able >>>>>> to continue this work. Here is the work that puts back the messages for any >>>>>> calls that were moved around due to JDK-8212884. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 >>>>>> >>>>>> All modified tests pass on my local dev machine. >>>>>> >>>>>> Thanks, >>>>>> Jc >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sun May 5 02:17:40 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 4 May 2019 19:17:40 -0700 Subject: RFR (M) 8223040: Add a AGCT test In-Reply-To: References: <1d66af45-98ad-1c5a-e570-aadea2d5345e@oracle.com> <359b9e8a-d1d6-66d8-f26a-e1b005047db7@oracle.com> <832d2f71-25ed-6551-7811-e343e35b75c4@oracle.com> <451fdea5-c0bc-32b6-b1f3-998aa8145128@oracle.com> Message-ID: <26fc8088-2cb9-dc93-327f-81c9d1f17e26@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Sun May 5 02:29:08 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Sat, 4 May 2019 19:29:08 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> Message-ID: <06d3d63e-d940-7892-886e-79976126e19c@oracle.com> An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Sun May 5 02:42:07 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Sun, 5 May 2019 02:42:07 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> Message-ID: <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> Dear Serguei? Thanks a lot for your reviewing. System.err.println(" incremental dump support:"); + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); From this description is not clear at all what does the chunkcount mean. Is it to define how many heap objects are dumped in one chunk? If so, would it better to name it chunksize instead where chunksize is measured in heap objects? Then would it better to use the same units to define the maxfilesize as well? (I'm not insisting on this, just asking.) The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. BRs, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From zanglin5 at jd.com Sun May 5 07:34:06 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Sun, 5 May 2019 07:34:06 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com>, <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> Message-ID: Dear All, I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8222319 May I ask your help to review it? When it is finalized, I will refine the webrev. BRs, Lin > Dear Serguei? > Thanks a lot for your reviewing. > > > > > System.err.println(" incremental dump support:"); > > + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); > > + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); > > > > > > From this description is not clear at all what does the chunkcount mean. > > Is it to define how many heap objects are dumped in one chunk? > > If so, would it better to name it chunksize instead where chunksize is measured in heap objects? > > Then would it better to use the same units to define the maxfilesize as well? > > (I'm not insisting on this, just asking.) > > The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. > For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and > when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. > > The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. > Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. > BRs, > Lin From robbin.ehn at oracle.com Mon May 6 07:31:45 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 6 May 2019 09:31:45 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) Message-ID: Hi, please review. Old threads linked list remove and updated SA to use ThreadsList array instead. Issue: https://bugs.openjdk.java.net/browse/JDK-8223306 Webrev: http://cr.openjdk.java.net/~rehn/8223306/webrev/ Passes t1-3 (which includes SA tests). Thanks, Robbin From matthias.baesken at sap.com Mon May 6 10:54:41 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 6 May 2019 10:54:41 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger Message-ID: Hello, looked at the latest web rev ( http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.3/ ) , looks good to me ! (not a Reviewer however ) Best regards, Matthias > > On 30/04/2019 9:33 pm, Schmelter, Ralf wrote: > > Hi David, > > > > good catch. I've moved the vm->native transition back to the start of the > method and instead do a native->vm transition before calling > print_debug_listen_address() method. > > > > webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.2/ > > Yep that works too. :) > > Not a review as I didn't look at the rest of the code. > > Cheers, > David > > > Best regards, > > Ralf > > > > From chris.plummer at oracle.com Mon May 6 18:32:17 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 May 2019 11:32:17 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon May 6 22:27:40 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 May 2019 15:27:40 -0700 Subject: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> Message-ID: <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon May 6 22:40:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 May 2019 08:40:52 +1000 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: References: Message-ID: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> Hi Robbin, I have a few concerns here. First I can't see how you are actually integrating the SA with the ThreadSMR. You've exposed the _java_thread_list for it to iterate but IIRC that list can be updated when threads are added/removed and I'm not seeing how the SA is left iterating a valid list - we'd normally using a ThreadsListHandle for that ?? (I may need a refresher on how this list is actually maintained.) The conversion from external iteration of the list (the for loop) to internal iteration (passing a lambda to JavaThreadsDo) is also problematic. First I'd be very wary about introducing lambda expressions into the SA code - lambda drags in a lot of supporting code that could have an impact on the way SA functions. There are places where we have to avoid lambdas due to bootstrapping/initialization issues and I think the SA may be an area where we also want to keep the code extremely simple. Second by using lambda's with internal iteration you've lost the ability to terminate the iteration loop! In the existing code if we have a return in the for-loop then we not only terminate the loop but the enclosing method. With the lambda the "return" just ends the current iteration and JavaThreadsDo will then continue with the next thread - so we don't even terminate the iteration let alone the method performing the iteration. So for places were we want to process one thread, for example, we will continue to iterate all remaining threads and just do nothing with them. That's very inefficient. Thanks, David On 6/05/2019 5:31 pm, Robbin Ehn wrote: > Hi, please review. > > Old threads linked list remove and updated SA to use ThreadsList array > instead. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8223306 > Webrev: > http://cr.openjdk.java.net/~rehn/8223306/webrev/ > > Passes t1-3 (which includes SA tests). > > Thanks, Robbin From jcbeyler at google.com Tue May 7 00:37:01 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 6 May 2019 17:37:01 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> Message-ID: Hi both, I think it all makes sense so I did this: Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.02/ Incremental webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.01_02/ @Serguei: I think since I am changing the call sites anyway, it makes sense to just change it to ec_jni for all; so I went ahead and did it retro-actively to all call sites @Chris: I am not shocked or my eyes are not crying by seeing TRACE_JNI_CALL_VARARGS so I went ahead and did that as well; I think it works out better too: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/em01t002.cpp.udiff.html You both said "leave it up to you" but I'd rather wait for a final LGTM from both (and/or reviews from others) of you and I can move forward, I'll re-submit for testing via the submit repo (all the affected tests pass on my dev machine already). Thanks again, Jc On Mon, May 6, 2019 at 11:32 AM Chris Plummer wrote: > Hi JC, > > After looking at the following: > > 71 methodID = jni_env->GetMethodID( > 72 klass, "loadClass", > "(Ljava/lang/String;)Ljava/lang/Class;", TRACE_JNI_CALL); > 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, > methodID, TRACE_VARARGS(className)); > > I was wondering if the naming of TRACE_VARARGS should more closely > resemble TRACE_JNI_CALL. Maybe TRACE_JNI_VARARGS or TRACE_JNI_CALL_VARARGS > (starting to get a bit wordy though)? > > I'll leave it up to you. Other than that it looks fine. > > thanks, > > Chris > > On 5/4/19 2:12 PM, Jean Christophe Beyler wrote: > > Hi Chris and Serguei, > > Then the new webrev is here: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 > > Let me know if now it looks good for you; > @Serguei, you had said it looks good but had comments; you never answered > my comment about naming; would you like me to rename all the environments > to ec_jni_env? I'd do another webrev for the ones not done in this webrev > but that are already under the ExceptionCheckingJniEnvPtr, let me know :) > > Finally, does anyone else have comments? > > Thanks, > Jc > > > On Tue, Apr 30, 2019 at 3:46 PM Chris Plummer > wrote: > >> On 4/30/19 3:36 PM, Jean Christophe Beyler wrote: >> >> You are right I was overthinking the naming, so I did this now: >> >> - loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, >> TRACE_JNI_CALL, className); >> + loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, >> TRACE_VARARGS(className)); >> >> Ok. I like this. >> >> >> Question now is: this variadic won't work if there are no arguments in a >> portable way, so if there are no arguments for the call, should we use a >> TRACE_JNI_CALL such as: >> jni_env->CallVoidMethod(thread, methodID, TRACE_JNI_CALL); >> >> or should I create a TRACE_VARARGS for no arguments: >> jni_env->CallVoidMethod(thread, methodID, TRACE_EMPTY_VARARGS()); >> >> Advantage of the latter is that you would know it is a VARARG at least >> and you can see it; draw-back is yet another macro. >> >> >> What do you think? >> >> In general we don't know it is vararg when looking at a callsite, so I >> don't feel the need to advertise it as such with TRACE_EMPTY_VARARGS(). I'd >> recommend just directly passing TRACE_JNI_CALL. >> >> Chris >> >> Jc >> >> >> >> On Tue, Apr 30, 2019 at 11:37 AM Chris Plummer >> wrote: >> >>> Hi JC, >>> >>> I'm not sure why you are suggesting TRACED_JNI_CALL instead of >>> TRACED_VARARGS. How are they different? Are you suggesting non-varargs >>> calls would just end up using an empty TRACED_JNI_CALL()? >>> >>> Chris >>> >>> On 4/30/19 10:05 AM, Jean Christophe Beyler wrote: >>> >>> I do have more of these coming and there are 86 CallXMethod cases where >>> this will occur and 49 NewObject cases. So it would be good to figure out >>> something that does not hurt our eyes too many times. >>> >>> I think I would go with the TRACED_VARARGS, it at least has the >>> advantage of not being too bad. I would move toward doing: >>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>> methodID, TRACED_JNI_CALL(className)); >>> >>> To be consisted with the non-vararg cases, what do you think? >>> >>> Jc >>> >>> On Tue, Apr 30, 2019 at 9:51 AM Chris Plummer >>> wrote: >>> >>>> The advantage of the TRACED_VARARGS approach (or leaving it as-is) is >>>> that there are limited APIs and callsites affected (only 1 of each in this >>>> review, but it's unclear to me if you have more of these changes coming). >>>> >>>> Chris >>>> >>>> On 4/29/19 9:49 PM, Jean Christophe Beyler wrote: >>>> >>>> Yes I would fix them all in the next webrev and then continue the >>>> porting. I 100% agree to which is less offensive. I find that >>>> >>>> 73 loadedClass = (jclass) jni_env->CALLOBJECTMETHODTRACED(loader, >>>> methodID, className); >>>> >>>> to be offensive as well. >>>> >>>> So perhaps the TRACED_VARARGS is best: >>>> >>>> >>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>> methodID, TRACED_VARARGS(className)); >>>> >>>> What do you think? >>>> >>>> >>>> On Mon, Apr 29, 2019 at 9:44 PM Chris Plummer >>>> wrote: >>>> >>>>> Hi JC, >>>>> >>>>> On 4/29/19 4:25 PM, Jean Christophe Beyler wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> I agree it's not ideal, how about putting it first? >>>>> >>>>> 73 loadedClass = (jclass) >>>>> jni_env->CallObjectMethod(TRACE_JNI_CALL, loader, methodID, className); >>>>> >>>>> It's not consistent with other uses, or are you suggesting changing >>>>> them all? >>>>> >>>>> >>>>> I find that less awkward than the VAR_ARGS, no? >>>>> >>>>> Or something like: >>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethodTraced(loader, >>>>> methodID, className); >>>>> >>>>> Where CallObjectMethodTraced is actually a define in the exception >>>>> handling system that adds the line and filename... >>>>> >>>>> I don't like macroizing a method call in this manner (macros should be >>>>> all upper case, right?). Also it's inconsistent with the other tracing >>>>> calls, unless you plan on doing it to all of them. >>>>> >>>>> >>>>> Which looks better? >>>>> >>>>> Not sure. I wouldn't ask which is better. I'd ask which is less >>>>> offensive. :) >>>>> >>>>> thanks, >>>>> >>>>> Chris >>>>> >>>>> >>>>> Thanks again, >>>>> Jc >>>>> >>>>> On Mon, Apr 29, 2019 at 3:40 PM Chris Plummer < >>>>> chris.plummer at oracle.com> wrote: >>>>> >>>>>> Ok. I only half heatedly suggest the following >>>>>> >>>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>>>> methodID, VAR_ARGS(className)); >>>>>> >>>>>> And then VAR_ARGS can contain the reference to TRACE_JNI_CALL. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 4/29/19 2:58 PM, Jean Christophe Beyler wrote: >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> Thanks for the review! It is the only issue I have with the system >>>>>> now and I had not found a good solution for: >>>>>> >>>>>> as CallObjectMethod is a variadic method, I can't put TRACE_JNI_CALL >>>>>> at the end; so I put right before the end; that allows me to do this: >>>>>> >>>>>> >>>>>> +jobject ExceptionCheckingJniEnv::CallObjectMethod(jobject obj, jmethodID methodID, int line,+ const char* file_name, ...) {+ JNIVerifier<> marker(this, "CallObjectMethod", obj, methodID, line, file_name);++ va_list args;+ va_start(args, file_name);+ jobject result = _jni_env->CallObjectMethodV(obj, methodID, args);+ va_end(args);+ return result;+} >>>>>> >>>>>> Putting it at the end would mean I would have to play with the va_list to remove the last one, and from what I have understood with va_list, it's kind of a no-no to do so. So I left at this. >>>>>> >>>>>> Do you have any better suggestion? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jc >>>>>> >>>>>> >>>>>> On Mon, Apr 29, 2019 at 10:38 AM Chris Plummer < >>>>>> chris.plummer at oracle.com> wrote: >>>>>> >>>>>>> Hi JC, >>>>>>> >>>>>>> In em01t002.cpp, is this correct? >>>>>>> >>>>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>>>>> methodID, TRACE_JNI_CALL, className); >>>>>>> >>>>>>> Shouldn't the TRACE_JNI_CALL arg be last? If so, can you look into >>>>>>> why this test didn't fail as a result. >>>>>>> >>>>>>> Other than that the changes look good. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> (Re-sending with subject line complete :-)) >>>>>>> >>>>>>> Since JDK-8213501 finally merged (sorry it took so long), I am able >>>>>>> to continue this work. Here is the work that puts back the messages for any >>>>>>> calls that were moved around due to JDK-8212884. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 >>>>>>> >>>>>>> All modified tests pass on my local dev machine. >>>>>>> >>>>>>> Thanks, >>>>>>> Jc >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 7 01:16:09 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 6 May 2019 18:16:09 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> Message-ID: <8d6558f8-4b21-76dc-1311-5d893009b3f0@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue May 7 02:09:01 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 6 May 2019 19:09:01 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: <8d6558f8-4b21-76dc-1311-5d893009b3f0@oracle.com> References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> <8d6558f8-4b21-76dc-1311-5d893009b3f0@oracle.com> Message-ID: <66425770-776f-0036-9d51-edf10aca0148@oracle.com> An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Tue May 7 06:50:15 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 7 May 2019 08:50:15 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> Message-ID: <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> Hi David, On 5/7/19 12:40 AM, David Holmes wrote: > Hi Robbin, > > I have a few concerns here. > > First I can't see how you are actually integrating the SA with the ThreadSMR. > You've exposed the _java_thread_list for it to iterate but IIRC that list can be > updated when threads are added/removed and I'm not seeing how the SA is left > iterating a valid list - we'd normally using a ThreadsListHandle for that ?? (I > may need a refresher on how this list is actually maintained.) The processes must be paused. If the processes would be running the linked list is also broken since if we unlink and delete a JavaThread and then later SA follows that _next pointer. > > The conversion from external iteration of the list (the for loop) to internal > iteration (passing a lambda to JavaThreadsDo) is also problematic. First I'd be > very wary about introducing lambda expressions into the SA code - lambda drags > in a lot of supporting code that could have an impact on the way SA functions. > There are places where we have to avoid lambdas due to > bootstrapping/initialization issues and I think the SA may be an area where we > also want to keep the code extremely simple. There are already several usages of lambdas in SA code, e.g. LinuxDebuggerLocal.java. SA is not a core module, it's an application, there is not a bootstrap issue or so. > > Second by using lambda's with internal iteration you've lost the ability to > terminate the iteration loop! In the existing code if we have a return in the > for-loop then we not only terminate the loop but the enclosing method. With the > lambda the "return" just ends the current iteration and JavaThreadsDo will then > continue with the next thread - so we don't even terminate the iteration let > alone the method performing the iteration. So for places were we want to process > one thread, for example, we will continue to iterate all remaining threads and > just do nothing with them. That's very inefficient. That's why I only used the internal iteration where we didn't have early returns. Thanks, Robbin > > Thanks, > David > > On 6/05/2019 5:31 pm, Robbin Ehn wrote: >> Hi, please review. >> >> Old threads linked list remove and updated SA to use ThreadsList array instead. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8223306 >> Webrev: >> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >> >> Passes t1-3 (which includes SA tests). >> >> Thanks, Robbin From david.holmes at oracle.com Tue May 7 07:47:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 May 2019 17:47:16 +1000 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> Message-ID: <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> Hi Robbin, On 7/05/2019 4:50 pm, Robbin Ehn wrote: > Hi David, > > On 5/7/19 12:40 AM, David Holmes wrote: >> Hi Robbin, >> >> I have a few concerns here. >> >> First I can't see how you are actually integrating the SA with the >> ThreadSMR. You've exposed the _java_thread_list for it to iterate but >> IIRC that list can be updated when threads are added/removed and I'm >> not seeing how the SA is left iterating a valid list - we'd normally >> using a ThreadsListHandle for that ?? (I may need a refresher on how >> this list is actually maintained.) > > The processes must be paused. If the processes would be running the > linked list is also broken since if we unlink and delete a JavaThread > and then later SA follows that _next pointer. Ah good point. Thanks for clarifying. >> >> The conversion from external iteration of the list (the for loop) to >> internal iteration (passing a lambda to JavaThreadsDo) is also >> problematic. First I'd be very wary about introducing lambda >> expressions into the SA code - lambda drags in a lot of supporting >> code that could have an impact on the way SA functions. There are >> places where we have to avoid lambdas due to >> bootstrapping/initialization issues and I think the SA may be an area >> where we also want to keep the code extremely simple. > > There are already several usages of lambdas in SA code, e.g. > LinuxDebuggerLocal.java. SA is not a core module, it's an application, > there is not a bootstrap issue or so. Hmm okay. Lambda carries a lot of baggage. But if its already being used ... >> Second by using lambda's with internal iteration you've lost the >> ability to terminate the iteration loop! In the existing code if we >> have a return in the for-loop then we not only terminate the loop but >> the enclosing method. With the lambda the "return" just ends the >> current iteration and JavaThreadsDo will then continue with the next >> thread - so we don't even terminate the iteration let alone the method >> performing the iteration. So for places were we want to process one >> thread, for example, we will continue to iterate all remaining threads >> and just do nothing with them. That's very inefficient. > > That's why I only used the internal iteration where we didn't have early > returns. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java - original code: 1556 new Command("where", "where { -a | id }", false) { 1557 public void doit(Tokens t) { ... 1564 for (JavaThread thread = threads.first(); thread != null; thread = thread.next()) { 1565 ByteArrayOutputStream bos = new ByteArrayOutputStream(); 1566 thread.printThreadIDOn(new PrintStream(bos)); 1567 if (all || bos.toString().equals(name)) { 1568 out.println("Thread " + bos.toString() + " Address: " + thread.getAddress()); ... 1577 } 1578 if (!all) return; That looks like an early return to me. Cheers, David ----- > Thanks, Robbin > >> >> Thanks, >> David >> >> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>> Hi, please review. >>> >>> Old threads linked list remove and updated SA to use ThreadsList >>> array instead. >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>> Webrev: >>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>> >>> Passes t1-3 (which includes SA tests). >>> >>> Thanks, Robbin From robbin.ehn at oracle.com Tue May 7 07:52:58 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 7 May 2019 09:52:58 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> Message-ID: <2ff1e661-d9ec-cdcb-1d8f-4f580faa54db@oracle.com> Hi David, On 5/7/19 9:47 AM, David Holmes wrote: > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java - > original code: > > 1556???????? new Command("where", "where { -a | id }", false) { > 1557???????????? public void doit(Tokens t) { > ... > 1564???????????????????? for (JavaThread thread = threads.first(); thread != > null; thread = thread.next()) { > 1565???????????????????????? ByteArrayOutputStream bos = new > ByteArrayOutputStream(); > 1566???????????????????????? thread.printThreadIDOn(new PrintStream(bos)); > 1567???????????????????????? if (all || bos.toString().equals(name)) { > 1568???????????????????????????? out.println("Thread " + bos.toString() + " > Address: " + thread.getAddress()); > ... > 1577???????????????????????????? } > 1578???????????????????????????? if (!all) return; > > That looks like an early return to me. Yes, thanks, it should not have been converted then. I'll revisit CommandProcessor.java and the other sites. /Robbin > > Cheers, > David > ----- > > >> Thanks, Robbin >> >>> >>> Thanks, >>> David >>> >>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>> Hi, please review. >>>> >>>> Old threads linked list remove and updated SA to use ThreadsList array instead. >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>> Webrev: >>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>> >>>> Passes t1-3 (which includes SA tests). >>>> >>>> Thanks, Robbin From christoph.langer at sap.com Tue May 7 12:36:32 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 7 May 2019 12:36:32 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: Message-ID: Hi Ralf, the change looks good to me, overall. I found a few minor nits in the tests. test/jdk/com/sun/jdi/OnJcmdTest.java 3 * Copyright (c) 2018, 2019, SAP SE. All rights reserved. -> according to our guidelines, we should not have a ',' after the last year for the SAP copyrights 33 * @run compile --add-exports java.base/jdk.internal.vm=ALL-UNNAMED -g OnJcmdTest.java -> can you replace this with @modules java.base/jdk.internal.vm ? The -g option is also not required, I guess (unless somebody debugs the test) Then you should be able to change 34 * @run main/othervm --add-exports java.base/jdk.internal.vm=ALL-UNNAMED -agentlib:jdwp=transport=dt_socket,address=localhost:0,onjcmd=y,server=y OnJcmdTest into @run main/othervm -agentlib:jdwp=transport=dt_socket,address=localhost:0,onjcmd=y,server=y OnJcmdTest 37 import java.lang.reflect.Method; -> can be removed test/jdk/com/sun/jdi/GetListenAddressTest.java -> SAP copyright header needs fixing like above -> 33 * @run compile -g GetListenAddressTest.java should be removed -> 37 import java.lang.ProcessBuilder.Redirect; -> is unnecessary, should be removed I'll sponsor the change for you. Best regards Christoph > -----Original Message----- > From: serviceability-dev On > Behalf Of Baesken, Matthias > Sent: Montag, 6. Mai 2019 12:55 > To: serviceability-dev at openjdk.java.net > Subject: [CAUTION] Re: RFR 8223065: Add jcmd to get the listen address of > the debugger > > Hello, looked at the latest web rev ( > http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.3/ ) , > looks good to me ! > (not a Reviewer however ) > > > Best regards, Matthias > > > > > > On 30/04/2019 9:33 pm, Schmelter, Ralf wrote: > > > Hi David, > > > > > > good catch. I've moved the vm->native transition back to the start of the > > method and instead do a native->vm transition before calling > > print_debug_listen_address() method. > > > > > > webrev: > > http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.2/ > > > > Yep that works too. :) > > > > Not a review as I didn't look at the rest of the code. > > > > Cheers, > > David > > > > > Best regards, > > > Ralf > > > > > > > From ralf.schmelter at sap.com Tue May 7 13:13:11 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Tue, 7 May 2019 13:13:11 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: Message-ID: Hi Christoph, thanks for the review. I've updated the webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.4/ Best regards, Ralf From Alan.Bateman at oracle.com Tue May 7 13:24:31 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 May 2019 14:24:31 +0100 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: Message-ID: On 07/05/2019 14:13, Schmelter, Ralf wrote: > Hi Christoph, > > thanks for the review. I've updated the webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.4/ > Specifying onjcmd=y to the debugger agent looks very strange. Was there a CSR submitted for JDK-8214892? I suspect that sub-option needs further discussion before additional features on built on it. -Alan From jcbeyler at google.com Tue May 7 14:44:22 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 7 May 2019 07:44:22 -0700 Subject: RFR (M) 8223044: Add back exception checking in tests In-Reply-To: <66425770-776f-0036-9d51-edf10aca0148@oracle.com> References: <02c0f97e-a058-ff1f-d925-c2f36e74d948@oracle.com> <72640c8a-b30d-3510-ad6e-d1be51b05a91@oracle.com> <7c326400-ae41-b26b-5232-3758b206139f@oracle.com> <268e791d-f69e-9a93-55c5-cb45d1bf8a33@oracle.com> <8d6558f8-4b21-76dc-1311-5d893009b3f0@oracle.com> <66425770-776f-0036-9d51-edf10aca0148@oracle.com> Message-ID: Thanks both for your help :) Jc On Mon, May 6, 2019 at 7:09 PM Chris Plummer wrote: > +1 > > On 5/6/19 6:16 PM, serguei.spitsyn at oracle.com wrote: > > Hi Jc, > > It looks great to me. > Thank you for the update! > > Thanks, > Serguei > > > On 5/6/19 17:37, Jean Christophe Beyler wrote: > > Hi both, > > I think it all makes sense so I did this: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.02/ > Incremental webrev: > http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.01_02/ > > @Serguei: I think since I am changing the call sites anyway, it makes > sense to just change it to ec_jni for all; so I went ahead and did it > retro-actively to all call sites > @Chris: I am not shocked or my eyes are not crying by seeing > TRACE_JNI_CALL_VARARGS so I went ahead and did that as well; I think it > works out better too: > > http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.02/test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM01/em01t002/em01t002.cpp.udiff.html > > You both said "leave it up to you" but I'd rather wait for a final LGTM > from both (and/or reviews from others) of you and I can move forward, I'll > re-submit for testing via the submit repo (all the affected tests pass on > my dev machine already). > > Thanks again, > Jc > > On Mon, May 6, 2019 at 11:32 AM Chris Plummer > wrote: > >> Hi JC, >> >> After looking at the following: >> >> 71 methodID = jni_env->GetMethodID( >> 72 klass, "loadClass", >> "(Ljava/lang/String;)Ljava/lang/Class;", TRACE_JNI_CALL); >> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >> methodID, TRACE_VARARGS(className)); >> >> I was wondering if the naming of TRACE_VARARGS should more closely >> resemble TRACE_JNI_CALL. Maybe TRACE_JNI_VARARGS or TRACE_JNI_CALL_VARARGS >> (starting to get a bit wordy though)? >> >> I'll leave it up to you. Other than that it looks fine. >> >> thanks, >> >> Chris >> >> On 5/4/19 2:12 PM, Jean Christophe Beyler wrote: >> >> Hi Chris and Serguei, >> >> Then the new webrev is here: >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 >> >> Let me know if now it looks good for you; >> @Serguei, you had said it looks good but had comments; you never answered >> my comment about naming; would you like me to rename all the environments >> to ec_jni_env? I'd do another webrev for the ones not done in this webrev >> but that are already under the ExceptionCheckingJniEnvPtr, let me know :) >> >> Finally, does anyone else have comments? >> >> Thanks, >> Jc >> >> >> On Tue, Apr 30, 2019 at 3:46 PM Chris Plummer >> wrote: >> >>> On 4/30/19 3:36 PM, Jean Christophe Beyler wrote: >>> >>> You are right I was overthinking the naming, so I did this now: >>> >>> - loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, >>> TRACE_JNI_CALL, className); >>> + loadedClass = (jclass) jni_env->CallObjectMethod(loader, methodID, >>> TRACE_VARARGS(className)); >>> >>> Ok. I like this. >>> >>> >>> Question now is: this variadic won't work if there are no arguments in a >>> portable way, so if there are no arguments for the call, should we use a >>> TRACE_JNI_CALL such as: >>> jni_env->CallVoidMethod(thread, methodID, TRACE_JNI_CALL); >>> >>> or should I create a TRACE_VARARGS for no arguments: >>> jni_env->CallVoidMethod(thread, methodID, TRACE_EMPTY_VARARGS()); >>> >>> Advantage of the latter is that you would know it is a VARARG at least >>> and you can see it; draw-back is yet another macro. >>> >>> >>> What do you think? >>> >>> In general we don't know it is vararg when looking at a callsite, so I >>> don't feel the need to advertise it as such with TRACE_EMPTY_VARARGS(). I'd >>> recommend just directly passing TRACE_JNI_CALL. >>> >>> Chris >>> >>> Jc >>> >>> >>> >>> On Tue, Apr 30, 2019 at 11:37 AM Chris Plummer >>> wrote: >>> >>>> Hi JC, >>>> >>>> I'm not sure why you are suggesting TRACED_JNI_CALL instead of >>>> TRACED_VARARGS. How are they different? Are you suggesting non-varargs >>>> calls would just end up using an empty TRACED_JNI_CALL()? >>>> >>>> Chris >>>> >>>> On 4/30/19 10:05 AM, Jean Christophe Beyler wrote: >>>> >>>> I do have more of these coming and there are 86 CallXMethod cases where >>>> this will occur and 49 NewObject cases. So it would be good to figure out >>>> something that does not hurt our eyes too many times. >>>> >>>> I think I would go with the TRACED_VARARGS, it at least has the >>>> advantage of not being too bad. I would move toward doing: >>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>> methodID, TRACED_JNI_CALL(className)); >>>> >>>> To be consisted with the non-vararg cases, what do you think? >>>> >>>> Jc >>>> >>>> On Tue, Apr 30, 2019 at 9:51 AM Chris Plummer >>>> wrote: >>>> >>>>> The advantage of the TRACED_VARARGS approach (or leaving it as-is) is >>>>> that there are limited APIs and callsites affected (only 1 of each in this >>>>> review, but it's unclear to me if you have more of these changes coming). >>>>> >>>>> Chris >>>>> >>>>> On 4/29/19 9:49 PM, Jean Christophe Beyler wrote: >>>>> >>>>> Yes I would fix them all in the next webrev and then continue the >>>>> porting. I 100% agree to which is less offensive. I find that >>>>> >>>>> 73 loadedClass = (jclass) jni_env->CALLOBJECTMETHODTRACED(loader, >>>>> methodID, className); >>>>> >>>>> to be offensive as well. >>>>> >>>>> So perhaps the TRACED_VARARGS is best: >>>>> >>>>> >>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>>> methodID, TRACED_VARARGS(className)); >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> On Mon, Apr 29, 2019 at 9:44 PM Chris Plummer < >>>>> chris.plummer at oracle.com> wrote: >>>>> >>>>>> Hi JC, >>>>>> >>>>>> On 4/29/19 4:25 PM, Jean Christophe Beyler wrote: >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> I agree it's not ideal, how about putting it first? >>>>>> >>>>>> 73 loadedClass = (jclass) >>>>>> jni_env->CallObjectMethod(TRACE_JNI_CALL, loader, methodID, className); >>>>>> >>>>>> It's not consistent with other uses, or are you suggesting changing >>>>>> them all? >>>>>> >>>>>> >>>>>> I find that less awkward than the VAR_ARGS, no? >>>>>> >>>>>> Or something like: >>>>>> 73 loadedClass = (jclass) >>>>>> jni_env->CallObjectMethodTraced(loader, methodID, className); >>>>>> >>>>>> Where CallObjectMethodTraced is actually a define in the exception >>>>>> handling system that adds the line and filename... >>>>>> >>>>>> I don't like macroizing a method call in this manner (macros should >>>>>> be all upper case, right?). Also it's inconsistent with the other tracing >>>>>> calls, unless you plan on doing it to all of them. >>>>>> >>>>>> >>>>>> Which looks better? >>>>>> >>>>>> Not sure. I wouldn't ask which is better. I'd ask which is less >>>>>> offensive. :) >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>> >>>>>> >>>>>> Thanks again, >>>>>> Jc >>>>>> >>>>>> On Mon, Apr 29, 2019 at 3:40 PM Chris Plummer < >>>>>> chris.plummer at oracle.com> wrote: >>>>>> >>>>>>> Ok. I only half heatedly suggest the following >>>>>>> >>>>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>>>>> methodID, VAR_ARGS(className)); >>>>>>> >>>>>>> And then VAR_ARGS can contain the reference to TRACE_JNI_CALL. >>>>>>> >>>>>>> Chris >>>>>>> >>>>>>> On 4/29/19 2:58 PM, Jean Christophe Beyler wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> Thanks for the review! It is the only issue I have with the system >>>>>>> now and I had not found a good solution for: >>>>>>> >>>>>>> as CallObjectMethod is a variadic method, I can't put TRACE_JNI_CALL >>>>>>> at the end; so I put right before the end; that allows me to do this: >>>>>>> >>>>>>> >>>>>>> +jobject ExceptionCheckingJniEnv::CallObjectMethod(jobject obj, jmethodID methodID, int line,+ const char* file_name, ...) {+ JNIVerifier<> marker(this, "CallObjectMethod", obj, methodID, line, file_name);++ va_list args;+ va_start(args, file_name);+ jobject result = _jni_env->CallObjectMethodV(obj, methodID, args);+ va_end(args);+ return result;+} >>>>>>> >>>>>>> Putting it at the end would mean I would have to play with the va_list to remove the last one, and from what I have understood with va_list, it's kind of a no-no to do so. So I left at this. >>>>>>> >>>>>>> Do you have any better suggestion? >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jc >>>>>>> >>>>>>> >>>>>>> On Mon, Apr 29, 2019 at 10:38 AM Chris Plummer < >>>>>>> chris.plummer at oracle.com> wrote: >>>>>>> >>>>>>>> Hi JC, >>>>>>>> >>>>>>>> In em01t002.cpp, is this correct? >>>>>>>> >>>>>>>> 73 loadedClass = (jclass) jni_env->CallObjectMethod(loader, >>>>>>>> methodID, TRACE_JNI_CALL, className); >>>>>>>> >>>>>>>> Shouldn't the TRACE_JNI_CALL arg be last? If so, can you look into >>>>>>>> why this test didn't fail as a result. >>>>>>>> >>>>>>>> Other than that the changes look good. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> On 4/26/19 5:52 PM, Jean Christophe Beyler wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> (Re-sending with subject line complete :-)) >>>>>>>> >>>>>>>> Since JDK-8213501 finally merged (sorry it took so long), I am able >>>>>>>> to continue this work. Here is the work that puts back the messages for any >>>>>>>> calls that were moved around due to JDK-8212884. >>>>>>>> >>>>>>>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223044/webrev.00/ >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223044 >>>>>>>> >>>>>>>> All modified tests pass on my local dev machine. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jc >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thanks, >>>>>>> Jc >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc >>>>> >>>>> >>>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>>> >>>> >>>> >>> >>> -- >>> >>> Thanks, >>> Jc >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> >> >> > > -- > > Thanks, > Jc > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Tue May 7 18:05:36 2019 From: gary.adams at oracle.com (Gary Adams) Date: Tue, 07 May 2019 14:05:36 -0400 Subject: Fwd: Re: RFR: JDK-8223416: Exclude javax/management/monitor/DerivedGaugeMonitorTest.java until JDK-8042211 is fixed. In-Reply-To: <59f98662-3f98-6b0a-ab16-4246ecef127a@oracle.com> References: <59f98662-3f98-6b0a-ab16-4246ecef127a@oracle.com> Message-ID: <5CD1C8F0.6030700@oracle.com> -------- Original Message -------- Subject: Re: RFR: JDK-8223416: Exclude javax/management/monitor/DerivedGaugeMonitorTest.java until JDK-8042211 is fixed. Date: Tue, 7 May 2019 13:59:57 -0400 From: Daniel D. Daugherty Reply-To: daniel.daugherty at oracle.com To: gary.adams at oracle.com, Internal Serviceability Gary, Thumbs up! But... The test is open so problem listing the test should also be open. The bug is closed because the description contains an internal URL. Dan On 5/7/19 1:56 PM, Gary Adams wrote: > Trivial update to ProblemList test while underlying fix is developed. > > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -566,6 +566,8 @@ > java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java 8081652 > generic-all > java/lang/management/ThreadMXBean/AllThreadIds.java 8131745 generic-all > > +javax/management/monitor/DerivedGaugeMonitorTest.java 8042211 > generic-all > + > ############################################################################ > > > # jdk_io > -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 7 18:40:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 7 May 2019 11:40:14 -0700 Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com> Message-ID: Hi guys, We need a couple of partial reviews for this enhancement: ?- From the net-dev to check IPv6-addresses related part. ?? It does not need to be a thorough review. ?? We need another pair of eyes to check for obvious typos or misses. ?? Included Chris H. to mailing list in hope for some assistance. ?? (Chris, we need some help to find one of the IPv6 experts.) ?- From the serviceability-dev to check if compatibility ?? is not broken and nothing is missed. ?? This includes part of code that is not directly involved ?? into manipulations with the IPv4/IPv6 addresses. ?? The related spec update is tracked by a sub-task: ???? https://bugs.openjdk.java.net/browse/JDK-8221707 Related CSR: https://bugs.openjdk.java.net/browse/JDK-8223104 The latest webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ Thanks, Serguei On 5/6/19 3:27 PM, serguei.spitsyn at oracle.com wrote: > Hi Alex, > > It looks great and very solid in general! > > Some minor comments are below. > > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html > > 263 * Result must be release with dbgsysFreeAddrInfo. > ? A typo: "must be release" => "must be released" > > 80 typedef struct { > 81 struct in6_addr subnet; > 82 struct in6_addr netmask; > 83 } AllowedPeerInfo; > . . . > > 431 parseAllowedPeersInternal(char *buffer) { . . . > 483 } . . . 524 isPeerAllowed(struct sockaddr_storage *peer) { > 525 struct in6_addr tmp; > 526 struct in6_addr *addr6; > 527 if (peer->ss_family == AF_INET) { > 528 convertIPv4ToIPv6((struct sockaddr *)peer, &tmp); > 529 addr6 = &tmp; > 530 } else { > 531 addr6 = &(((struct sockaddr_in6 *)peer)->sin6_addr); > 532 } > 533 > 534 for (int i = 0; i < _peers_cnt; ++i) { > 535 if (isAddressInSubnet(addr6, &(_peers[i].subnet), > &(_peers[i].netmask))) { > 536 return 1; > 537 } > 538 } > ?The allowed pears are converted into and used/checked in the IPv6 format. > ?Some short comments about it in all three places above would be helpful. > ?I'd consider to do the same in parseAllowedAddr() before this fragment: > 367 if (addrInfo->ai_family == AF_INET6) { > 368 memcpy(result, &(((struct sockaddr_in6 > *)(addrInfo->ai_addr))->sin6_addr), sizeof(*result)); > 369 *isIPv4 = 0; > 370 } else { // IPv4 address > 371 struct in6_addr addr6; > 372 convertIPv4ToIPv6(addrInfo->ai_addr, &addr6); > 373 memcpy(result, &addr6, sizeof(*result)); > 374 *isIPv4 = 1; > 375 } > > ?and in parseAllowedMask() before the line: > 420 result->s6_addr[i] = (char)(0xFF << (8 - prefixLen)); > > This fragment needs a comment: 402 if (isIPv4) { > 403 prefixLen += 96; > 404 } > > > We have to find out at least one more reviewer for this fix! > > Thanks, > Serguei > > > On 5/3/19 18:14, serguei.spitsyn at oracle.com wrote: >> Hi Alex, >> >> Thank you for creating the CSR! >> I've added myself as a reviewer and corrected a couple of places. >> Feel free to change my changes if necessary. :) >> It would be nice to get one more CSR review if possible, so I've >> added the net-dev mailing list. >> >> I hope to finish the webrev review soon. >> >> Thanks, >> Serguei >> >> On 5/1/19 10:54 AM, Alex Menkov wrote: >>> Hi all, >>> >>> I created CSR for the feature: >>> https://bugs.openjdk.java.net/browse/JDK-8223104 >>> >>> The latest webrev: >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ >>> >>> --alex >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeubanks at google.com Wed May 8 00:48:40 2019 From: aeubanks at google.com (Arthur Eubanks) Date: Tue, 7 May 2019 17:48:40 -0700 Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com> Message-ID: Even though I showed our internal patches in this area earlier, I haven't really looked into exactly what this patch does (since it was written by someone else). I can confirm that it fixes jshell in an IPv6 only environment though. *From: * *Date: *Tue, May 7, 2019 at 11:42 AM *To: *Alex Menkov, , net-dev, Chris Hegarty Hi guys, > > We need a couple of partial reviews for this enhancement: > > - From the net-dev to check IPv6-addresses related part. > It does not need to be a thorough review. > We need another pair of eyes to check for obvious typos or misses. > Included Chris H. to mailing list in hope for some assistance. > (Chris, we need some help to find one of the IPv6 experts.) > > - From the serviceability-dev to check if compatibility > is not broken and nothing is missed. > This includes part of code that is not directly involved > into manipulations with the IPv4/IPv6 addresses. > The related spec update is tracked by a sub-task: > https://bugs.openjdk.java.net/browse/JDK-8221707 > > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223104 > > The latest webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ > > > Thanks, > Serguei > > > On 5/6/19 3:27 PM, serguei.spitsyn at oracle.com wrote: > > Hi Alex, > > It looks great and very solid in general! > > Some minor comments are below. > > > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c.frames.html > > 263 * Result must be release with dbgsysFreeAddrInfo. > > A typo: "must be release" => "must be released" > > 80 typedef struct { 81 struct in6_addr subnet; 82 struct in6_addr netmask; > 83 } AllowedPeerInfo; > . . . > 431 parseAllowedPeersInternal(char *buffer) { > . . . 483 } > . . . > 524 isPeerAllowed(struct sockaddr_storage *peer) { 525 struct in6_addr tmp; 526 struct in6_addr *addr6; 527 if (peer->ss_family == AF_INET) { 528 convertIPv4ToIPv6((struct sockaddr *)peer, &tmp); 529 addr6 = &tmp; 530 } else { 531 addr6 = &(((struct sockaddr_in6 *)peer)->sin6_addr); 532 } 533 534 for (int i = 0; i < _peers_cnt; ++i) { 535 if (isAddressInSubnet(addr6, &(_peers[i].subnet), &(_peers[i].netmask))) { > 536 return 1; > 537 } > 538 } > > The allowed pears are converted into and used/checked in the IPv6 format. > Some short comments about it in all three places above would be helpful. > I'd consider to do the same in parseAllowedAddr() before this fragment: > > 367 if (addrInfo->ai_family == AF_INET6) { 368 memcpy(result, &(((struct sockaddr_in6 *)(addrInfo->ai_addr))->sin6_addr), sizeof(*result)); 369 *isIPv4 = 0; 370 } else { // IPv4 address 371 struct in6_addr addr6; 372 convertIPv4ToIPv6(addrInfo->ai_addr, &addr6); 373 memcpy(result, &addr6, sizeof(*result)); 374 *isIPv4 = 1; > 375 } > > > and in parseAllowedMask() before the line: > > 420 result->s6_addr[i] = (char)(0xFF << (8 - prefixLen)); > > > This fragment needs a comment: > 402 if (isIPv4) { 403 prefixLen += 96; > 404 } > > > > We have to find out at least one more reviewer for this fix! > > Thanks, > Serguei > > > On 5/3/19 18:14, serguei.spitsyn at oracle.com wrote: > > Hi Alex, > > Thank you for creating the CSR! > I've added myself as a reviewer and corrected a couple of places. > Feel free to change my changes if necessary. :) > It would be nice to get one more CSR review if possible, so I've added the > net-dev mailing list. > > I hope to finish the webrev review soon. > > Thanks, > Serguei > > On 5/1/19 10:54 AM, Alex Menkov wrote: > > Hi all, > > I created CSR for the feature: > https://bugs.openjdk.java.net/browse/JDK-8223104 > > The latest webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ > > --alex > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Wed May 8 02:47:22 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 7 May 2019 19:47:22 -0700 Subject: RFR (S) 8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism Message-ID: Hi all, Could I get a review for this test fix: Webrev: http://cr.openjdk.java.net/~jcbeyler/8223441/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223441 Backstory is: When I fixed https://bugs.openjdk.java.net/browse/JDK-8215113, I fixed this failing test in the "actually make the error calculation correct". But it turns out the test itself failed 7 out of 10 times and when we tested it, we were apparently "lucky". This fix makes the test pass 5k times so I am hopeful it will not show up again. Extra notes: - I fixed this by adding a loop that says: if we have not converged yet, try again at max 5 times; generally we don't converge if the sampling intervals chosen at the start just have pushed us far enough from the average we expect that it takes more samples to get us back on track Thanks, Jc Ps: FWIW, I'm going to look at the flakyness of the rest of the suite and see if anything pops up to reduce the test bug noise of this suite -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed May 8 09:00:22 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 May 2019 02:00:22 -0700 Subject: RFR (S) 8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Wed May 8 09:17:37 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 8 May 2019 11:17:37 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> Message-ID: Hi David, I changed to normal for: http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html Full: http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ Inc: http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ Passes t1-2 Thanks, Robbin On 2019-05-07 09:47, David Holmes wrote: > Hi Robbin, > > On 7/05/2019 4:50 pm, Robbin Ehn wrote: >> Hi David, >> >> On 5/7/19 12:40 AM, David Holmes wrote: >>> Hi Robbin, >>> >>> I have a few concerns here. >>> >>> First I can't see how you are actually integrating the SA with the ThreadSMR. >>> You've exposed the _java_thread_list for it to iterate but IIRC that list can >>> be updated when threads are added/removed and I'm not seeing how the SA is >>> left iterating a valid list - we'd normally using a ThreadsListHandle for >>> that ?? (I may need a refresher on how this list is actually maintained.) >> >> The processes must be paused. If the processes would be running the linked >> list is also broken since if we unlink and delete a JavaThread and then later >> SA follows that _next pointer. > > Ah good point. Thanks for clarifying. > >>> >>> The conversion from external iteration of the list (the for loop) to internal >>> iteration (passing a lambda to JavaThreadsDo) is also problematic. First I'd >>> be very wary about introducing lambda expressions into the SA code - lambda >>> drags in a lot of supporting code that could have an impact on the way SA >>> functions. There are places where we have to avoid lambdas due to >>> bootstrapping/initialization issues and I think the SA may be an area where >>> we also want to keep the code extremely simple. >> >> There are already several usages of lambdas in SA code, e.g. >> LinuxDebuggerLocal.java. SA is not a core module, it's an application, there >> is not a bootstrap issue or so. > > Hmm okay. Lambda carries a lot of baggage. But if its already being used ... > >>> Second by using lambda's with internal iteration you've lost the ability to >>> terminate the iteration loop! In the existing code if we have a return in the >>> for-loop then we not only terminate the loop but the enclosing method. With >>> the lambda the "return" just ends the current iteration and JavaThreadsDo >>> will then continue with the next thread - so we don't even terminate the >>> iteration let alone the method performing the iteration. So for places were >>> we want to process one thread, for example, we will continue to iterate all >>> remaining threads and just do nothing with them. That's very inefficient. >> >> That's why I only used the internal iteration where we didn't have early returns. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java - > original code: > > 1556???????? new Command("where", "where { -a | id }", false) { > 1557???????????? public void doit(Tokens t) { > ... > 1564???????????????????? for (JavaThread thread = threads.first(); thread != > null; thread = thread.next()) { > 1565???????????????????????? ByteArrayOutputStream bos = new > ByteArrayOutputStream(); > 1566???????????????????????? thread.printThreadIDOn(new PrintStream(bos)); > 1567???????????????????????? if (all || bos.toString().equals(name)) { > 1568???????????????????????????? out.println("Thread " + bos.toString() + " > Address: " + thread.getAddress()); > ... > 1577???????????????????????????? } > 1578???????????????????????????? if (!all) return; > > That looks like an early return to me. > > Cheers, > David > ----- > > >> Thanks, Robbin >> >>> >>> Thanks, >>> David >>> >>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>> Hi, please review. >>>> >>>> Old threads linked list remove and updated SA to use ThreadsList array instead. >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>> Webrev: >>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>> >>>> Passes t1-3 (which includes SA tests). >>>> >>>> Thanks, Robbin From robbin.ehn at oracle.com Wed May 8 09:20:31 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 8 May 2019 11:20:31 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> Message-ID: <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Correct links: http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ /Robbin On 2019-05-08 11:17, Robbin Ehn wrote: > Hi David, > > I changed to normal for: > http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html > > > Full: > http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ > Inc: > http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ > > Passes t1-2 > > Thanks, Robbin > > > On 2019-05-07 09:47, David Holmes wrote: >> Hi Robbin, >> >> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>> Hi David, >>> >>> On 5/7/19 12:40 AM, David Holmes wrote: >>>> Hi Robbin, >>>> >>>> I have a few concerns here. >>>> >>>> First I can't see how you are actually integrating the SA with the >>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate but IIRC >>>> that list can be updated when threads are added/removed and I'm not seeing >>>> how the SA is left iterating a valid list - we'd normally using a >>>> ThreadsListHandle for that ?? (I may need a refresher on how this list is >>>> actually maintained.) >>> >>> The processes must be paused. If the processes would be running the linked >>> list is also broken since if we unlink and delete a JavaThread and then later >>> SA follows that _next pointer. >> >> Ah good point. Thanks for clarifying. >> >>>> >>>> The conversion from external iteration of the list (the for loop) to >>>> internal iteration (passing a lambda to JavaThreadsDo) is also problematic. >>>> First I'd be very wary about introducing lambda expressions into the SA code >>>> - lambda drags in a lot of supporting code that could have an impact on the >>>> way SA functions. There are places where we have to avoid lambdas due to >>>> bootstrapping/initialization issues and I think the SA may be an area where >>>> we also want to keep the code extremely simple. >>> >>> There are already several usages of lambdas in SA code, e.g. >>> LinuxDebuggerLocal.java. SA is not a core module, it's an application, there >>> is not a bootstrap issue or so. >> >> Hmm okay. Lambda carries a lot of baggage. But if its already being used ... >> >>>> Second by using lambda's with internal iteration you've lost the ability to >>>> terminate the iteration loop! In the existing code if we have a return in >>>> the for-loop then we not only terminate the loop but the enclosing method. >>>> With the lambda the "return" just ends the current iteration and >>>> JavaThreadsDo will then continue with the next thread - so we don't even >>>> terminate the iteration let alone the method performing the iteration. So >>>> for places were we want to process one thread, for example, we will continue >>>> to iterate all remaining threads and just do nothing with them. That's very >>>> inefficient. >>> >>> That's why I only used the internal iteration where we didn't have early >>> returns. >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java - >> original code: >> >> 1556???????? new Command("where", "where { -a | id }", false) { >> 1557???????????? public void doit(Tokens t) { >> ... >> 1564???????????????????? for (JavaThread thread = threads.first(); thread != >> null; thread = thread.next()) { >> 1565???????????????????????? ByteArrayOutputStream bos = new >> ByteArrayOutputStream(); >> 1566???????????????????????? thread.printThreadIDOn(new PrintStream(bos)); >> 1567???????????????????????? if (all || bos.toString().equals(name)) { >> 1568???????????????????????????? out.println("Thread " + bos.toString() + " >> Address: " + thread.getAddress()); >> ... >> 1577???????????????????????????? } >> 1578???????????????????????????? if (!all) return; >> >> That looks like an early return to me. >> >> Cheers, >> David >> ----- >> >> >>> Thanks, Robbin >>> >>>> >>>> Thanks, >>>> David >>>> >>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>> Hi, please review. >>>>> >>>>> Old threads linked list remove and updated SA to use ThreadsList array >>>>> instead. >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>> >>>>> Passes t1-3 (which includes SA tests). >>>>> >>>>> Thanks, Robbin From christoph.langer at sap.com Wed May 8 09:23:08 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 8 May 2019 09:23:08 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: Message-ID: Hi Ralf, thanks for the new webrev. It looks good. In GetListenAddressTest.java, the directive "@modules java.base/jdk.intenal.vm" can be removed as well. I've loaded the patch with this modification into our test system. But anyway, we'll need to wait for the CSR discussion until it can be pushed. Best regards Christoph > -----Original Message----- > From: Schmelter, Ralf > Sent: Dienstag, 7. Mai 2019 15:13 > To: Langer, Christoph ; serviceability- > dev at openjdk.java.net > Subject: RE: RFR 8223065: Add jcmd to get the listen address of the debugger > > Hi Christoph, > > thanks for the review. I've updated the webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.4/ > > Best regards, > Ralf > From christoph.langer at sap.com Wed May 8 09:29:53 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 8 May 2019 09:29:53 +0000 Subject: RFR 8223065: Add jcmd to get the listen address of the debugger In-Reply-To: References: Message-ID: Hi Alan, Ralf has opened a CSR for JDK-8214892: https://bugs.openjdk.java.net/browse/JDK-8223456 What will we do now? Shall we use this CSR to discuss how the VM options and jcmds/dcmds for "debugging on demand" will be named and what they will be? And in case, the outcome is different to what'll be actually implemented, will we do another change, referring to that CSR? I think I have some suggestions about the option(s). Shall I post comments to the CSR for that? Thanks Christoph > -----Original Message----- > From: Alan Bateman > Sent: Dienstag, 7. Mai 2019 15:25 > To: Schmelter, Ralf ; Langer, Christoph > ; serviceability-dev at openjdk.java.net > Subject: Re: RFR 8223065: Add jcmd to get the listen address of the debugger > > On 07/05/2019 14:13, Schmelter, Ralf wrote: > > Hi Christoph, > > > > thanks for the review. I've updated the webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8223065/webrev.4/ > > > Specifying onjcmd=y to the debugger agent looks very strange. Was there > a CSR submitted for JDK-8214892? I suspect that sub-option needs further > discussion before additional features on built on it. > > -Alan From coleen.phillimore at oracle.com Wed May 8 11:07:55 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 8 May 2019 07:07:55 -0400 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Message-ID: Looks good to me. Coleen On 5/8/19 5:20 AM, Robbin Ehn wrote: > Correct links: > http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html > > > http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ > http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ > > /Robbin > > On 2019-05-08 11:17, Robbin Ehn wrote: >> Hi David, >> >> I changed to normal for: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >> >> >> Full: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >> Inc: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >> >> Passes t1-2 >> >> Thanks, Robbin >> >> >> On 2019-05-07 09:47, David Holmes wrote: >>> Hi Robbin, >>> >>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>> Hi David, >>>> >>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>> Hi Robbin, >>>>> >>>>> I have a few concerns here. >>>>> >>>>> First I can't see how you are actually integrating the SA with the >>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate >>>>> but IIRC that list can be updated when threads are added/removed >>>>> and I'm not seeing how the SA is left iterating a valid list - >>>>> we'd normally using a ThreadsListHandle for that ?? (I may need a >>>>> refresher on how this list is actually maintained.) >>>> >>>> The processes must be paused. If the processes would be running the >>>> linked list is also broken since if we unlink and delete a >>>> JavaThread and then later SA follows that _next pointer. >>> >>> Ah good point. Thanks for clarifying. >>> >>>>> >>>>> The conversion from external iteration of the list (the for loop) >>>>> to internal iteration (passing a lambda to JavaThreadsDo) is also >>>>> problematic. First I'd be very wary about introducing lambda >>>>> expressions into the SA code - lambda drags in a lot of supporting >>>>> code that could have an impact on the way SA functions. There are >>>>> places where we have to avoid lambdas due to >>>>> bootstrapping/initialization issues and I think the SA may be an >>>>> area where we also want to keep the code extremely simple. >>>> >>>> There are already several usages of lambdas in SA code, e.g. >>>> LinuxDebuggerLocal.java. SA is not a core module, it's an >>>> application, there is not a bootstrap issue or so. >>> >>> Hmm okay. Lambda carries a lot of baggage. But if its already being >>> used ... >>> >>>>> Second by using lambda's with internal iteration you've lost the >>>>> ability to terminate the iteration loop! In the existing code if >>>>> we have a return in the for-loop then we not only terminate the >>>>> loop but the enclosing method. With the lambda the "return" just >>>>> ends the current iteration and JavaThreadsDo will then continue >>>>> with the next thread - so we don't even terminate the iteration >>>>> let alone the method performing the iteration. So for places were >>>>> we want to process one thread, for example, we will continue to >>>>> iterate all remaining threads and just do nothing with them. >>>>> That's very inefficient. >>>> >>>> That's why I only used the internal iteration where we didn't have >>>> early returns. >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>> - original code: >>> >>> 1556???????? new Command("where", "where { -a | id }", false) { >>> 1557???????????? public void doit(Tokens t) { >>> ... >>> 1564???????????????????? for (JavaThread thread = threads.first(); >>> thread != null; thread = thread.next()) { >>> 1565???????????????????????? ByteArrayOutputStream bos = new >>> ByteArrayOutputStream(); >>> 1566???????????????????????? thread.printThreadIDOn(new >>> PrintStream(bos)); >>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>> 1568???????????????????????????? out.println("Thread " + >>> bos.toString() + " Address: " + thread.getAddress()); >>> ... >>> 1577???????????????????????????? } >>> 1578???????????????????????????? if (!all) return; >>> >>> That looks like an early return to me. >>> >>> Cheers, >>> David >>> ----- >>> >>> >>>> Thanks, Robbin >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>> Hi, please review. >>>>>> >>>>>> Old threads linked list remove and updated SA to use ThreadsList >>>>>> array instead. >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>> >>>>>> Passes t1-3 (which includes SA tests). >>>>>> >>>>>> Thanks, Robbin From jcbeyler at google.com Wed May 8 14:49:04 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 8 May 2019 07:49:04 -0700 Subject: RFR (S) 8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism In-Reply-To: References: Message-ID: Hi Serguei, Done & Done; I think 10 instead of 5 will be ok. It only continues running if the sampling interval average has not converged so it should only lengthen degenerate cases. Thanks for the review, Jc On Wed, May 8, 2019 at 2:00 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Jc, > > A couple of minor comments. > > 37 private static final int maxCount = 5; > > Constant names are better to start from a capital letter. > Also, I'd suggest 10 instead of 5 to make it more reliable. > But it depend on how much it potentially can make the test to run slower. > > 94 // If we failed maxCount times, through the exception. > > A typo: replace "through" with "throw". > > > Otherwise, I'm Okay with this fix. > No need for another webrev. > > > Thanks, > Serguei > > > On 5/7/19 19:47, Jean Christophe Beyler wrote: > > Hi all, > > Could I get a review for this test fix: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8223441/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8223441 > > Backstory is: > When I fixed https://bugs.openjdk.java.net/browse/JDK-8215113, I fixed > this failing test in the "actually make the error calculation correct". But > it turns out the test itself failed 7 out of 10 times and when we tested > it, we were apparently "lucky". > > This fix makes the test pass 5k times so I am hopeful it will not show up > again. > > Extra notes: > - I fixed this by adding a loop that says: if we have not converged > yet, try again at max 5 times; generally we don't converge if the sampling > intervals chosen at the start just have pushed us far enough from the > average we expect that it takes more samples to get us back on track > > Thanks, > Jc > > Ps: FWIW, I'm going to look at the flakyness of the rest of the suite and > see if anything pops up to reduce the test bug noise of this suite > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed May 8 16:02:00 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 May 2019 12:02:00 -0400 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Message-ID: On 5/8/19 5:20 AM, Robbin Ehn wrote: > Correct links: > http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html > > > http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ > http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ src/hotspot/share/runtime/thread.hpp ??? No comments. src/hotspot/share/runtime/thread.cpp ??? No comments. src/hotspot/share/runtime/threadSMR.hpp ??? No comments. src/hotspot/share/runtime/vmStructs.cpp ??? No comments. It's nice to see that no code is using the old Threads::_thread_list or JavaThread::next() anymore. I have a vague memory of some Compiler Thread code still using it back when we first layered in ThreadSMR... Something about a fast way to find the next CompilerThread... That must have changed. Onward... General comment - Please make sure to update all copyright years before ????????????????? pushing this changeset. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/DeadlockDetector.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java ??? L46: ??? L47: ??? private static AddressField????? threadsField; ??? L48: ??? private static CIntegerField???? lengthField; ??????? nit - please delete blank line on L46 ??????? nit - please reduce the space between type and variable names ????????????? (I have no preference if you still keep them aligned) ??? nit - Please delete blank line on L74. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java ??? old L203: ????? Threads threads = VM.getVM().getThreads(); ??? old L204: ????? for (JavaThread cur = threads.first(); cur != null; cur = cur.next()) { ??? new L203: ????? VM.getVM().getThreads().doJavaThreads((cur) -> { ??????? In this case, you did a lambda conversion... src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java ??? old L75: ??????????? for (JavaThread cur = threads.first(); cur != null; cur = cur.next(), i++) { ??? new L75: ??????????? for (int k = 0; k < threads.getNumberOfThreads(); k++) { ??? new L76: ??????????????? JavaThread cur = threads.getJavaThreadAt(k); ??????? In this case, you didn't do a lambda conversion... ??????? I'm trying to grok a reason for the different styles... ??????? Update: Is is maybe a control flow thing? (No, I don't know much ?????????? about lambdas.) As in: Loops that "break" or early return are ?????????? not amenable to conversion to a lambda... (just guessing) ??? L74: ??????????? int i = 1; ??????? Not your bug, but I think that 'i' is not used. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaVM.java ??? No comments. test/hotspot/jtreg/serviceability/sa/ClhsdbField.java ??? No comments. test/hotspot/jtreg/serviceability/sa/ClhsdbPrintStatics.java ??? No comments. test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java ??? No comments. This all looks good to me... so thumbs up! I have some reservations about using lambdas in a debugging tool. My personal philosophy about debugging tools is that they should be built on the simplest/most stable technology to reduce the chances of the more complicated technology failing during a debug session. I hate it when my debugger crashes! That said, SA is pretty much standalone so use of lambdas in this debugging tool shouldn't affect the JVM or core file being debugged. Again, thumbs up! Dan > > /Robbin > > On 2019-05-08 11:17, Robbin Ehn wrote: >> Hi David, >> >> I changed to normal for: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >> >> >> Full: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >> Inc: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >> >> Passes t1-2 >> >> Thanks, Robbin >> >> >> On 2019-05-07 09:47, David Holmes wrote: >>> Hi Robbin, >>> >>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>> Hi David, >>>> >>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>> Hi Robbin, >>>>> >>>>> I have a few concerns here. >>>>> >>>>> First I can't see how you are actually integrating the SA with the >>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate >>>>> but IIRC that list can be updated when threads are added/removed >>>>> and I'm not seeing how the SA is left iterating a valid list - >>>>> we'd normally using a ThreadsListHandle for that ?? (I may need a >>>>> refresher on how this list is actually maintained.) >>>> >>>> The processes must be paused. If the processes would be running the >>>> linked list is also broken since if we unlink and delete a >>>> JavaThread and then later SA follows that _next pointer. >>> >>> Ah good point. Thanks for clarifying. >>> >>>>> >>>>> The conversion from external iteration of the list (the for loop) >>>>> to internal iteration (passing a lambda to JavaThreadsDo) is also >>>>> problematic. First I'd be very wary about introducing lambda >>>>> expressions into the SA code - lambda drags in a lot of supporting >>>>> code that could have an impact on the way SA functions. There are >>>>> places where we have to avoid lambdas due to >>>>> bootstrapping/initialization issues and I think the SA may be an >>>>> area where we also want to keep the code extremely simple. >>>> >>>> There are already several usages of lambdas in SA code, e.g. >>>> LinuxDebuggerLocal.java. SA is not a core module, it's an >>>> application, there is not a bootstrap issue or so. >>> >>> Hmm okay. Lambda carries a lot of baggage. But if its already being >>> used ... >>> >>>>> Second by using lambda's with internal iteration you've lost the >>>>> ability to terminate the iteration loop! In the existing code if >>>>> we have a return in the for-loop then we not only terminate the >>>>> loop but the enclosing method. With the lambda the "return" just >>>>> ends the current iteration and JavaThreadsDo will then continue >>>>> with the next thread - so we don't even terminate the iteration >>>>> let alone the method performing the iteration. So for places were >>>>> we want to process one thread, for example, we will continue to >>>>> iterate all remaining threads and just do nothing with them. >>>>> That's very inefficient. >>>> >>>> That's why I only used the internal iteration where we didn't have >>>> early returns. >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>> - original code: >>> >>> 1556???????? new Command("where", "where { -a | id }", false) { >>> 1557???????????? public void doit(Tokens t) { >>> ... >>> 1564???????????????????? for (JavaThread thread = threads.first(); >>> thread != null; thread = thread.next()) { >>> 1565???????????????????????? ByteArrayOutputStream bos = new >>> ByteArrayOutputStream(); >>> 1566???????????????????????? thread.printThreadIDOn(new >>> PrintStream(bos)); >>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>> 1568???????????????????????????? out.println("Thread " + >>> bos.toString() + " Address: " + thread.getAddress()); >>> ... >>> 1577???????????????????????????? } >>> 1578???????????????????????????? if (!all) return; >>> >>> That looks like an early return to me. >>> >>> Cheers, >>> David >>> ----- >>> >>> >>>> Thanks, Robbin >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>> Hi, please review. >>>>>> >>>>>> Old threads linked list remove and updated SA to use ThreadsList >>>>>> array instead. >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>> >>>>>> Passes t1-3 (which includes SA tests). >>>>>> >>>>>> Thanks, Robbin From gary.adams at oracle.com Wed May 8 20:18:00 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Wed, 8 May 2019 16:18:00 -0400 Subject: RFR: JDK-8223584 -Exclude javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java until JDK-8042215 is fixed Message-ID: Another trivial update to ProblemList an intermittent failing test. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -567,6 +567,7 @@ ?java/lang/management/ThreadMXBean/AllThreadIds.java 8131745 generic-all ?javax/management/monitor/DerivedGaugeMonitorTest.java 8042211 generic-all +javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java 8042215 generic-all From daniel.daugherty at oracle.com Wed May 8 20:20:13 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 8 May 2019 16:20:13 -0400 Subject: RFR: JDK-8223584 -Exclude javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java until JDK-8042215 is fixed In-Reply-To: References: Message-ID: <55c265fa-6313-aad4-3348-3dbde197e64c@oracle.com> Thumbs up and trivial. Dan On 5/8/19 4:18 PM, gary.adams at oracle.com wrote: > Another trivial update to ProblemList an intermittent failing test. > > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -567,6 +567,7 @@ > ?java/lang/management/ThreadMXBean/AllThreadIds.java 8131745 generic-all > > ?javax/management/monitor/DerivedGaugeMonitorTest.java 8042211 > generic-all > +javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java > 8042215 generic-all > From jcbeyler at google.com Wed May 8 22:53:49 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 8 May 2019 15:53:49 -0700 Subject: RFR (S) 8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism In-Reply-To: References: Message-ID: Hi all, Due to this failing pretty heavily a test it seems; is there any way I could get a second reviewer so I can hopefully calm the test bug demons? Thanks! Jc On Wed, May 8, 2019 at 7:49 AM Jean Christophe Beyler wrote: > Hi Serguei, > > Done & Done; I think 10 instead of 5 will be ok. It only continues running > if the sampling interval average has not converged so it should only > lengthen degenerate cases. > > Thanks for the review, > Jc > > On Wed, May 8, 2019 at 2:00 AM serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com> wrote: > >> Hi Jc, >> >> A couple of minor comments. >> >> 37 private static final int maxCount = 5; >> >> Constant names are better to start from a capital letter. >> Also, I'd suggest 10 instead of 5 to make it more reliable. >> But it depend on how much it potentially can make the test to run >> slower. >> >> 94 // If we failed maxCount times, through the exception. >> >> A typo: replace "through" with "throw". >> >> >> Otherwise, I'm Okay with this fix. >> No need for another webrev. >> >> >> Thanks, >> Serguei >> >> >> On 5/7/19 19:47, Jean Christophe Beyler wrote: >> >> Hi all, >> >> Could I get a review for this test fix: >> >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223441/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8223441 >> >> Backstory is: >> When I fixed https://bugs.openjdk.java.net/browse/JDK-8215113, I fixed >> this failing test in the "actually make the error calculation correct". But >> it turns out the test itself failed 7 out of 10 times and when we tested >> it, we were apparently "lucky". >> >> This fix makes the test pass 5k times so I am hopeful it will not show up >> again. >> >> Extra notes: >> - I fixed this by adding a loop that says: if we have not converged >> yet, try again at max 5 times; generally we don't converge if the sampling >> intervals chosen at the start just have pushed us far enough from the >> average we expect that it takes more samples to get us back on track >> >> Thanks, >> Jc >> >> Ps: FWIW, I'm going to look at the flakyness of the rest of the suite and >> see if anything pops up to reduce the test bug noise of this suite >> >> >> > > -- > > Thanks, > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Wed May 8 22:57:02 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 8 May 2019 15:57:02 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version Message-ID: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> Please, review a fix for the task: ? https://bugs.openjdk.java.net/browse/JDK-8219023 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ Summary: ?By design as we have never bumped the JVMTI version unless ?there were spec changes for that release. Now we want to sync ?the JVMTI version with the JDK version regardless of whether ?or not spec changes have occurred in that release. ?Also, we want it automatically set by the build system so that ?no manual updates are needed for each release. ?The jvmti.h and jvmti.html (JVMTI spec) are generated from ?the jvmti.xsl with the XSLT scripts now. So, the fix removes ?hard coded major, minor and micro versions from the jvmti.xml ?and passes major and minor parameters with the -PARAMETER ?to the XSL transformation. ?Another part of the fix is in the JDI which starts using JDK ?versions now instead of maintaining its own, and in the JDWP ?agent which is using the JVMTI versions instead of its own. Testing: ?Generated docs and jvmti.h and checked the versions are correct. One could ask if we have to use same or similar approach for other API's and tools, like JNI, JMX and so on. But these are not areas of my expertise or responsibility. It just feels like there is some room for unification here. Thanks, Serguei From jcbeyler at google.com Wed May 8 23:06:13 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 8 May 2019 16:06:13 -0700 Subject: RFR (L) 8220747: Migrate data structures to being more C++ In-Reply-To: <4927d1b1-49ad-9be7-d2ca-483e521f7b18@oracle.com> References: <4927d1b1-49ad-9be7-d2ca-483e521f7b18@oracle.com> Message-ID: Hi David, Thanks for the quick look :) I moved the code around to really only have the minimal part in the extern C part. It seems that the link you are providing seems to show that what we did is the right thing then so that seems like it's a good start I guess! Here is an updated webrev: Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.03/ I left the structs in structs so I did not have to append the fields with '_', which otherwise made the code review feel (to me) messy. Thanks again for your help, Jc On Wed, May 1, 2019 at 10:22 PM David Holmes wrote: > Hi Jc, > > I just a had a quick look at this so not a full review - sorry. > > I'm not sure it makes sense to define classes within "extern C {". The > extern C is intended to define an interface for this C++ library to be > used from a C program - as discussed here for your Solaris issue: > > https://docs.oracle.com/cd/E18659_01/html/821-1383/bkamu.html > > Cheers, > David > > On 2/05/2019 1:08 pm, Jean Christophe Beyler wrote: > > Hi all, > > > > Re-sending with the full title.... > > > > (OK... so JC will promise to go around the block 3 times before > submitting > > a review request; and will do any item you would like to redeem myself; I > > apologize profusely and feel horrible...) > > > > I want to move the libHeapMonitorTest.c to C++ and here is the first > "step" > > towards that. There are two parts to this: move the file to C++ and move > > some of the C-style to C++-style code. > > > > But this webrev failed on solaris; Igor helped me figure it out and his > > solution was to add the change to the JtregNativeHotspot.gmk for > solstudio. > > We are not sure this is the "right" solution to this and hence have added > > both the serviceability and build lists to review both file changes and > > figure out what is best :) > > > > This does pass the submit-repo testing and the tests on my local dev > > machine. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8220747 > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8220747/webrev.02/ > > > > Thanks all for your help, > > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu May 9 01:39:09 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 May 2019 18:39:09 -0700 Subject: RFR (S) 8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism In-Reply-To: References: Message-ID: <7d949da8-4b73-2372-3cd1-2d59b3c04cd9@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 9 01:42:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 May 2019 11:42:21 +1000 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> Message-ID: Hi Serguei, On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com wrote: > Please, review a fix for the task: > ? https://bugs.openjdk.java.net/browse/JDK-8219023 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ > > Summary: > > ?By design as we have never bumped the JVMTI version unless > ?there were spec changes for that release. Now we want to sync > ?the JVMTI version with the JDK version regardless of whether > ?or not spec changes have occurred in that release. > ?Also, we want it automatically set by the build system so that > ?no manual updates are needed for each release. > > ?The jvmti.h and jvmti.html (JVMTI spec) are generated from > ?the jvmti.xsl with the XSLT scripts now. So, the fix removes > ?hard coded major, minor and micro versions from the jvmti.xml > ?and passes major and minor parameters with the -PARAMETER > ?to the XSL transformation. > > ?Another part of the fix is in the JDI which starts using JDK > ?versions now instead of maintaining its own, and in the JDWP > ?agent which is using the JVMTI versions instead of its own. This all seems reasonable (though I'm no expert on working with XSL etc). One thing I am unclear of is why you bother with using VERSION_INTERIM when the actual version check will only consider VERSION_FEATURE (aka major). Couldn't you just leave the "minor" part 0 the same as the "micro" part? For the record I considered whether this needs a CSR request and concluded it did not as it doesn't involve changing any actual specifications. Thanks, David > Testing: > ?Generated docs and jvmti.h and checked the versions are correct. > > One could ask if we have to use same or similar approach for > other API's and tools, like JNI, JMX and so on. > But these are not areas of my expertise or responsibility. > It just feels like there is some room for unification here. > > Thanks, > Serguei From chris.plummer at oracle.com Thu May 9 02:10:36 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 May 2019 19:10:36 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> Message-ID: <85df23aa-b96f-c099-2220-279f50de9fde@oracle.com> Hi Serguei, Changes look good. Can you verify that the .jtr file for com/sun/jdi tests has all the versions updated? For example, you will currently see: JVM version:13-ea JDI version: 11.0 JVM description: Java Debug Interface (Reference Implementation) version 11.0 Java Debug Wire Protocol (Reference Implementation) version 11.0 JVM Debug Interface version 11.0 JVM version 13-ea (Java HotSpot(TM) 64-Bit Server VM, mixed mode, sharing) I think your intent is for all of these to be updated from 11 to 13. thanks, Chris On 5/8/19 3:57 PM, serguei.spitsyn at oracle.com wrote: > Please, review a fix for the task: > ? https://bugs.openjdk.java.net/browse/JDK-8219023 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ > > Summary: > > ?By design as we have never bumped the JVMTI version unless > ?there were spec changes for that release. Now we want to sync > ?the JVMTI version with the JDK version regardless of whether > ?or not spec changes have occurred in that release. > ?Also, we want it automatically set by the build system so that > ?no manual updates are needed for each release. > > ?The jvmti.h and jvmti.html (JVMTI spec) are generated from > ?the jvmti.xsl with the XSLT scripts now. So, the fix removes > ?hard coded major, minor and micro versions from the jvmti.xml > ?and passes major and minor parameters with the -PARAMETER > ?to the XSL transformation. > > ?Another part of the fix is in the JDI which starts using JDK > ?versions now instead of maintaining its own, and in the JDWP > ?agent which is using the JVMTI versions instead of its own. > > Testing: > ?Generated docs and jvmti.h and checked the versions are correct. > > One could ask if we have to use same or similar approach for > other API's and tools, like JNI, JMX and so on. > But these are not areas of my expertise or responsibility. > It just feels like there is some room for unification here. > > Thanks, > Serguei From jcbeyler at google.com Thu May 9 03:26:35 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 8 May 2019 20:26:35 -0700 Subject: RFR (S) 8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism In-Reply-To: <7d949da8-4b73-2372-3cd1-2d59b3c04cd9@oracle.com> References: <7d949da8-4b73-2372-3cd1-2d59b3c04cd9@oracle.com> Message-ID: Yes and actually the count variable too were missing due to a mishap when generating the webrev... I had this in my local diff: public static void main(String[] args) { int sizes[] = {1000, 10000, 100000}; + double expected = 0; + int count = 0; for (int currentSize : sizes) { System.out.println("Testing size " + currentSize); Which fixes the issue you were seeing... Thanks for the review! Jc *From: *Chris Plummer *Date: *Wed, May 8, 2019 at 6:39 PM *To: *Jean Christophe Beyler, serguei.spitsyn at oracle.com *Cc: *OpenJDK Serviceability Hi JC, > > I don't see how this builds. You used to have: > > 78 double expected = maxIteration; > > Now you have: > > 81 expected = maxIteration * count; > > And I don't see a declaration of "expected" anywhere. > > Other than that the changes look fine. > > thanks, > > Chris > > On 5/8/19 3:53 PM, Jean Christophe Beyler wrote: > > Hi all, > > Due to this failing pretty heavily a test it seems; is there any way I > could get a second reviewer so I can hopefully calm the test bug demons? > > Thanks! > Jc > > On Wed, May 8, 2019 at 7:49 AM Jean Christophe Beyler > wrote: > >> Hi Serguei, >> >> Done & Done; I think 10 instead of 5 will be ok. It only continues >> running if the sampling interval average has not converged so it should >> only lengthen degenerate cases. >> >> Thanks for the review, >> Jc >> >> On Wed, May 8, 2019 at 2:00 AM serguei.spitsyn at oracle.com < >> serguei.spitsyn at oracle.com> wrote: >> >>> Hi Jc, >>> >>> A couple of minor comments. >>> >>> 37 private static final int maxCount = 5; >>> >>> Constant names are better to start from a capital letter. >>> Also, I'd suggest 10 instead of 5 to make it more reliable. >>> But it depend on how much it potentially can make the test to run >>> slower. >>> >>> 94 // If we failed maxCount times, through the exception. >>> >>> A typo: replace "through" with "throw". >>> >>> >>> Otherwise, I'm Okay with this fix. >>> No need for another webrev. >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/7/19 19:47, Jean Christophe Beyler wrote: >>> >>> Hi all, >>> >>> Could I get a review for this test fix: >>> >>> Webrev: http://cr.openjdk.java.net/~jcbeyler/8223441/webrev.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223441 >>> >>> Backstory is: >>> When I fixed https://bugs.openjdk.java.net/browse/JDK-8215113, I fixed >>> this failing test in the "actually make the error calculation correct". But >>> it turns out the test itself failed 7 out of 10 times and when we tested >>> it, we were apparently "lucky". >>> >>> This fix makes the test pass 5k times so I am hopeful it will not show >>> up again. >>> >>> Extra notes: >>> - I fixed this by adding a loop that says: if we have not converged >>> yet, try again at max 5 times; generally we don't converge if the sampling >>> intervals chosen at the start just have pushed us far enough from the >>> average we expect that it takes more samples to get us back on track >>> >>> Thanks, >>> Jc >>> >>> Ps: FWIW, I'm going to look at the flakyness of the rest of the suite >>> and see if anything pops up to reduce the test bug noise of this suite >>> >>> >>> >> >> -- >> >> Thanks, >> Jc >> > > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu May 9 03:27:40 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 8 May 2019 20:27:40 -0700 Subject: RFR (S) 8223441: HeapMonitorStatArrayCorrectnessTest fails due to sampling determinism In-Reply-To: References: <7d949da8-4b73-2372-3cd1-2d59b3c04cd9@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 9 04:46:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 May 2019 14:46:52 +1000 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Message-ID: Hi Robbin, On 8/05/2019 7:20 pm, Robbin Ehn wrote: > Correct links: > http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html So you removed all uses of lambda in that file ... okay src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java As Dan also hints at you are a bit inconsistent with keeping loops or replacing with lambda's. Anything that would do a "break" or "return" in the loop can't be converted to a lambda; but "continue" becomes "return" in the lambda version. Overall I'd just say forget about any internal iteration using lambdas and just make the simple changes needed for the loop version. It's a less disruptive change and doesn't add the complexity and overhead of lambda expressions. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java Existing: 76 JavaThread cur = threads.getJavaThreadAt(k); 77 if (cur.isJavaThread()) { How can cur possibly be anything other than a JavaThread? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java Same issue: 463 if (t.isJavaThread()) { Possibly more of these I didn't go searching - so probably separate cleanup RFE. --- Up to you whether you want to keep lambda's but at least ensure consistency in their use - ie use them everywhere you can. But you know my thoughts on it. :) Thanks, David ----- > > http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ > http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ > > /Robbin > > On 2019-05-08 11:17, Robbin Ehn wrote: >> Hi David, >> >> I changed to normal for: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >> >> >> Full: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >> Inc: >> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >> >> Passes t1-2 >> >> Thanks, Robbin >> >> >> On 2019-05-07 09:47, David Holmes wrote: >>> Hi Robbin, >>> >>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>> Hi David, >>>> >>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>> Hi Robbin, >>>>> >>>>> I have a few concerns here. >>>>> >>>>> First I can't see how you are actually integrating the SA with the >>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate >>>>> but IIRC that list can be updated when threads are added/removed >>>>> and I'm not seeing how the SA is left iterating a valid list - we'd >>>>> normally using a ThreadsListHandle for that ?? (I may need a >>>>> refresher on how this list is actually maintained.) >>>> >>>> The processes must be paused. If the processes would be running the >>>> linked list is also broken since if we unlink and delete a >>>> JavaThread and then later SA follows that _next pointer. >>> >>> Ah good point. Thanks for clarifying. >>> >>>>> >>>>> The conversion from external iteration of the list (the for loop) >>>>> to internal iteration (passing a lambda to JavaThreadsDo) is also >>>>> problematic. First I'd be very wary about introducing lambda >>>>> expressions into the SA code - lambda drags in a lot of supporting >>>>> code that could have an impact on the way SA functions. There are >>>>> places where we have to avoid lambdas due to >>>>> bootstrapping/initialization issues and I think the SA may be an >>>>> area where we also want to keep the code extremely simple. >>>> >>>> There are already several usages of lambdas in SA code, e.g. >>>> LinuxDebuggerLocal.java. SA is not a core module, it's an >>>> application, there is not a bootstrap issue or so. >>> >>> Hmm okay. Lambda carries a lot of baggage. But if its already being >>> used ... >>> >>>>> Second by using lambda's with internal iteration you've lost the >>>>> ability to terminate the iteration loop! In the existing code if we >>>>> have a return in the for-loop then we not only terminate the loop >>>>> but the enclosing method. With the lambda the "return" just ends >>>>> the current iteration and JavaThreadsDo will then continue with the >>>>> next thread - so we don't even terminate the iteration let alone >>>>> the method performing the iteration. So for places were we want to >>>>> process one thread, for example, we will continue to iterate all >>>>> remaining threads and just do nothing with them. That's very >>>>> inefficient. >>>> >>>> That's why I only used the internal iteration where we didn't have >>>> early returns. >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>> - original code: >>> >>> 1556???????? new Command("where", "where { -a | id }", false) { >>> 1557???????????? public void doit(Tokens t) { >>> ... >>> 1564???????????????????? for (JavaThread thread = threads.first(); >>> thread != null; thread = thread.next()) { >>> 1565???????????????????????? ByteArrayOutputStream bos = new >>> ByteArrayOutputStream(); >>> 1566???????????????????????? thread.printThreadIDOn(new >>> PrintStream(bos)); >>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>> 1568???????????????????????????? out.println("Thread " + >>> bos.toString() + " Address: " + thread.getAddress()); >>> ... >>> 1577???????????????????????????? } >>> 1578???????????????????????????? if (!all) return; >>> >>> That looks like an early return to me. >>> >>> Cheers, >>> David >>> ----- >>> >>> >>>> Thanks, Robbin >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>> Hi, please review. >>>>>> >>>>>> Old threads linked list remove and updated SA to use ThreadsList >>>>>> array instead. >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>> >>>>>> Passes t1-3 (which includes SA tests). >>>>>> >>>>>> Thanks, Robbin From sakamoto.osamu at nttcom.co.jp Thu May 9 08:33:22 2019 From: sakamoto.osamu at nttcom.co.jp (=?iso-2022-jp?B?GyRCOmRLXBsoQiAbJEJFfRsoQg==?=) Date: Thu, 9 May 2019 08:33:22 +0000 Subject: debugd options should regard to jhsdb style Message-ID: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> Hi all, I want to use `jhsdb debugd` on my laptop. However debugd mode has different options from other modes. I think debugd should have same options like other modes. For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. Also I added `--serverid` option for serverid. I attached a patch for this enhancement. This patch passes serviceability/sa jtreg tests. Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . However it has been disabled by JDK-8163805. It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. Could you help? I want to contribute it. I need a sponsor. (My company has signed to OCA (NTT Comware Corporation)) Thanks, Osamu -------------- next part -------------- A non-text attachment was scrubbed... Name: debugd.patch Type: application/octet-stream Size: 3879 bytes Desc: debugd.patch URL: From serguei.spitsyn at oracle.com Thu May 9 08:51:51 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 May 2019 01:51:51 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <85df23aa-b96f-c099-2220-279f50de9fde@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <85df23aa-b96f-c099-2220-279f50de9fde@oracle.com> Message-ID: Hi Chris, Thank you for the review! Yes, it is fixed now: ----------System.out:(27/1669)---------- vmOpts: '' javaOpts: '' JVM version:13-internal JDI version: 13.0 JVM description: Java Debug Interface (Reference Implementation) version 13.0 Java Debug Wire Protocol (Reference Implementation) version 13.0 JVM Debug Interface version 13.0 JVM version 13-internal (Java HotSpot(TM) 64-Bit Server VM, mixed mode, sharing) Howdy! ??? Visible variables at this point are: I think, it is Okay to print JVM version as it is now (13-internal). Thanks, Serguei On 5/8/19 19:10, Chris Plummer wrote: > Hi Serguei, > > Changes look good. Can you verify that the .jtr file for com/sun/jdi > tests has all the versions updated? For example, you will currently see: > > JVM version:13-ea > JDI version: 11.0 > JVM description: Java Debug Interface (Reference Implementation) > version 11.0 > Java Debug Wire Protocol (Reference Implementation) version 11.0 > JVM Debug Interface version 11.0 > JVM version 13-ea (Java HotSpot(TM) 64-Bit Server VM, mixed mode, > sharing) > > I think your intent is for all of these to be updated from 11 to 13. > > thanks, > > Chris > > > On 5/8/19 3:57 PM, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for the task: >> ? https://bugs.openjdk.java.net/browse/JDK-8219023 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >> >> Summary: >> >> ?By design as we have never bumped the JVMTI version unless >> ?there were spec changes for that release. Now we want to sync >> ?the JVMTI version with the JDK version regardless of whether >> ?or not spec changes have occurred in that release. >> ?Also, we want it automatically set by the build system so that >> ?no manual updates are needed for each release. >> >> ?The jvmti.h and jvmti.html (JVMTI spec) are generated from >> ?the jvmti.xsl with the XSLT scripts now. So, the fix removes >> ?hard coded major, minor and micro versions from the jvmti.xml >> ?and passes major and minor parameters with the -PARAMETER >> ?to the XSL transformation. >> >> ?Another part of the fix is in the JDI which starts using JDK >> ?versions now instead of maintaining its own, and in the JDWP >> ?agent which is using the JVMTI versions instead of its own. >> >> Testing: >> ?Generated docs and jvmti.h and checked the versions are correct. >> >> One could ask if we have to use same or similar approach for >> other API's and tools, like JNI, JMX and so on. >> But these are not areas of my expertise or responsibility. >> It just feels like there is some room for unification here. >> >> Thanks, >> Serguei > > > From serguei.spitsyn at oracle.com Thu May 9 09:09:47 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 May 2019 02:09:47 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> Message-ID: <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 9 13:13:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 May 2019 23:13:11 +1000 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> Message-ID: <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> Hi Serguei, On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you a lot for review! > There are some replies below. > > > On 5/8/19 18:42, David Holmes wrote: >> Hi Serguei, >> >> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for the task: >>> https://bugs.openjdk.java.net/browse/JDK-8219023 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >>> >>> Summary: >>> >>> ??By design as we have never bumped the JVMTI version unless >>> ??there were spec changes for that release. Now we want to sync >>> ??the JVMTI version with the JDK version regardless of whether >>> ??or not spec changes have occurred in that release. >>> ??Also, we want it automatically set by the build system so that >>> ??no manual updates are needed for each release. >>> >>> ??The jvmti.h and jvmti.html (JVMTI spec) are generated from >>> ??the jvmti.xsl with the XSLT scripts now. So, the fix removes >>> ??hard coded major, minor and micro versions from the jvmti.xml >>> ??and passes major and minor parameters with the -PARAMETER >>> ??to the XSL transformation. >>> >>> ??Another part of the fix is in the JDI which starts using JDK >>> ??versions now instead of maintaining its own, and in the JDWP >>> ??agent which is using the JVMTI versions instead of its own. >> >> This all seems reasonable (though I'm no expert on working with XSL etc). >> >> One thing I am unclear of is why you bother with using VERSION_INTERIM >> when the actual version check will only consider VERSION_FEATURE (aka >> major). Couldn't you just leave the "minor" part 0 the same as the >> "micro" part? > > This is right question to ask. > I was two-folded on this. > But finally decided to maintain minor version (aka VERSION_INTERIM). > Then the JVMTI and debugger version will match the VM and JDK version > for update releases. > If understand it correctly, we are still going to have major.minor versions. Not really. What we have now are things like 11.0.3 and 12.0.1 - only using the first and third parts. The full 4 part version string is: $VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH and we typically only update version_feature and version_update. https://openjdk.java.net/jeps/322 > Also, the JVMTI GetVersionNumberspec still tells about both minor and > micro versions. > It also defines special constants for corresponding masks and shifts: > > Version Masks > Constant Value Description > |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 Mask to extract > interface type. The value of the version returned by this function > masked with |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always > |JVMTI_VERSION_INTERFACE_JVMTI| since this is a JVMTI function. > |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000 Mask to extract major > version number. > |JVMTI_VERSION_MASK_MINOR| 0x0000FF00 Mask to extract minor > version number. > |JVMTI_VERSION_MASK_MICRO| 0x000000FF Mask to extract micro > version number. > > Version Shifts > Constant Value Description > |JVMTI_VERSION_SHIFT_MAJOR| 16 Shift to extract major version number. > |JVMTI_VERSION_SHIFT_MINOR| 8 Shift to extract minor version number. > |JVMTI_VERSION_SHIFT_MICRO| 0 Shift to extract micro version number. > > > This is link to the spec: > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber > > It seems, changing (and/or deprecating) this will give more problems > than benefits. > It is better to remain compatible with previous releases. This is a problem that was flagged when the new versioning scheme was introduced but I'm guessing nothing was actually done about it. They are not really compatible beyond the major/feature part. If we only update the spec version with the feature version then all versions will have the form N.0.0. However your changes will also update if we happen to use a VERSION_INTERIM for some reason - though the version check will ignore that anyway. I'm not really seeing the point in having that happen. Maybe we do need to define a new version API that maps to the new versioning scheme of OpenJDK ? But if we did that we'd still have to support the legacy mapping and I'd still advocate simply using VERSION_FEATURE.0.0. It's tricky. David ----- >> For the record I considered whether this needs a CSR request and >> concluded it did not as it doesn't involve changing any actual >> specifications. > > Okay, thanks. > I considered it too, made the same conclusion but still have some doubt. :) > > Thanks! > Serguei > >> >> Thanks, >> David >> >>> Testing: >>> ??Generated docs and jvmti.h and checked the versions are correct. >>> >>> One could ask if we have to use same or similar approach for >>> other API's and tools, like JNI, JMX and so on. >>> But these are not areas of my expertise or responsibility. >>> It just feels like there is some room for unification here. >>> >>> Thanks, >>> Serguei > From serguei.spitsyn at oracle.com Thu May 9 15:48:13 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 May 2019 08:48:13 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> Message-ID: <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> I'll try to get rid of VERSION_INTERIM. Always using just VERSION_FEATURE.0.0 should not create problems if we do not change JVMTI spec in VERSION_UPDATE. I do not see why we would change the JVMTI spec in update releases. But if we do then using VERSION_UPDATE as microversion would be good enough. Thanks! Serguei On 5/9/19 06:13, David Holmes wrote: > Hi Serguei, > > On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you a lot for review! >> There are some replies below. >> >> >> On 5/8/19 18:42, David Holmes wrote: >>> Hi Serguei, >>> >>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com wrote: >>>> Please, review a fix for the task: >>>> https://bugs.openjdk.java.net/browse/JDK-8219023 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >>>> >>>> >>>> Summary: >>>> >>>> ??By design as we have never bumped the JVMTI version unless >>>> ??there were spec changes for that release. Now we want to sync >>>> ??the JVMTI version with the JDK version regardless of whether >>>> ??or not spec changes have occurred in that release. >>>> ??Also, we want it automatically set by the build system so that >>>> ??no manual updates are needed for each release. >>>> >>>> ??The jvmti.h and jvmti.html (JVMTI spec) are generated from >>>> ??the jvmti.xsl with the XSLT scripts now. So, the fix removes >>>> ??hard coded major, minor and micro versions from the jvmti.xml >>>> ??and passes major and minor parameters with the -PARAMETER >>>> ??to the XSL transformation. >>>> >>>> ??Another part of the fix is in the JDI which starts using JDK >>>> ??versions now instead of maintaining its own, and in the JDWP >>>> ??agent which is using the JVMTI versions instead of its own. >>> >>> This all seems reasonable (though I'm no expert on working with XSL >>> etc). >>> >>> One thing I am unclear of is why you bother with using >>> VERSION_INTERIM when the actual version check will only consider >>> VERSION_FEATURE (aka major). Couldn't you just leave the "minor" >>> part 0 the same as the "micro" part? >> >> This is right question to ask. >> I was two-folded on this. >> But finally decided to maintain minor version (aka VERSION_INTERIM). >> Then the JVMTI and debugger version will match the VM and JDK version >> for update releases. >> If understand it correctly, we are still going to have major.minor >> versions. > > Not really. What we have now are things like 11.0.3 and 12.0.1 - only > using the first and third parts. The full 4 part version string is: > > $VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH > > and we typically only update version_feature and version_update. > > https://openjdk.java.net/jeps/322 > >> Also, the JVMTI GetVersionNumberspec still tells about both minor and >> micro versions. >> It also defines special constants for corresponding masks and shifts: >> >> ??? Version Masks >> ??? Constant???? Value???? Description >> ??? |JVMTI_VERSION_MASK_INTERFACE_TYPE|???? 0x70000000???? Mask to >> extract >> ??? interface type. The value of the version returned by this function >> ??? masked with |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always >> ??? |JVMTI_VERSION_INTERFACE_JVMTI| since this is a JVMTI function. >> ??? |JVMTI_VERSION_MASK_MAJOR|???? 0x0FFF0000???? Mask to extract major >> ??? version number. >> ??? |JVMTI_VERSION_MASK_MINOR|???? 0x0000FF00???? Mask to extract minor >> ??? version number. >> ??? |JVMTI_VERSION_MASK_MICRO|???? 0x000000FF???? Mask to extract micro >> ??? version number. >> >> ??? Version Shifts >> ??? Constant???? Value???? Description >> ??? |JVMTI_VERSION_SHIFT_MAJOR|???? 16???? Shift to extract major >> version number. >> ??? |JVMTI_VERSION_SHIFT_MINOR|???? 8???? Shift to extract minor >> version number. >> ??? |JVMTI_VERSION_SHIFT_MICRO|???? 0???? Shift to extract micro >> version number. >> >> >> This is link to the spec: >> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber >> >> >> It seems, changing (and/or deprecating) this will give more problems >> than benefits. >> It is better to remain compatible with previous releases. > > This is a problem that was flagged when the new versioning scheme was > introduced but I'm guessing nothing was actually done about it. They > are not really compatible beyond the major/feature part. > > If we only update the spec version with the feature version then all > versions will have the form N.0.0. However your changes will also > update if we happen to use a VERSION_INTERIM for some reason - though > the version check will ignore that anyway. I'm not really seeing the > point in having that happen. > > Maybe we do need to define a new version API that maps to the new > versioning scheme of OpenJDK ? But if we did that we'd still have to > support the legacy mapping and I'd still advocate simply using > VERSION_FEATURE.0.0. > > It's tricky. > > David > ----- > >>> For the record I considered whether this needs a CSR request and >>> concluded it did not as it doesn't involve changing any actual >>> specifications. >> >> Okay, thanks. >> I considered it too, made the same conclusion but still have some >> doubt. :) >> >> Thanks! >> Serguei >> >>> >>> Thanks, >>> David >>> >>>> Testing: >>>> ??Generated docs and jvmti.h and checked the versions are correct. >>>> >>>> One could ask if we have to use same or similar approach for >>>> other API's and tools, like JNI, JMX and so on. >>>> But these are not areas of my expertise or responsibility. >>>> It just feels like there is some room for unification here. >>>> >>>> Thanks, >>>> Serguei >> From jcbeyler at google.com Thu May 9 16:10:43 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 9 May 2019 09:10:43 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> Message-ID: Hi Serguei, FWIW, the change looks good and I think it's a good idea to do. However, there is one thorn in our internal agent code is that the JVMTI_VERSION is in an enum. This makes us unable to #if it when adding usages of newer features/methods. This probably could/should be a different webrev (which I can do if you like) but is there any way while you are changing this that the enum for JVMTI_VERSION could become a set of #define? So instead of: enum { JVMTI_VERSION_1 = 0x30010000, JVMTI_VERSION_1_0 = 0x30010000, JVMTI_VERSION_1_1 = 0x30010100, JVMTI_VERSION_1_2 = 0x30010200, JVMTI_VERSION_9 = 0x30090000, JVMTI_VERSION_11 = 0x300B0000, JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 /* version: 11.0.0 */ }; We would get: #define JVMTI_VERSION_1 0x30010000 #define JVMTI_VERSION_1_0 0x30010000 #define JVMTI_VERSION_1_1 = 0x30010100 #define JVMTI_VERSION_1_2 = 0x30010200 #define JVMTI_VERSION_9 = 0x30090000 #define JVMTI_VERSION_11 = 0x300B0000 #define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 /* version: 11.0.0 */) I actually don't care about any define of these except for JVMTI_VERSION; basically it would be useful so that in our agent code we can test the JVMTI_VERSION with #if macros to protect the code when new elements show up in future versions. So it also could be: enum { JVMTI_VERSION_1 = 0x30010000, JVMTI_VERSION_1_0 = 0x30010000, JVMTI_VERSION_1_1 = 0x30010100, JVMTI_VERSION_1_2 = 0x30010200, JVMTI_VERSION_9 = 0x30090000, JVMTI_VERSION_11 = 0x300B0000, JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 /* version: 11.0.0 */ }; #define JVMTI_LATEST_VERSION (0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 /* version: 11.0.0 */) Right now, I have to do weird things where I detect the jvmti.h used at compile time to then do -DUSING_JDK11 for the agent at compile time. Thanks! Jc On Thu, May 9, 2019 at 8:48 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > I'll try to get rid of VERSION_INTERIM. > Always using just VERSION_FEATURE.0.0 should not create problems > if we do not change JVMTI spec in VERSION_UPDATE. > I do not see why we would change the JVMTI spec in update releases. > But if we do then using VERSION_UPDATE as microversion would be good > enough. > > Thanks! > Serguei > > > On 5/9/19 06:13, David Holmes wrote: > > Hi Serguei, > > > > On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com wrote: > >> Hi David, > >> > >> Thank you a lot for review! > >> There are some replies below. > >> > >> > >> On 5/8/19 18:42, David Holmes wrote: > >>> Hi Serguei, > >>> > >>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com wrote: > >>>> Please, review a fix for the task: > >>>> https://bugs.openjdk.java.net/browse/JDK-8219023 > >>>> > >>>> Webrev: > >>>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ > >>>> > >>>> > >>>> Summary: > >>>> > >>>> By design as we have never bumped the JVMTI version unless > >>>> there were spec changes for that release. Now we want to sync > >>>> the JVMTI version with the JDK version regardless of whether > >>>> or not spec changes have occurred in that release. > >>>> Also, we want it automatically set by the build system so that > >>>> no manual updates are needed for each release. > >>>> > >>>> The jvmti.h and jvmti.html (JVMTI spec) are generated from > >>>> the jvmti.xsl with the XSLT scripts now. So, the fix removes > >>>> hard coded major, minor and micro versions from the jvmti.xml > >>>> and passes major and minor parameters with the -PARAMETER > >>>> to the XSL transformation. > >>>> > >>>> Another part of the fix is in the JDI which starts using JDK > >>>> versions now instead of maintaining its own, and in the JDWP > >>>> agent which is using the JVMTI versions instead of its own. > >>> > >>> This all seems reasonable (though I'm no expert on working with XSL > >>> etc). > >>> > >>> One thing I am unclear of is why you bother with using > >>> VERSION_INTERIM when the actual version check will only consider > >>> VERSION_FEATURE (aka major). Couldn't you just leave the "minor" > >>> part 0 the same as the "micro" part? > >> > >> This is right question to ask. > >> I was two-folded on this. > >> But finally decided to maintain minor version (aka VERSION_INTERIM). > >> Then the JVMTI and debugger version will match the VM and JDK version > >> for update releases. > >> If understand it correctly, we are still going to have major.minor > >> versions. > > > > Not really. What we have now are things like 11.0.3 and 12.0.1 - only > > using the first and third parts. The full 4 part version string is: > > > > $VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH > > > > and we typically only update version_feature and version_update. > > > > https://openjdk.java.net/jeps/322 > > > >> Also, the JVMTI GetVersionNumberspec still tells about both minor and > >> micro versions. > >> It also defines special constants for corresponding masks and shifts: > >> > >> Version Masks > >> Constant Value Description > >> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 Mask to > >> extract > >> interface type. The value of the version returned by this function > >> masked with |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always > >> |JVMTI_VERSION_INTERFACE_JVMTI| since this is a JVMTI function. > >> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000 Mask to extract major > >> version number. > >> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00 Mask to extract minor > >> version number. > >> |JVMTI_VERSION_MASK_MICRO| 0x000000FF Mask to extract micro > >> version number. > >> > >> Version Shifts > >> Constant Value Description > >> |JVMTI_VERSION_SHIFT_MAJOR| 16 Shift to extract major > >> version number. > >> |JVMTI_VERSION_SHIFT_MINOR| 8 Shift to extract minor > >> version number. > >> |JVMTI_VERSION_SHIFT_MICRO| 0 Shift to extract micro > >> version number. > >> > >> > >> This is link to the spec: > >> > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber > >> > >> > >> It seems, changing (and/or deprecating) this will give more problems > >> than benefits. > >> It is better to remain compatible with previous releases. > > > > This is a problem that was flagged when the new versioning scheme was > > introduced but I'm guessing nothing was actually done about it. They > > are not really compatible beyond the major/feature part. > > > > If we only update the spec version with the feature version then all > > versions will have the form N.0.0. However your changes will also > > update if we happen to use a VERSION_INTERIM for some reason - though > > the version check will ignore that anyway. I'm not really seeing the > > point in having that happen. > > > > Maybe we do need to define a new version API that maps to the new > > versioning scheme of OpenJDK ? But if we did that we'd still have to > > support the legacy mapping and I'd still advocate simply using > > VERSION_FEATURE.0.0. > > > > It's tricky. > > > > David > > ----- > > > >>> For the record I considered whether this needs a CSR request and > >>> concluded it did not as it doesn't involve changing any actual > >>> specifications. > >> > >> Okay, thanks. > >> I considered it too, made the same conclusion but still have some > >> doubt. :) > >> > >> Thanks! > >> Serguei > >> > >>> > >>> Thanks, > >>> David > >>> > >>>> Testing: > >>>> Generated docs and jvmti.h and checked the versions are correct. > >>>> > >>>> One could ask if we have to use same or similar approach for > >>>> other API's and tools, like JNI, JMX and so on. > >>>> But these are not areas of my expertise or responsibility. > >>>> It just feels like there is some room for unification here. > >>>> > >>>> Thanks, > >>>> Serguei > >> > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu May 9 16:17:33 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 9 May 2019 09:17:33 -0700 Subject: debugd options should regard to jhsdb style In-Reply-To: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> Message-ID: Hi Osamu, The patch looks good to me (I'm not an official reviewer though and I wonder if we should factorize that code a bit, it seems we do the longOpts with variations of options all over the place and we could just have a generic one and all call it. But that is a different webrev I think). Thanks, Jc On Thu, May 9, 2019 at 1:34 AM ?? ? wrote: > Hi all, > > I want to use `jhsdb debugd` on my laptop. > However debugd mode has different options from other modes. > I think debugd should have same options like other modes. > > For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. > Also I added `--serverid` option for serverid. > > I attached a patch for this enhancement. > This patch passes serviceability/sa jtreg tests. > > Testcase for debugd is available as > serviceability/sa/sadebugd/SADebugDTest.java . > However it has been disabled by JDK-8163805. > It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been > merged. > > Could you help? I want to contribute it. I need a sponsor. > (My company has signed to OCA (NTT Comware Corporation)) > > Thanks, > > Osamu > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 9 21:08:01 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 May 2019 14:08:01 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> Message-ID: <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu May 9 21:17:07 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 9 May 2019 14:17:07 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> Message-ID: Hi Serguei, Of course I can :) Consider, just randomly of course, the heap sampling work that got added to JVMTI. Now imagine you'd want to test if it is supported by a given JVMTI version, you would write something like this: bool HeapMonitor::Supported(jvmtiEnv *jvmti) { jvmtiCapabilities caps; memset(&caps, 0, sizeof(caps)); if (jvmti->GetPotentialCapabilities(&caps) != JVMTI_ERROR_NONE) { LOG(WARNING) << "Failed to get potential capabilities, disabling the heap " << "sampling monitor"; return false; } return caps.can_generate_sampled_object_alloc_events && caps.can_generate_garbage_collection_events; } Now, the problem is that this code cannot be used if you compile with an older JDK such as JDK8 for example because can_generate_sampled_object_alloc_events does not exist yet for that jvmti.h file. In a perfect world, we might imagine that we are always compiling with the latest JVMTI headers but that is not always true and, therefore, to have the code portable, we now have to do: bool HeapMonitor::Supported(jvmtiEnv *jvmti) { #ifdef ENABLE_HEAP_SAMPLING jvmtiCapabilities caps; memset(&caps, 0, sizeof(caps)); if (jvmti->GetPotentialCapabilities(&caps) != JVMTI_ERROR_NONE) { LOG(WARNING) << "Failed to get potential capabilities, disabling the heap " << "sampling monitor"; return false; } return caps.can_generate_sampled_object_alloc_events && caps.can_generate_garbage_collection_events; #else return false; #endif } Where ENABLE_HEAP_SAMPLING is defined if we did compile with JDK11 and not defined if we compiled with JDK8. I can't use JVMTI_VERSION because I can't use it in an #if because it is not an enum. Were it to be a #define or were I to have a #define I could use with a version number being bumped up, I could write something such as: #ifdef JVMTI_VERSION_11 or something that looks in the value of the JVMTI_VERSION if I wanted. Right now, I can't even do that! Hopefully this helps understand what I am talking about :-), Jc On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Hi Jc, > > Thank you a lot for review! > Some replies below. > > > On 5/9/19 09:10, Jean Christophe Beyler wrote: > > Hi Serguei, > > FWIW, the change looks good and I think it's a good idea to do. However, > there is one thorn in our internal agent code is that the JVMTI_VERSION is > in an enum. This makes us unable to #if it when adding usages of newer > features/methods. > > This probably could/should be a different webrev (which I can do if you > like) but is there any way while you are changing this that the enum for > JVMTI_VERSION could become a set of #define? > > So instead of: > enum { > JVMTI_VERSION_1 = 0x30010000, > JVMTI_VERSION_1_0 = 0x30010000, > JVMTI_VERSION_1_1 = 0x30010100, > JVMTI_VERSION_1_2 = 0x30010200, > JVMTI_VERSION_9 = 0x30090000, > JVMTI_VERSION_11 = 0x300B0000, > > JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 /* > version: 11.0.0 */ > }; > > We would get: > #define JVMTI_VERSION_1 0x30010000 > #define JVMTI_VERSION_1_0 0x30010000 > #define JVMTI_VERSION_1_1 = 0x30010100 > #define JVMTI_VERSION_1_2 = 0x30010200 > #define JVMTI_VERSION_9 = 0x30090000 > #define JVMTI_VERSION_11 = 0x300B0000 > #define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 /* > version: 11.0.0 */) > > > It is interesting concern and suggestion. > I'm not sure if it requires a CSR. > > > I actually don't care about any define of these except for JVMTI_VERSION; > basically it would be useful so that in our agent code we can test the > JVMTI_VERSION with #if macros to protect the code when new elements show up > in future versions. So it also could be: > enum { > JVMTI_VERSION_1 = 0x30010000, > JVMTI_VERSION_1_0 = 0x30010000, > JVMTI_VERSION_1_1 = 0x30010100, > JVMTI_VERSION_1_2 = 0x30010200, > JVMTI_VERSION_9 = 0x30090000, > JVMTI_VERSION_11 = 0x300B0000, > > JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 /* > version: 11.0.0 */ > }; > > #define JVMTI_LATEST_VERSION (0x30000000 + (11 * 0x10000) + (0 * 0x100) + > 0 /* version: 11.0.0 */) > > > I is not a problem to implement this one. > But I'm not sure how does this really help in your case. > I do not see a point to test the JVMTI_VERSION with #if as it is always > defined. > Could you, please, elaborate a little bit more? > > Thanks, > Serguei > > Right now, I have to do weird things where I detect the jvmti.h used at > compile time to then do -DUSING_JDK11 for the agent at compile time. > > Thanks! > Jc > > > > > On Thu, May 9, 2019 at 8:48 AM serguei.spitsyn at oracle.com < > serguei.spitsyn at oracle.com> wrote: > >> I'll try to get rid of VERSION_INTERIM. >> Always using just VERSION_FEATURE.0.0 should not create problems >> if we do not change JVMTI spec in VERSION_UPDATE. >> I do not see why we would change the JVMTI spec in update releases. >> But if we do then using VERSION_UPDATE as microversion would be good >> enough. >> >> Thanks! >> Serguei >> >> >> On 5/9/19 06:13, David Holmes wrote: >> > Hi Serguei, >> > >> > On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com wrote: >> >> Hi David, >> >> >> >> Thank you a lot for review! >> >> There are some replies below. >> >> >> >> >> >> On 5/8/19 18:42, David Holmes wrote: >> >>> Hi Serguei, >> >>> >> >>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com wrote: >> >>>> Please, review a fix for the task: >> >>>> https://bugs.openjdk.java.net/browse/JDK-8219023 >> >>>> >> >>>> Webrev: >> >>>> >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >> >>>> >> >>>> >> >>>> Summary: >> >>>> >> >>>> By design as we have never bumped the JVMTI version unless >> >>>> there were spec changes for that release. Now we want to sync >> >>>> the JVMTI version with the JDK version regardless of whether >> >>>> or not spec changes have occurred in that release. >> >>>> Also, we want it automatically set by the build system so that >> >>>> no manual updates are needed for each release. >> >>>> >> >>>> The jvmti.h and jvmti.html (JVMTI spec) are generated from >> >>>> the jvmti.xsl with the XSLT scripts now. So, the fix removes >> >>>> hard coded major, minor and micro versions from the jvmti.xml >> >>>> and passes major and minor parameters with the -PARAMETER >> >>>> to the XSL transformation. >> >>>> >> >>>> Another part of the fix is in the JDI which starts using JDK >> >>>> versions now instead of maintaining its own, and in the JDWP >> >>>> agent which is using the JVMTI versions instead of its own. >> >>> >> >>> This all seems reasonable (though I'm no expert on working with XSL >> >>> etc). >> >>> >> >>> One thing I am unclear of is why you bother with using >> >>> VERSION_INTERIM when the actual version check will only consider >> >>> VERSION_FEATURE (aka major). Couldn't you just leave the "minor" >> >>> part 0 the same as the "micro" part? >> >> >> >> This is right question to ask. >> >> I was two-folded on this. >> >> But finally decided to maintain minor version (aka VERSION_INTERIM). >> >> Then the JVMTI and debugger version will match the VM and JDK version >> >> for update releases. >> >> If understand it correctly, we are still going to have major.minor >> >> versions. >> > >> > Not really. What we have now are things like 11.0.3 and 12.0.1 - only >> > using the first and third parts. The full 4 part version string is: >> > >> > $VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH >> > >> > and we typically only update version_feature and version_update. >> > >> > https://openjdk.java.net/jeps/322 >> > >> >> Also, the JVMTI GetVersionNumberspec still tells about both minor and >> >> micro versions. >> >> It also defines special constants for corresponding masks and shifts: >> >> >> >> Version Masks >> >> Constant Value Description >> >> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 Mask to >> >> extract >> >> interface type. The value of the version returned by this function >> >> masked with |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always >> >> |JVMTI_VERSION_INTERFACE_JVMTI| since this is a JVMTI function. >> >> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000 Mask to extract major >> >> version number. >> >> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00 Mask to extract minor >> >> version number. >> >> |JVMTI_VERSION_MASK_MICRO| 0x000000FF Mask to extract micro >> >> version number. >> >> >> >> Version Shifts >> >> Constant Value Description >> >> |JVMTI_VERSION_SHIFT_MAJOR| 16 Shift to extract major >> >> version number. >> >> |JVMTI_VERSION_SHIFT_MINOR| 8 Shift to extract minor >> >> version number. >> >> |JVMTI_VERSION_SHIFT_MICRO| 0 Shift to extract micro >> >> version number. >> >> >> >> >> >> This is link to the spec: >> >> >> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber >> >> >> >> >> >> It seems, changing (and/or deprecating) this will give more problems >> >> than benefits. >> >> It is better to remain compatible with previous releases. >> > >> > This is a problem that was flagged when the new versioning scheme was >> > introduced but I'm guessing nothing was actually done about it. They >> > are not really compatible beyond the major/feature part. >> > >> > If we only update the spec version with the feature version then all >> > versions will have the form N.0.0. However your changes will also >> > update if we happen to use a VERSION_INTERIM for some reason - though >> > the version check will ignore that anyway. I'm not really seeing the >> > point in having that happen. >> > >> > Maybe we do need to define a new version API that maps to the new >> > versioning scheme of OpenJDK ? But if we did that we'd still have to >> > support the legacy mapping and I'd still advocate simply using >> > VERSION_FEATURE.0.0. >> > >> > It's tricky. >> > >> > David >> > ----- >> > >> >>> For the record I considered whether this needs a CSR request and >> >>> concluded it did not as it doesn't involve changing any actual >> >>> specifications. >> >> >> >> Okay, thanks. >> >> I considered it too, made the same conclusion but still have some >> >> doubt. :) >> >> >> >> Thanks! >> >> Serguei >> >> >> >>> >> >>> Thanks, >> >>> David >> >>> >> >>>> Testing: >> >>>> Generated docs and jvmti.h and checked the versions are correct. >> >>>> >> >>>> One could ask if we have to use same or similar approach for >> >>>> other API's and tools, like JNI, JMX and so on. >> >>>> But these are not areas of my expertise or responsibility. >> >>>> It just feels like there is some room for unification here. >> >>>> >> >>>> Thanks, >> >>>> Serguei >> >> >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 9 22:30:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 08:30:44 +1000 Subject: debugd options should regard to jhsdb style In-Reply-To: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> Message-ID: <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> Hi, This will need a bug filed and a corresponding CSR request. I suspect that historically the form of this command was done to match other tools. Thanks, David On 9/05/2019 6:33 pm, ?? ? wrote: > Hi all, > > I want to use `jhsdb debugd` on my laptop. > However debugd mode has different options from other modes. > I think debugd should have same options like other modes. > > For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. > Also I added `--serverid` option for serverid. > > I attached a patch for this enhancement. > This patch passes serviceability/sa jtreg tests. > > Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . > However it has been disabled by JDK-8163805. > It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. > > Could you help? I want to contribute it. I need a sponsor. > (My company has signed to OCA (NTT Comware Corporation)) > > Thanks, > > Osamu > From serguei.spitsyn at oracle.com Thu May 9 23:45:39 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 May 2019 16:45:39 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri May 10 00:11:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 10:11:08 +1000 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> Message-ID: <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com wrote: > Hi Jc, > > Okay, you convinced me - thanks! > Added new line into the generated jvmti.h: > > ? #define JVMTI_VERSION_LATEST JVMTI_VERSION That requires a CSR as you are expanding the exported interface. Also you need #define JVMTI_VERSION_LATEST (JVMTI_VERSION) as JVMTI_VERSION is itself an expression not a constant. That might limit the utility of having such a define as you won't be able to use it in an ifdef guard to test a value AFAICS. David > I hope, it will help in your case. > > > Updated webrev version is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ > > > This version includes suggestions from David. > > Thanks, > Serguei > > > > On 5/9/19 14:17, Jean Christophe Beyler wrote: >> Hi Serguei, >> >> Of course I can :) >> >> Consider, just randomly of course, the heap sampling work that got >> added to JVMTI. Now imagine you'd want to test if it is supported by a >> given JVMTI version, you would write something like this: >> >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >> ? jvmtiCapabilities caps; >> ? memset(&caps, 0, sizeof(caps)); >> ? if (jvmti->GetPotentialCapabilities(&caps) != JVMTI_ERROR_NONE) { >> ? ? LOG(WARNING) << "Failed to get potential capabilities, disabling >> the heap " >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >> ? ? return false; >> ? } >> >> ? return caps.can_generate_sampled_object_alloc_events >> ? ? ? && caps.can_generate_garbage_collection_events; >> } >> >> Now, the problem is that this code cannot be used if you compile with >> an older JDK such as JDK8 for example >> because?can_generate_sampled_object_alloc_events does not exist yet >> for that jvmti.h file. >> >> >> In a perfect world, we might imagine that we are always compiling with >> the latest JVMTI headers but that is not always true and, therefore, >> to have the code portable, we now have to do: >> >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >> #ifdef ENABLE_HEAP_SAMPLING >> ? jvmtiCapabilities caps; >> ? memset(&caps, 0, sizeof(caps)); >> ? if (jvmti->GetPotentialCapabilities(&caps) != JVMTI_ERROR_NONE) { >> ? ? LOG(WARNING) << "Failed to get potential capabilities, disabling >> the heap " >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >> ? ? return false; >> ? } >> >> ? return caps.can_generate_sampled_object_alloc_events >> ? ? ? && caps.can_generate_garbage_collection_events; >> #else >> ? return false; >> #endif >> } >> >> Where ENABLE_HEAP_SAMPLING is defined if we did compile with JDK11 and >> not defined if we compiled with JDK8. I can't use JVMTI_VERSION >> because I can't use it in an #if because it is not an enum. Were it to >> be a #define or were I to have a #define I could use with a version >> number being bumped up, I could write something such as: >> >> #ifdef JVMTI_VERSION_11 >> >> or something that looks in the value of the JVMTI_VERSION if I wanted. >> Right now, I can't even do that! >> >> Hopefully this helps understand what I am talking about :-), >> Jc >> >> >> >> >> On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com >> > > wrote: >> >> Hi Jc, >> >> Thank you a lot for review! >> Some replies below. >> >> >> On 5/9/19 09:10, Jean Christophe Beyler wrote: >>> Hi Serguei, >>> >>> FWIW, the change looks good and I think it's a good idea to do. >>> However, there is one thorn in our internal agent code is that >>> the JVMTI_VERSION is in an enum. This makes us unable to #if it >>> when adding usages of newer features/methods. >>> >>> This probably could/should be a different webrev (which I can do >>> if you like) but is there any way while you are changing this >>> that the enum for JVMTI_VERSION could become a set of #define? >>> >>> So instead of: >>> enum { >>> ? ? JVMTI_VERSION_1? ?= 0x30010000, >>> ? ? JVMTI_VERSION_1_0 = 0x30010000, >>> ? ? JVMTI_VERSION_1_1 = 0x30010100, >>> ? ? JVMTI_VERSION_1_2 = 0x30010200, >>> ? ? JVMTI_VERSION_9? ?= 0x30090000, >>> ? ? JVMTI_VERSION_11? = 0x300B0000, >>> >>> ? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + >>> 0? /* version: 11.0.0 */ >>> }; >>> >>> We would get: >>> #define JVMTI_VERSION_1 0x30010000 >>> #define JVMTI_VERSION_1_0 0x30010000 >>> #define JVMTI_VERSION_1_1 = 0x30010100 >>> #define JVMTI_VERSION_1_2 = 0x30010200 >>> #define JVMTI_VERSION_9? ?= 0x30090000 >>> #define JVMTI_VERSION_11? = 0x300B0000 >>> #define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + (0 * 0x100) >>> + 0? /* version: 11.0.0 */) >> >> It is interesting concern and suggestion. >> I'm not sure if it requires a CSR. >> >> >>> I actually don't care about any define of these except for >>> JVMTI_VERSION; basically it would be useful so that in our agent >>> code we can test the JVMTI_VERSION with #if macros to protect the >>> code when new elements show up in future versions. So it also >>> could be: >>> enum { >>> ? ? JVMTI_VERSION_1? ?= 0x30010000, >>> ? ? JVMTI_VERSION_1_0 = 0x30010000, >>> ? ? JVMTI_VERSION_1_1 = 0x30010100, >>> ? ? JVMTI_VERSION_1_2 = 0x30010200, >>> ? ? JVMTI_VERSION_9? ?= 0x30090000, >>> ? ? JVMTI_VERSION_11? = 0x300B0000, >>> >>> ? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + >>> 0? /* version: 11.0.0 */ >>> }; >>> >>> #define JVMTI_LATEST_VERSION (0x30000000 + (11 * 0x10000) + (0 * >>> 0x100) + 0? /* version: 11.0.0 */) >> >> I is not a problem to implement this one. >> But I'm not sure how does this really help in your case. >> I do not see a point to test the JVMTI_VERSION with #if as it is >> always defined. >> Could you, please, elaborate a little bit more? >> >> Thanks, >> Serguei >> >>> Right now, I have to do weird things where I detect the jvmti.h >>> used at compile time to then do -DUSING_JDK11 for the agent at >>> compile time. >>> >>> Thanks! >>> Jc >>> >>> >>> >>> >>> On Thu, May 9, 2019 at 8:48 AM serguei.spitsyn at oracle.com >>> >> > wrote: >>> >>> I'll try to get rid of VERSION_INTERIM. >>> Always using just VERSION_FEATURE.0.0 should not create problems >>> if we do not change JVMTI spec in VERSION_UPDATE. >>> I do not see why we would change the JVMTI spec in update >>> releases. >>> But if we do then using VERSION_UPDATE as microversion would >>> be good enough. >>> >>> Thanks! >>> Serguei >>> >>> >>> On 5/9/19 06:13, David Holmes wrote: >>> > Hi Serguei, >>> > >>> > On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com >>> wrote: >>> >> Hi David, >>> >> >>> >> Thank you a lot for review! >>> >> There are some replies below. >>> >> >>> >> >>> >> On 5/8/19 18:42, David Holmes wrote: >>> >>> Hi Serguei, >>> >>> >>> >>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com >>> wrote: >>> >>>> Please, review a fix for the task: >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8219023 >>> >>>> >>> >>>> Webrev: >>> >>>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >>> >>> >>>> >>> >>>> >>> >>>> Summary: >>> >>>> >>> >>>> ??By design as we have never bumped the JVMTI version unless >>> >>>> ??there were spec changes for that release. Now we want >>> to sync >>> >>>> ??the JVMTI version with the JDK version regardless of >>> whether >>> >>>> ??or not spec changes have occurred in that release. >>> >>>> ??Also, we want it automatically set by the build system >>> so that >>> >>>> ??no manual updates are needed for each release. >>> >>>> >>> >>>> ??The jvmti.h and jvmti.html (JVMTI spec) are generated from >>> >>>> ??the jvmti.xsl with the XSLT scripts now. So, the fix >>> removes >>> >>>> ??hard coded major, minor and micro versions from the >>> jvmti.xml >>> >>>> ??and passes major and minor parameters with the -PARAMETER >>> >>>> ??to the XSL transformation. >>> >>>> >>> >>>> ??Another part of the fix is in the JDI which starts >>> using JDK >>> >>>> ??versions now instead of maintaining its own, and in >>> the JDWP >>> >>>> ??agent which is using the JVMTI versions instead of its >>> own. >>> >>> >>> >>> This all seems reasonable (though I'm no expert on >>> working with XSL >>> >>> etc). >>> >>> >>> >>> One thing I am unclear of is why you bother with using >>> >>> VERSION_INTERIM when the actual version check will only >>> consider >>> >>> VERSION_FEATURE (aka major). Couldn't you just leave the >>> "minor" >>> >>> part 0 the same as the "micro" part? >>> >> >>> >> This is right question to ask. >>> >> I was two-folded on this. >>> >> But finally decided to maintain minor version (aka >>> VERSION_INTERIM). >>> >> Then the JVMTI and debugger version will match the VM and >>> JDK version >>> >> for update releases. >>> >> If understand it correctly, we are still going to have >>> major.minor >>> >> versions. >>> > >>> > Not really. What we have now are things like 11.0.3 and >>> 12.0.1 - only >>> > using the first and third parts. The full 4 part version >>> string is: >>> > >>> > >>> $VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH >>> > >>> > and we typically only update version_feature and >>> version_update. >>> > >>> > https://openjdk.java.net/jeps/322 >>> > >>> >> Also, the JVMTI GetVersionNumberspec still tells about >>> both minor and >>> >> micro versions. >>> >> It also defines special constants for corresponding masks >>> and shifts: >>> >> >>> >> ??? Version Masks >>> >> ??? Constant???? Value???? Description >>> >> ??? |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 >>> Mask to >>> >> extract >>> >> ??? interface type. The value of the version returned by >>> this function >>> >> ??? masked with |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always >>> >> ??? |JVMTI_VERSION_INTERFACE_JVMTI| since this is a JVMTI >>> function. >>> >> ??? |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000???? Mask to >>> extract major >>> >> ??? version number. >>> >> ??? |JVMTI_VERSION_MASK_MINOR| 0x0000FF00???? Mask to >>> extract minor >>> >> ??? version number. >>> >> ??? |JVMTI_VERSION_MASK_MICRO| 0x000000FF???? Mask to >>> extract micro >>> >> ??? version number. >>> >> >>> >> ??? Version Shifts >>> >> ??? Constant???? Value???? Description >>> >> ??? |JVMTI_VERSION_SHIFT_MAJOR|???? 16 Shift to extract major >>> >> version number. >>> >> ??? |JVMTI_VERSION_SHIFT_MINOR|???? 8 Shift to extract minor >>> >> version number. >>> >> ??? |JVMTI_VERSION_SHIFT_MICRO|???? 0 Shift to extract micro >>> >> version number. >>> >> >>> >> >>> >> This is link to the spec: >>> >> >>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber >>> >>> >> >>> >> >>> >> It seems, changing (and/or deprecating) this will give >>> more problems >>> >> than benefits. >>> >> It is better to remain compatible with previous releases. >>> > >>> > This is a problem that was flagged when the new versioning >>> scheme was >>> > introduced but I'm guessing nothing was actually done about >>> it. They >>> > are not really compatible beyond the major/feature part. >>> > >>> > If we only update the spec version with the feature version >>> then all >>> > versions will have the form N.0.0. However your changes >>> will also >>> > update if we happen to use a VERSION_INTERIM for some >>> reason - though >>> > the version check will ignore that anyway. I'm not really >>> seeing the >>> > point in having that happen. >>> > >>> > Maybe we do need to define a new version API that maps to >>> the new >>> > versioning scheme of OpenJDK ? But if we did that we'd >>> still have to >>> > support the legacy mapping and I'd still advocate simply using >>> > VERSION_FEATURE.0.0. >>> > >>> > It's tricky. >>> > >>> > David >>> > ----- >>> > >>> >>> For the record I considered whether this needs a CSR >>> request and >>> >>> concluded it did not as it doesn't involve changing any >>> actual >>> >>> specifications. >>> >> >>> >> Okay, thanks. >>> >> I considered it too, made the same conclusion but still >>> have some >>> >> doubt. :) >>> >> >>> >> Thanks! >>> >> Serguei >>> >> >>> >>> >>> >>> Thanks, >>> >>> David >>> >>> >>> >>>> Testing: >>> >>>> ??Generated docs and jvmti.h and checked the versions >>> are correct. >>> >>>> >>> >>>> One could ask if we have to use same or similar approach for >>> >>>> other API's and tools, like JNI, JMX and so on. >>> >>>> But these are not areas of my expertise or responsibility. >>> >>>> It just feels like there is some room for unification here. >>> >>>> >>> >>>> Thanks, >>> >>>> Serguei >>> >> >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> >> >> >> -- >> >> Thanks, >> Jc > From jcbeyler at google.com Fri May 10 00:17:19 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 9 May 2019 17:17:19 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> Message-ID: Hi Serguei, Adding to the difficulties that David is exposing, this won't work. You need to redo the xls definition because you need the #define to be the numeric value directly and not the enum; otherwise it won't work in any usable way at preprocessor time sadly. I think it makes sense to just do what you were planning to do here without this and I'll file a bug and work out the CSR path and review path separately and see what is do-able or not then because I think it's too much work now "just for this now" if that makes sense :) Jc *From: *David Holmes *Date: *Thu, May 9, 2019 at 5:11 PM *To: *serguei.spitsyn at oracle.com, Jean Christophe Beyler *Cc: *serviceability-dev On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com wrote: > > Hi Jc, > > > > Okay, you convinced me - thanks! > > Added new line into the generated jvmti.h: > > > > #define JVMTI_VERSION_LATEST JVMTI_VERSION > > That requires a CSR as you are expanding the exported interface. > > Also you need > > #define JVMTI_VERSION_LATEST (JVMTI_VERSION) > > as JVMTI_VERSION is itself an expression not a constant. That might > limit the utility of having such a define as you won't be able to use it > in an ifdef guard to test a value AFAICS. > > David > > > I hope, it will help in your case. > > > > > > Updated webrev version is: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ > > > > > > This version includes suggestions from David. > > > > Thanks, > > Serguei > > > > > > > > On 5/9/19 14:17, Jean Christophe Beyler wrote: > >> Hi Serguei, > >> > >> Of course I can :) > >> > >> Consider, just randomly of course, the heap sampling work that got > >> added to JVMTI. Now imagine you'd want to test if it is supported by a > >> given JVMTI version, you would write something like this: > >> > >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { > >> jvmtiCapabilities caps; > >> memset(&caps, 0, sizeof(caps)); > >> if (jvmti->GetPotentialCapabilities(&caps) != JVMTI_ERROR_NONE) { > >> LOG(WARNING) << "Failed to get potential capabilities, disabling > >> the heap " > >> << "sampling monitor"; > >> return false; > >> } > >> > >> return caps.can_generate_sampled_object_alloc_events > >> && caps.can_generate_garbage_collection_events; > >> } > >> > >> Now, the problem is that this code cannot be used if you compile with > >> an older JDK such as JDK8 for example > >> because can_generate_sampled_object_alloc_events does not exist yet > >> for that jvmti.h file. > >> > >> > >> In a perfect world, we might imagine that we are always compiling with > >> the latest JVMTI headers but that is not always true and, therefore, > >> to have the code portable, we now have to do: > >> > >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { > >> #ifdef ENABLE_HEAP_SAMPLING > >> jvmtiCapabilities caps; > >> memset(&caps, 0, sizeof(caps)); > >> if (jvmti->GetPotentialCapabilities(&caps) != JVMTI_ERROR_NONE) { > >> LOG(WARNING) << "Failed to get potential capabilities, disabling > >> the heap " > >> << "sampling monitor"; > >> return false; > >> } > >> > >> return caps.can_generate_sampled_object_alloc_events > >> && caps.can_generate_garbage_collection_events; > >> #else > >> return false; > >> #endif > >> } > >> > >> Where ENABLE_HEAP_SAMPLING is defined if we did compile with JDK11 and > >> not defined if we compiled with JDK8. I can't use JVMTI_VERSION > >> because I can't use it in an #if because it is not an enum. Were it to > >> be a #define or were I to have a #define I could use with a version > >> number being bumped up, I could write something such as: > >> > >> #ifdef JVMTI_VERSION_11 > >> > >> or something that looks in the value of the JVMTI_VERSION if I wanted. > >> Right now, I can't even do that! > >> > >> Hopefully this helps understand what I am talking about :-), > >> Jc > >> > >> > >> > >> > >> On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com > >> >> > wrote: > >> > >> Hi Jc, > >> > >> Thank you a lot for review! > >> Some replies below. > >> > >> > >> On 5/9/19 09:10, Jean Christophe Beyler wrote: > >>> Hi Serguei, > >>> > >>> FWIW, the change looks good and I think it's a good idea to do. > >>> However, there is one thorn in our internal agent code is that > >>> the JVMTI_VERSION is in an enum. This makes us unable to #if it > >>> when adding usages of newer features/methods. > >>> > >>> This probably could/should be a different webrev (which I can do > >>> if you like) but is there any way while you are changing this > >>> that the enum for JVMTI_VERSION could become a set of #define? > >>> > >>> So instead of: > >>> enum { > >>> JVMTI_VERSION_1 = 0x30010000, > >>> JVMTI_VERSION_1_0 = 0x30010000, > >>> JVMTI_VERSION_1_1 = 0x30010100, > >>> JVMTI_VERSION_1_2 = 0x30010200, > >>> JVMTI_VERSION_9 = 0x30090000, > >>> JVMTI_VERSION_11 = 0x300B0000, > >>> > >>> JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + > >>> 0 /* version: 11.0.0 */ > >>> }; > >>> > >>> We would get: > >>> #define JVMTI_VERSION_1 0x30010000 > >>> #define JVMTI_VERSION_1_0 0x30010000 > >>> #define JVMTI_VERSION_1_1 = 0x30010100 > >>> #define JVMTI_VERSION_1_2 = 0x30010200 > >>> #define JVMTI_VERSION_9 = 0x30090000 > >>> #define JVMTI_VERSION_11 = 0x300B0000 > >>> #define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + (0 * 0x100) > >>> + 0 /* version: 11.0.0 */) > >> > >> It is interesting concern and suggestion. > >> I'm not sure if it requires a CSR. > >> > >> > >>> I actually don't care about any define of these except for > >>> JVMTI_VERSION; basically it would be useful so that in our agent > >>> code we can test the JVMTI_VERSION with #if macros to protect the > >>> code when new elements show up in future versions. So it also > >>> could be: > >>> enum { > >>> JVMTI_VERSION_1 = 0x30010000, > >>> JVMTI_VERSION_1_0 = 0x30010000, > >>> JVMTI_VERSION_1_1 = 0x30010100, > >>> JVMTI_VERSION_1_2 = 0x30010200, > >>> JVMTI_VERSION_9 = 0x30090000, > >>> JVMTI_VERSION_11 = 0x300B0000, > >>> > >>> JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + > >>> 0 /* version: 11.0.0 */ > >>> }; > >>> > >>> #define JVMTI_LATEST_VERSION (0x30000000 + (11 * 0x10000) + (0 * > >>> 0x100) + 0 /* version: 11.0.0 */) > >> > >> I is not a problem to implement this one. > >> But I'm not sure how does this really help in your case. > >> I do not see a point to test the JVMTI_VERSION with #if as it is > >> always defined. > >> Could you, please, elaborate a little bit more? > >> > >> Thanks, > >> Serguei > >> > >>> Right now, I have to do weird things where I detect the jvmti.h > >>> used at compile time to then do -DUSING_JDK11 for the agent at > >>> compile time. > >>> > >>> Thanks! > >>> Jc > >>> > >>> > >>> > >>> > >>> On Thu, May 9, 2019 at 8:48 AM serguei.spitsyn at oracle.com > >>> >>> > wrote: > >>> > >>> I'll try to get rid of VERSION_INTERIM. > >>> Always using just VERSION_FEATURE.0.0 should not create > problems > >>> if we do not change JVMTI spec in VERSION_UPDATE. > >>> I do not see why we would change the JVMTI spec in update > >>> releases. > >>> But if we do then using VERSION_UPDATE as microversion would > >>> be good enough. > >>> > >>> Thanks! > >>> Serguei > >>> > >>> > >>> On 5/9/19 06:13, David Holmes wrote: > >>> > Hi Serguei, > >>> > > >>> > On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com > >>> wrote: > >>> >> Hi David, > >>> >> > >>> >> Thank you a lot for review! > >>> >> There are some replies below. > >>> >> > >>> >> > >>> >> On 5/8/19 18:42, David Holmes wrote: > >>> >>> Hi Serguei, > >>> >>> > >>> >>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com > >>> wrote: > >>> >>>> Please, review a fix for the task: > >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8219023 > >>> >>>> > >>> >>>> Webrev: > >>> >>>> > >>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ > >>> > >>> >>>> > >>> >>>> > >>> >>>> Summary: > >>> >>>> > >>> >>>> By design as we have never bumped the JVMTI version > unless > >>> >>>> there were spec changes for that release. Now we want > >>> to sync > >>> >>>> the JVMTI version with the JDK version regardless of > >>> whether > >>> >>>> or not spec changes have occurred in that release. > >>> >>>> Also, we want it automatically set by the build system > >>> so that > >>> >>>> no manual updates are needed for each release. > >>> >>>> > >>> >>>> The jvmti.h and jvmti.html (JVMTI spec) are generated > from > >>> >>>> the jvmti.xsl with the XSLT scripts now. So, the fix > >>> removes > >>> >>>> hard coded major, minor and micro versions from the > >>> jvmti.xml > >>> >>>> and passes major and minor parameters with the > -PARAMETER > >>> >>>> to the XSL transformation. > >>> >>>> > >>> >>>> Another part of the fix is in the JDI which starts > >>> using JDK > >>> >>>> versions now instead of maintaining its own, and in > >>> the JDWP > >>> >>>> agent which is using the JVMTI versions instead of its > >>> own. > >>> >>> > >>> >>> This all seems reasonable (though I'm no expert on > >>> working with XSL > >>> >>> etc). > >>> >>> > >>> >>> One thing I am unclear of is why you bother with using > >>> >>> VERSION_INTERIM when the actual version check will only > >>> consider > >>> >>> VERSION_FEATURE (aka major). Couldn't you just leave the > >>> "minor" > >>> >>> part 0 the same as the "micro" part? > >>> >> > >>> >> This is right question to ask. > >>> >> I was two-folded on this. > >>> >> But finally decided to maintain minor version (aka > >>> VERSION_INTERIM). > >>> >> Then the JVMTI and debugger version will match the VM and > >>> JDK version > >>> >> for update releases. > >>> >> If understand it correctly, we are still going to have > >>> major.minor > >>> >> versions. > >>> > > >>> > Not really. What we have now are things like 11.0.3 and > >>> 12.0.1 - only > >>> > using the first and third parts. The full 4 part version > >>> string is: > >>> > > >>> > > >>> > $VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH > >>> > > >>> > and we typically only update version_feature and > >>> version_update. > >>> > > >>> > https://openjdk.java.net/jeps/322 > >>> > > >>> >> Also, the JVMTI GetVersionNumberspec still tells about > >>> both minor and > >>> >> micro versions. > >>> >> It also defines special constants for corresponding masks > >>> and shifts: > >>> >> > >>> >> Version Masks > >>> >> Constant Value Description > >>> >> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 > >>> Mask to > >>> >> extract > >>> >> interface type. The value of the version returned by > >>> this function > >>> >> masked with |JVMTI_VERSION_MASK_INTERFACE_TYPE| is > always > >>> >> |JVMTI_VERSION_INTERFACE_JVMTI| since this is a JVMTI > >>> function. > >>> >> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000 Mask to > >>> extract major > >>> >> version number. > >>> >> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00 Mask to > >>> extract minor > >>> >> version number. > >>> >> |JVMTI_VERSION_MASK_MICRO| 0x000000FF Mask to > >>> extract micro > >>> >> version number. > >>> >> > >>> >> Version Shifts > >>> >> Constant Value Description > >>> >> |JVMTI_VERSION_SHIFT_MAJOR| 16 Shift to extract > major > >>> >> version number. > >>> >> |JVMTI_VERSION_SHIFT_MINOR| 8 Shift to extract minor > >>> >> version number. > >>> >> |JVMTI_VERSION_SHIFT_MICRO| 0 Shift to extract micro > >>> >> version number. > >>> >> > >>> >> > >>> >> This is link to the spec: > >>> >> > >>> > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber > >>> > >>> >> > >>> >> > >>> >> It seems, changing (and/or deprecating) this will give > >>> more problems > >>> >> than benefits. > >>> >> It is better to remain compatible with previous releases. > >>> > > >>> > This is a problem that was flagged when the new versioning > >>> scheme was > >>> > introduced but I'm guessing nothing was actually done about > >>> it. They > >>> > are not really compatible beyond the major/feature part. > >>> > > >>> > If we only update the spec version with the feature version > >>> then all > >>> > versions will have the form N.0.0. However your changes > >>> will also > >>> > update if we happen to use a VERSION_INTERIM for some > >>> reason - though > >>> > the version check will ignore that anyway. I'm not really > >>> seeing the > >>> > point in having that happen. > >>> > > >>> > Maybe we do need to define a new version API that maps to > >>> the new > >>> > versioning scheme of OpenJDK ? But if we did that we'd > >>> still have to > >>> > support the legacy mapping and I'd still advocate simply > using > >>> > VERSION_FEATURE.0.0. > >>> > > >>> > It's tricky. > >>> > > >>> > David > >>> > ----- > >>> > > >>> >>> For the record I considered whether this needs a CSR > >>> request and > >>> >>> concluded it did not as it doesn't involve changing any > >>> actual > >>> >>> specifications. > >>> >> > >>> >> Okay, thanks. > >>> >> I considered it too, made the same conclusion but still > >>> have some > >>> >> doubt. :) > >>> >> > >>> >> Thanks! > >>> >> Serguei > >>> >> > >>> >>> > >>> >>> Thanks, > >>> >>> David > >>> >>> > >>> >>>> Testing: > >>> >>>> Generated docs and jvmti.h and checked the versions > >>> are correct. > >>> >>>> > >>> >>>> One could ask if we have to use same or similar approach > for > >>> >>>> other API's and tools, like JNI, JMX and so on. > >>> >>>> But these are not areas of my expertise or responsibility. > >>> >>>> It just feels like there is some room for unification > here. > >>> >>>> > >>> >>>> Thanks, > >>> >>>> Serguei > >>> >> > >>> > >>> > >>> > >>> -- > >>> > >>> Thanks, > >>> Jc > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 10 00:28:48 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 May 2019 17:28:48 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> Message-ID: <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 10 00:32:15 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 9 May 2019 17:32:15 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> Message-ID: <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri May 10 01:20:35 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 May 2019 10:20:35 +0900 Subject: debugd options should regard to jhsdb style In-Reply-To: <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> Message-ID: <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> Hi, Osamu, your change looks good to me. I will sponsor you. David, I filed this issue and requested to CSR: JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 I uploaded webrev. I will push it to submit repo. http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ Thanks, Yasumasa On 2019/05/10 7:30, David Holmes wrote: > Hi, > > This will need a bug filed and a corresponding CSR request. I suspect > that historically the form of this command was done to match other tools. > > > Thanks, > David > > On 9/05/2019 6:33 pm, ?? ? wrote: >> Hi all, >> >> I want to use `jhsdb debugd` on my laptop. >> However debugd mode has different options from other modes. >> I think debugd should have same options like other modes. >> >> For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. >> Also I added `--serverid` option for serverid. >> >> I attached a patch for this enhancement. >> This patch passes serviceability/sa jtreg tests. >> >> Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . >> However it has been disabled by JDK-8163805. >> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. >> >> Could you help? I want to contribute it. I need a sponsor. >> (My company has signed to OCA (NTT Comware Corporation)) >> >> Thanks, >> >> Osamu >> From david.holmes at oracle.com Fri May 10 01:51:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 11:51:52 +1000 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> Message-ID: <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> Hi Serguei, On 10/05/2019 10:32 am, serguei.spitsyn at oracle.com wrote: > I've updated the webrev v2 in place. make/hotspot/gensrc/GensrcJvmti.gmk You don't need to pass through: -PARAM minorversion $(VERSION_INTERIM) src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java 57 private static final int minorVersion = Runtime.version().interim(); That should be kept at 0. I'd like to see an actual diff of the generated jvmti.h and jvmti.html files as well please. Some of the XSL stuff looks odd to me. Thanks, David > Thanks, > Serguei > > > On 5/9/19 17:28, serguei.spitsyn at oracle.com wrote: >> David and Jc, >> >> Okay, I'll remove this line now. >> Thank you for your comments. >> >> Let's let Jc to file a separate enhancement on this. >> Then I'll file a CSR and prepare a fix. >> >> I hope, you both are Okay with the rest. >> >> Thanks! >> Serguei >> >> >> On 5/9/19 17:17, Jean Christophe Beyler wrote: >>> Hi Serguei, >>> >>> Adding to the difficulties that David is exposing, this won't work. >>> You need to redo the xls definition because you need the #define to >>> be the numeric value directly and not the enum; otherwise it won't >>> work in any usable way at preprocessor time sadly. >>> >>> I think it makes sense to just do what you were planning to do here >>> without this and I'll file a bug and work out the CSR path and review >>> path separately and see what is do-able or not then because I think >>> it's too much work now "just for this now" if that makes sense :) >>> Jc >>> >>> *From: *David Holmes >> > >>> *Date: *Thu, May 9, 2019 at 5:11 PM >>> *To: *serguei.spitsyn at oracle.com , >>> Jean Christophe Beyler >>> *Cc: *serviceability-dev >>> >>> On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com >>> wrote: >>> > Hi Jc, >>> > >>> > Okay, you convinced me - thanks! >>> > Added new line into the generated jvmti.h: >>> > >>> >? ? #define JVMTI_VERSION_LATEST JVMTI_VERSION >>> >>> That requires a CSR as you are expanding the exported interface. >>> >>> Also you need >>> >>> #define JVMTI_VERSION_LATEST (JVMTI_VERSION) >>> >>> as JVMTI_VERSION is itself an expression not a constant. That might >>> limit the utility of having such a define as you won't be able to >>> use it >>> in an ifdef guard to test a value AFAICS. >>> >>> David >>> >>> > I hope, it will help in your case. >>> > >>> > >>> > Updated webrev version is: >>> > >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ >>> > >>> > >>> > This version includes suggestions from David. >>> > >>> > Thanks, >>> > Serguei >>> > >>> > >>> > >>> > On 5/9/19 14:17, Jean Christophe Beyler wrote: >>> >> Hi Serguei, >>> >> >>> >> Of course I can :) >>> >> >>> >> Consider, just randomly of course, the heap sampling work that >>> got >>> >> added to JVMTI. Now imagine you'd want to test if it is >>> supported by a >>> >> given JVMTI version, you would write something like this: >>> >> >>> >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >>> >> ? jvmtiCapabilities caps; >>> >> ? memset(&caps, 0, sizeof(caps)); >>> >> ? if (jvmti->GetPotentialCapabilities(&caps) != >>> JVMTI_ERROR_NONE) { >>> >> ? ? LOG(WARNING) << "Failed to get potential capabilities, >>> disabling >>> >> the heap " >>> >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >>> >> ? ? return false; >>> >> ? } >>> >> >>> >> ? return caps.can_generate_sampled_object_alloc_events >>> >> ? ? ? && caps.can_generate_garbage_collection_events; >>> >> } >>> >> >>> >> Now, the problem is that this code cannot be used if you >>> compile with >>> >> an older JDK such as JDK8 for example >>> >> because?can_generate_sampled_object_alloc_events does not >>> exist yet >>> >> for that jvmti.h file. >>> >> >>> >> >>> >> In a perfect world, we might imagine that we are always >>> compiling with >>> >> the latest JVMTI headers but that is not always true and, >>> therefore, >>> >> to have the code portable, we now have to do: >>> >> >>> >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >>> >> #ifdef ENABLE_HEAP_SAMPLING >>> >> ? jvmtiCapabilities caps; >>> >> ? memset(&caps, 0, sizeof(caps)); >>> >> ? if (jvmti->GetPotentialCapabilities(&caps) != >>> JVMTI_ERROR_NONE) { >>> >> ? ? LOG(WARNING) << "Failed to get potential capabilities, >>> disabling >>> >> the heap " >>> >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >>> >> ? ? return false; >>> >> ? } >>> >> >>> >> ? return caps.can_generate_sampled_object_alloc_events >>> >> ? ? ? && caps.can_generate_garbage_collection_events; >>> >> #else >>> >> ? return false; >>> >> #endif >>> >> } >>> >> >>> >> Where ENABLE_HEAP_SAMPLING is defined if we did compile with >>> JDK11 and >>> >> not defined if we compiled with JDK8. I can't use JVMTI_VERSION >>> >> because I can't use it in an #if because it is not an enum. >>> Were it to >>> >> be a #define or were I to have a #define I could use with a >>> version >>> >> number being bumped up, I could write something such as: >>> >> >>> >> #ifdef JVMTI_VERSION_11 >>> >> >>> >> or something that looks in the value of the JVMTI_VERSION if I >>> wanted. >>> >> Right now, I can't even do that! >>> >> >>> >> Hopefully this helps understand what I am talking about :-), >>> >> Jc >>> >> >>> >> >>> >> >>> >> >>> >> On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com >>> >>> >> >> > >> >>> >> >> >> wrote: >>> >> >>> >>? ? ?Hi Jc, >>> >> >>> >>? ? ?Thank you a lot for review! >>> >>? ? ?Some replies below. >>> >> >>> >> >>> >>? ? ?On 5/9/19 09:10, Jean Christophe Beyler wrote: >>> >>>? ? ?Hi Serguei, >>> >>> >>> >>>? ? ?FWIW, the change looks good and I think it's a good idea >>> to do. >>> >>>? ? ?However, there is one thorn in our internal agent code is >>> that >>> >>>? ? ?the JVMTI_VERSION is in an enum. This makes us unable to >>> #if it >>> >>>? ? ?when adding usages of newer features/methods. >>> >>> >>> >>>? ? ?This probably could/should be a different webrev (which I >>> can do >>> >>>? ? ?if you like) but is there any way while you are changing this >>> >>>? ? ?that the enum for JVMTI_VERSION could become a set of >>> #define? >>> >>> >>> >>>? ? ?So instead of: >>> >>>? ? ?enum { >>> >>>? ? ?? ? JVMTI_VERSION_1? ?= 0x30010000, >>> >>>? ? ?? ? JVMTI_VERSION_1_0 = 0x30010000, >>> >>>? ? ?? ? JVMTI_VERSION_1_1 = 0x30010100, >>> >>>? ? ?? ? JVMTI_VERSION_1_2 = 0x30010200, >>> >>>? ? ?? ? JVMTI_VERSION_9? ?= 0x30090000, >>> >>>? ? ?? ? JVMTI_VERSION_11? = 0x300B0000, >>> >>> >>> >>>? ? ?? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * >>> 0x100) + >>> >>>? ? ?0? /* version: 11.0.0 */ >>> >>>? ? ?}; >>> >>> >>> >>>? ? ?We would get: >>> >>>? ? ?#define JVMTI_VERSION_1 0x30010000 >>> >>>? ? ?#define JVMTI_VERSION_1_0 0x30010000 >>> >>>? ? ?#define JVMTI_VERSION_1_1 = 0x30010100 >>> >>>? ? ?#define JVMTI_VERSION_1_2 = 0x30010200 >>> >>>? ? ?#define JVMTI_VERSION_9? ?= 0x30090000 >>> >>>? ? ?#define JVMTI_VERSION_11? = 0x300B0000 >>> >>>? ? ?#define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + (0 * >>> 0x100) >>> >>>? ? ?+ 0? /* version: 11.0.0 */) >>> >> >>> >>? ? ?It is interesting concern and suggestion. >>> >>? ? ?I'm not sure if it requires a CSR. >>> >> >>> >> >>> >>>? ? ?I actually don't care about any define of these except for >>> >>>? ? ?JVMTI_VERSION; basically it would be useful so that in >>> our agent >>> >>>? ? ?code we can test the JVMTI_VERSION with #if macros to >>> protect the >>> >>>? ? ?code when new elements show up in future versions. So it also >>> >>>? ? ?could be: >>> >>>? ? ?enum { >>> >>>? ? ?? ? JVMTI_VERSION_1? ?= 0x30010000, >>> >>>? ? ?? ? JVMTI_VERSION_1_0 = 0x30010000, >>> >>>? ? ?? ? JVMTI_VERSION_1_1 = 0x30010100, >>> >>>? ? ?? ? JVMTI_VERSION_1_2 = 0x30010200, >>> >>>? ? ?? ? JVMTI_VERSION_9? ?= 0x30090000, >>> >>>? ? ?? ? JVMTI_VERSION_11? = 0x300B0000, >>> >>> >>> >>>? ? ?? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * >>> 0x100) + >>> >>>? ? ?0? /* version: 11.0.0 */ >>> >>>? ? ?}; >>> >>> >>> >>>? ? ?#define JVMTI_LATEST_VERSION (0x30000000 + (11 * 0x10000) >>> + (0 * >>> >>>? ? ?0x100) + 0? /* version: 11.0.0 */) >>> >> >>> >>? ? ?I is not a problem to implement this one. >>> >>? ? ?But I'm not sure how does this really help in your case. >>> >>? ? ?I do not see a point to test the JVMTI_VERSION with #if as >>> it is >>> >>? ? ?always defined. >>> >>? ? ?Could you, please, elaborate a little bit more? >>> >> >>> >>? ? ?Thanks, >>> >>? ? ?Serguei >>> >> >>> >>>? ? ?Right now, I have to do weird things where I detect the >>> jvmti.h >>> >>>? ? ?used at compile time to then do -DUSING_JDK11 for the >>> agent at >>> >>>? ? ?compile time. >>> >>> >>> >>>? ? ?Thanks! >>> >>>? ? ?Jc >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>? ? ?On Thu, May 9, 2019 at 8:48 AM serguei.spitsyn at oracle.com >>> >>> >>>? ? ?>> > >> >>> >>>? ? ?>> >> wrote: >>> >>> >>> >>>? ? ? ? ?I'll try to get rid of VERSION_INTERIM. >>> >>>? ? ? ? ?Always using just VERSION_FEATURE.0.0 should not >>> create problems >>> >>>? ? ? ? ?if we do not change JVMTI spec in VERSION_UPDATE. >>> >>>? ? ? ? ?I do not see why we would change the JVMTI spec in update >>> >>>? ? ? ? ?releases. >>> >>>? ? ? ? ?But if we do then using VERSION_UPDATE as >>> microversion would >>> >>>? ? ? ? ?be good enough. >>> >>> >>> >>>? ? ? ? ?Thanks! >>> >>>? ? ? ? ?Serguei >>> >>> >>> >>> >>> >>>? ? ? ? ?On 5/9/19 06:13, David Holmes wrote: >>> >>>? ? ? ? ?> Hi Serguei, >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com >>> >>> >>>? ? ? ? ?>> > wrote: >>> >>>? ? ? ? ?>> Hi David, >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> Thank you a lot for review! >>> >>>? ? ? ? ?>> There are some replies below. >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> On 5/8/19 18:42, David Holmes wrote: >>> >>>? ? ? ? ?>>> Hi Serguei, >>> >>>? ? ? ? ?>>> >>> >>>? ? ? ? ?>>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com >>> >>> >>>? ? ? ? ?>> > wrote: >>> >>>? ? ? ? ?>>>> Please, review a fix for the task: >>> >>>? ? ? ? ?>>>> https://bugs.openjdk.java.net/browse/JDK-8219023 >>> >>>? ? ? ? ?>>>> >>> >>>? ? ? ? ?>>>> Webrev: >>> >>>? ? ? ? ?>>>> >>> >>> >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >>> >>> >>> >>>? ? ? ? ?>>>> >>> >>>? ? ? ? ?>>>> >>> >>>? ? ? ? ?>>>> Summary: >>> >>>? ? ? ? ?>>>> >>> >>>? ? ? ? ?>>>> ??By design as we have never bumped the JVMTI >>> version unless >>> >>>? ? ? ? ?>>>> ??there were spec changes for that release. Now >>> we want >>> >>>? ? ? ? ?to sync >>> >>>? ? ? ? ?>>>> ??the JVMTI version with the JDK version >>> regardless of >>> >>>? ? ? ? ?whether >>> >>>? ? ? ? ?>>>> ??or not spec changes have occurred in that release. >>> >>>? ? ? ? ?>>>> ??Also, we want it automatically set by the >>> build system >>> >>>? ? ? ? ?so that >>> >>>? ? ? ? ?>>>> ??no manual updates are needed for each release. >>> >>>? ? ? ? ?>>>> >>> >>>? ? ? ? ?>>>> ??The jvmti.h and jvmti.html (JVMTI spec) are >>> generated from >>> >>>? ? ? ? ?>>>> ??the jvmti.xsl with the XSLT scripts now. So, >>> the fix >>> >>>? ? ? ? ?removes >>> >>>? ? ? ? ?>>>> ??hard coded major, minor and micro versions >>> from the >>> >>>? ? ? ? ?jvmti.xml >>> >>>? ? ? ? ?>>>> ??and passes major and minor parameters with the >>> -PARAMETER >>> >>>? ? ? ? ?>>>> ??to the XSL transformation. >>> >>>? ? ? ? ?>>>> >>> >>>? ? ? ? ?>>>> ??Another part of the fix is in the JDI which starts >>> >>>? ? ? ? ?using JDK >>> >>>? ? ? ? ?>>>> ??versions now instead of maintaining its own, >>> and in >>> >>>? ? ? ? ?the JDWP >>> >>>? ? ? ? ?>>>> ??agent which is using the JVMTI versions >>> instead of its >>> >>>? ? ? ? ?own. >>> >>>? ? ? ? ?>>> >>> >>>? ? ? ? ?>>> This all seems reasonable (though I'm no expert on >>> >>>? ? ? ? ?working with XSL >>> >>>? ? ? ? ?>>> etc). >>> >>>? ? ? ? ?>>> >>> >>>? ? ? ? ?>>> One thing I am unclear of is why you bother with >>> using >>> >>>? ? ? ? ?>>> VERSION_INTERIM when the actual version check >>> will only >>> >>>? ? ? ? ?consider >>> >>>? ? ? ? ?>>> VERSION_FEATURE (aka major). Couldn't you just >>> leave the >>> >>>? ? ? ? ?"minor" >>> >>>? ? ? ? ?>>> part 0 the same as the "micro" part? >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> This is right question to ask. >>> >>>? ? ? ? ?>> I was two-folded on this. >>> >>>? ? ? ? ?>> But finally decided to maintain minor version (aka >>> >>>? ? ? ? ?VERSION_INTERIM). >>> >>>? ? ? ? ?>> Then the JVMTI and debugger version will match the >>> VM and >>> >>>? ? ? ? ?JDK version >>> >>>? ? ? ? ?>> for update releases. >>> >>>? ? ? ? ?>> If understand it correctly, we are still going to have >>> >>>? ? ? ? ?major.minor >>> >>>? ? ? ? ?>> versions. >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> Not really. What we have now are things like 11.0.3 and >>> >>>? ? ? ? ?12.0.1 - only >>> >>>? ? ? ? ?> using the first and third parts. The full 4 part >>> version >>> >>>? ? ? ? ?string is: >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> >>> >>> ?$VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> and we typically only update version_feature and >>> >>>? ? ? ? ?version_update. >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> https://openjdk.java.net/jeps/322 >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?>> Also, the JVMTI GetVersionNumberspec still tells about >>> >>>? ? ? ? ?both minor and >>> >>>? ? ? ? ?>> micro versions. >>> >>>? ? ? ? ?>> It also defines special constants for >>> corresponding masks >>> >>>? ? ? ? ?and shifts: >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> ??? Version Masks >>> >>>? ? ? ? ?>> ??? Constant???? Value Description >>> >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 >>> >>>? ? ? ? ?Mask to >>> >>>? ? ? ? ?>> extract >>> >>>? ? ? ? ?>> ??? interface type. The value of the version >>> returned by >>> >>>? ? ? ? ?this function >>> >>>? ? ? ? ?>> ??? masked with >>> |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always >>> >>>? ? ? ? ?>> |JVMTI_VERSION_INTERFACE_JVMTI| since this is a JVMTI >>> >>>? ? ? ? ?function. >>> >>>? ? ? ? ?>> ??? |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000???? Mask to >>> >>>? ? ? ? ?extract major >>> >>>? ? ? ? ?>> ??? version number. >>> >>>? ? ? ? ?>> ??? |JVMTI_VERSION_MASK_MINOR| 0x0000FF00???? Mask to >>> >>>? ? ? ? ?extract minor >>> >>>? ? ? ? ?>> ??? version number. >>> >>>? ? ? ? ?>> ??? |JVMTI_VERSION_MASK_MICRO| 0x000000FF???? Mask to >>> >>>? ? ? ? ?extract micro >>> >>>? ? ? ? ?>> ??? version number. >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> ??? Version Shifts >>> >>>? ? ? ? ?>> ??? Constant???? Value Description >>> >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MAJOR|???? 16 Shift to >>> extract major >>> >>>? ? ? ? ?>> version number. >>> >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MINOR|???? 8 Shift to extract >>> minor >>> >>>? ? ? ? ?>> version number. >>> >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MICRO|???? 0 Shift to extract >>> micro >>> >>>? ? ? ? ?>> version number. >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> This is link to the spec: >>> >>>? ? ? ? ?>> >>> >>> >>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber >>> >>> >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> It seems, changing (and/or deprecating) this will give >>> >>>? ? ? ? ?more problems >>> >>>? ? ? ? ?>> than benefits. >>> >>>? ? ? ? ?>> It is better to remain compatible with previous >>> releases. >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> This is a problem that was flagged when the new >>> versioning >>> >>>? ? ? ? ?scheme was >>> >>>? ? ? ? ?> introduced but I'm guessing nothing was actually >>> done about >>> >>>? ? ? ? ?it. They >>> >>>? ? ? ? ?> are not really compatible beyond the major/feature >>> part. >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> If we only update the spec version with the feature >>> version >>> >>>? ? ? ? ?then all >>> >>>? ? ? ? ?> versions will have the form N.0.0. However your changes >>> >>>? ? ? ? ?will also >>> >>>? ? ? ? ?> update if we happen to use a VERSION_INTERIM for some >>> >>>? ? ? ? ?reason - though >>> >>>? ? ? ? ?> the version check will ignore that anyway. I'm not >>> really >>> >>>? ? ? ? ?seeing the >>> >>>? ? ? ? ?> point in having that happen. >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> Maybe we do need to define a new version API that >>> maps to >>> >>>? ? ? ? ?the new >>> >>>? ? ? ? ?> versioning scheme of OpenJDK ? But if we did that we'd >>> >>>? ? ? ? ?still have to >>> >>>? ? ? ? ?> support the legacy mapping and I'd still advocate >>> simply using >>> >>>? ? ? ? ?> VERSION_FEATURE.0.0. >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> It's tricky. >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?> David >>> >>>? ? ? ? ?> ----- >>> >>>? ? ? ? ?> >>> >>>? ? ? ? ?>>> For the record I considered whether this needs a CSR >>> >>>? ? ? ? ?request and >>> >>>? ? ? ? ?>>> concluded it did not as it doesn't involve >>> changing any >>> >>>? ? ? ? ?actual >>> >>>? ? ? ? ?>>> specifications. >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> Okay, thanks. >>> >>>? ? ? ? ?>> I considered it too, made the same conclusion but >>> still >>> >>>? ? ? ? ?have some >>> >>>? ? ? ? ?>> doubt. :) >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>> Thanks! >>> >>>? ? ? ? ?>> Serguei >>> >>>? ? ? ? ?>> >>> >>>? ? ? ? ?>>> >>> >>>? ? ? ? ?>>> Thanks, >>> >>>? ? ? ? ?>>> David >>> >>>? ? ? ? ?>>> >>> >>>? ? ? ? ?>>>> Testing: >>> >>>? ? ? ? ?>>>> ??Generated docs and jvmti.h and checked the >>> versions >>> >>>? ? ? ? ?are correct. >>> >>>? ? ? ? ?>>>> >>> >>>? ? ? ? ?>>>> One could ask if we have to use same or similar >>> approach for >>> >>>? ? ? ? ?>>>> other API's and tools, like JNI, JMX and so on. >>> >>>? ? ? ? ?>>>> But these are not areas of my expertise or >>> responsibility. >>> >>>? ? ? ? ?>>>> It just feels like there is some room for >>> unification here. >>> >>>? ? ? ? ?>>>> >>> >>>? ? ? ? ?>>>> Thanks, >>> >>>? ? ? ? ?>>>> Serguei >>> >>>? ? ? ? ?>> >>> >>> >>> >>> >>> >>> >>> >>>? ? ?-- >>> >>> >>> >>>? ? ?Thanks, >>> >>>? ? ?Jc >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Thanks, >>> >> Jc >>> > >>> >>> >>> >>> -- >>> >>> Thanks, >>> Jc >> > From sakamoto.osamu at nttcom.co.jp Fri May 10 02:43:42 2019 From: sakamoto.osamu at nttcom.co.jp (=?utf-8?B?5Z2C5pysIOe1sQ==?=) Date: Fri, 10 May 2019 02:43:42 +0000 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> Message-ID: <04649AF8E13EB949B7D27EFDD2A37DFEE2B2407F@WMBOX4.soad.nttcom.co.jp> Hi, Jc Thank you for reviewing my patch. I think it is another issue if we implement generalize handling for longOpts as you said. Thanks, Osamu -----Original Message----- From: Jean Christophe Beyler Sent: Friday, May 10, 2019 1:18 AM To: ?? ? Cc: serviceability-dev at openjdk.java.net; ?? ?? Subject: Re: debugd options should regard to jhsdb style Hi Osamu, The patch looks good to me (I'm not an official reviewer though and I wonder if we should factorize that code a bit, it seems we do the longOpts with variations of options all over the place and we could just have a generic one and all call it. But that is a different webrev I think). Thanks, Jc On Thu, May 9, 2019 at 1:34 AM ?? ? > wrote: Hi all, I want to use `jhsdb debugd` on my laptop. However debugd mode has different options from other modes. I think debugd should have same options like other modes. For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. Also I added `--serverid` option for serverid. I attached a patch for this enhancement. This patch passes serviceability/sa jtreg tests. Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . However it has been disabled by JDK-8163805. It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. Could you help? I want to contribute it. I need a sponsor. (My company has signed to OCA (NTT Comware Corporation)) Thanks, Osamu -- Thanks, Jc From sakamoto.osamu at nttcom.co.jp Fri May 10 02:53:06 2019 From: sakamoto.osamu at nttcom.co.jp (=?utf-8?B?5Z2C5pysIOe1sQ==?=) Date: Fri, 10 May 2019 02:53:06 +0000 Subject: debugd options should regard to jhsdb style In-Reply-To: <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> Message-ID: <04649AF8E13EB949B7D27EFDD2A37DFEE2B240B0@WMBOX4.soad.nttcom.co.jp> Hi, David Thank you for reviewing my patch. Yasumasa Thank you for reviewing my patch and sponsoring this issue. Thanks, Osamu -----Original Message----- From: Yasumasa Suenaga Sent: Friday, May 10, 2019 10:21 AM To: David Holmes ; ?? ? Cc: serviceability-dev at openjdk.java.net Subject: Re: debugd options should regard to jhsdb style Hi, Osamu, your change looks good to me. I will sponsor you. David, I filed this issue and requested to CSR: JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 I uploaded webrev. I will push it to submit repo. http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ Thanks, Yasumasa On 2019/05/10 7:30, David Holmes wrote: > Hi, > > This will need a bug filed and a corresponding CSR request. I suspect > that historically the form of this command was done to match other tools. > > > Thanks, > David > > On 9/05/2019 6:33 pm, ?? ? wrote: >> Hi all, >> >> I want to use `jhsdb debugd` on my laptop. >> However debugd mode has different options from other modes. >> I think debugd should have same options like other modes. >> >> For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. >> Also I added `--serverid` option for serverid. >> >> I attached a patch for this enhancement. >> This patch passes serviceability/sa jtreg tests. >> >> Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . >> However it has been disabled by JDK-8163805. >> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. >> >> Could you help? I want to contribute it. I need a sponsor. >> (My company has signed to OCA (NTT Comware Corporation)) >> >> Thanks, >> >> Osamu >> From yasuenag at gmail.com Fri May 10 03:05:26 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 May 2019 12:05:26 +0900 Subject: debugd options should regard to jhsdb style In-Reply-To: <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> Message-ID: tests on submit repo have been passed (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) Could you review the CSR? > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 Yasumasa 2019?5?10?(?) 10:20 Yasumasa Suenaga : > > Hi, > > Osamu, your change looks good to me. > I will sponsor you. > > David, I filed this issue and requested to CSR: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > > I uploaded webrev. I will push it to submit repo. > > http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ > > > Thanks, > > Yasumasa > > > On 2019/05/10 7:30, David Holmes wrote: > > Hi, > > > > This will need a bug filed and a corresponding CSR request. I suspect > > that historically the form of this command was done to match other tools. > > > > > > Thanks, > > David > > > > On 9/05/2019 6:33 pm, ?? ? wrote: > >> Hi all, > >> > >> I want to use `jhsdb debugd` on my laptop. > >> However debugd mode has different options from other modes. > >> I think debugd should have same options like other modes. > >> > >> For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. > >> Also I added `--serverid` option for serverid. > >> > >> I attached a patch for this enhancement. > >> This patch passes serviceability/sa jtreg tests. > >> > >> Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . > >> However it has been disabled by JDK-8163805. > >> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. > >> > >> Could you help? I want to contribute it. I need a sponsor. > >> (My company has signed to OCA (NTT Comware Corporation)) > >> > >> Thanks, > >> > >> Osamu > >> From jcbeyler at google.com Fri May 10 03:54:18 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 9 May 2019 20:54:18 -0700 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> Message-ID: Hi Yasumasa, I'm not a reviewer but the CSR looks good; I feel that the specification section could use some text and then send the reader to the other bug entry :) Jc *From: *Yasumasa Suenaga *Date: *Thu, May 9, 2019 at 8:06 PM *To: *serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net tests on submit repo have been passed > (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) > > Could you review the CSR? > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > > > Yasumasa > > > 2019?5?10?(?) 10:20 Yasumasa Suenaga : > > > > Hi, > > > > Osamu, your change looks good to me. > > I will sponsor you. > > > > David, I filed this issue and requested to CSR: > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 > > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > > > > I uploaded webrev. I will push it to submit repo. > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2019/05/10 7:30, David Holmes wrote: > > > Hi, > > > > > > This will need a bug filed and a corresponding CSR request. I suspect > > > that historically the form of this command was done to match other > tools. > > > > > > > > > Thanks, > > > David > > > > > > On 9/05/2019 6:33 pm, ?? ? wrote: > > >> Hi all, > > >> > > >> I want to use `jhsdb debugd` on my laptop. > > >> However debugd mode has different options from other modes. > > >> I think debugd should have same options like other modes. > > >> > > >> For example, `jhsdb debugd ` should be `jhsdb debugd --pid > `. > > >> Also I added `--serverid` option for serverid. > > >> > > >> I attached a patch for this enhancement. > > >> This patch passes serviceability/sa jtreg tests. > > >> > > >> Testcase for debugd is available as > serviceability/sa/sadebugd/SADebugDTest.java . > > >> However it has been disabled by JDK-8163805. > > >> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has > been merged. > > >> > > >> Could you help? I want to contribute it. I need a sponsor. > > >> (My company has signed to OCA (NTT Comware Corporation)) > > >> > > >> Thanks, > > >> > > >> Osamu > > >> > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri May 10 04:12:33 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 May 2019 13:12:33 +0900 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> Message-ID: Thanks JC! I added key point of this change to specification section in CSR. Yasumasa 2019?5?10?(?) 12:54 Jean Christophe Beyler : > > Hi Yasumasa, > > I'm not a reviewer but the CSR looks good; I feel that the specification section could use some text and then send the reader to the other bug entry :) > Jc > > From: Yasumasa Suenaga > Date: Thu, May 9, 2019 at 8:06 PM > To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > >> tests on submit repo have been passed >> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >> >> Could you review the CSR? >> >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >> >> >> Yasumasa >> >> >> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >> > >> > Hi, >> > >> > Osamu, your change looks good to me. >> > I will sponsor you. >> > >> > David, I filed this issue and requested to CSR: >> > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >> > >> > I uploaded webrev. I will push it to submit repo. >> > >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >> > >> > >> > Thanks, >> > >> > Yasumasa >> > >> > >> > On 2019/05/10 7:30, David Holmes wrote: >> > > Hi, >> > > >> > > This will need a bug filed and a corresponding CSR request. I suspect >> > > that historically the form of this command was done to match other tools. >> > > >> > > >> > > Thanks, >> > > David >> > > >> > > On 9/05/2019 6:33 pm, ?? ? wrote: >> > >> Hi all, >> > >> >> > >> I want to use `jhsdb debugd` on my laptop. >> > >> However debugd mode has different options from other modes. >> > >> I think debugd should have same options like other modes. >> > >> >> > >> For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. >> > >> Also I added `--serverid` option for serverid. >> > >> >> > >> I attached a patch for this enhancement. >> > >> This patch passes serviceability/sa jtreg tests. >> > >> >> > >> Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . >> > >> However it has been disabled by JDK-8163805. >> > >> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. >> > >> >> > >> Could you help? I want to contribute it. I need a sponsor. >> > >> (My company has signed to OCA (NTT Comware Corporation)) >> > >> >> > >> Thanks, >> > >> >> > >> Osamu >> > >> > > > > -- > > Thanks, > Jc From jcbeyler at google.com Fri May 10 05:00:09 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 9 May 2019 22:00:09 -0700 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> Message-ID: Hi Yasumasa, That looks better to me at least :) Thanks! Jc *From: *Yasumasa Suenaga *Date: *Thu, May 9, 2019 at 9:12 PM *To: *Jean Christophe Beyler *Cc: *serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net Thanks JC! > > I added key point of this change to specification section in CSR. > > > Yasumasa > > 2019?5?10?(?) 12:54 Jean Christophe Beyler : > > > > Hi Yasumasa, > > > > I'm not a reviewer but the CSR looks good; I feel that the specification > section could use some text and then send the reader to the other bug entry > :) > > Jc > > > > From: Yasumasa Suenaga > > Date: Thu, May 9, 2019 at 8:06 PM > > To: serviceability-dev at openjdk.java.net > serviceability-dev at openjdk.java.net > > > >> tests on submit repo have been passed > >> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) > >> > >> Could you review the CSR? > >> > >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > >> > >> > >> Yasumasa > >> > >> > >> 2019?5?10?(?) 10:20 Yasumasa Suenaga : > >> > > >> > Hi, > >> > > >> > Osamu, your change looks good to me. > >> > I will sponsor you. > >> > > >> > David, I filed this issue and requested to CSR: > >> > > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 > >> > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > >> > > >> > I uploaded webrev. I will push it to submit repo. > >> > > >> > http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ > >> > > >> > > >> > Thanks, > >> > > >> > Yasumasa > >> > > >> > > >> > On 2019/05/10 7:30, David Holmes wrote: > >> > > Hi, > >> > > > >> > > This will need a bug filed and a corresponding CSR request. I > suspect > >> > > that historically the form of this command was done to match other > tools. > >> > > > >> > > > >> > > Thanks, > >> > > David > >> > > > >> > > On 9/05/2019 6:33 pm, ?? ? wrote: > >> > >> Hi all, > >> > >> > >> > >> I want to use `jhsdb debugd` on my laptop. > >> > >> However debugd mode has different options from other modes. > >> > >> I think debugd should have same options like other modes. > >> > >> > >> > >> For example, `jhsdb debugd ` should be `jhsdb debugd --pid > `. > >> > >> Also I added `--serverid` option for serverid. > >> > >> > >> > >> I attached a patch for this enhancement. > >> > >> This patch passes serviceability/sa jtreg tests. > >> > >> > >> > >> Testcase for debugd is available as > serviceability/sa/sadebugd/SADebugDTest.java . > >> > >> However it has been disabled by JDK-8163805. > >> > >> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal > has been merged. > >> > >> > >> > >> Could you help? I want to contribute it. I need a sponsor. > >> > >> (My company has signed to OCA (NTT Comware Corporation)) > >> > >> > >> > >> Thanks, > >> > >> > >> > >> Osamu > >> > >> > > > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri May 10 06:16:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 10 May 2019 16:16:34 +1000 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> Message-ID: <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> Hi Yasumasa, I've made some updates to the CSR request and raised a couple of issues. FYI the specification section only needs to contain the actual specification for what has changed ie the new command-line options; not the implementation that will bring about those changes. Thanks, David On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: > Thanks JC! > > I added key point of this change to specification section in CSR. > > > Yasumasa > > 2019?5?10?(?) 12:54 Jean Christophe Beyler : >> >> Hi Yasumasa, >> >> I'm not a reviewer but the CSR looks good; I feel that the specification section could use some text and then send the reader to the other bug entry :) >> Jc >> >> From: Yasumasa Suenaga >> Date: Thu, May 9, 2019 at 8:06 PM >> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net >> >>> tests on submit repo have been passed >>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>> >>> Could you review the CSR? >>> >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>> >>> >>> Yasumasa >>> >>> >>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>> >>>> Hi, >>>> >>>> Osamu, your change looks good to me. >>>> I will sponsor you. >>>> >>>> David, I filed this issue and requested to CSR: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>> >>>> I uploaded webrev. I will push it to submit repo. >>>> >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/05/10 7:30, David Holmes wrote: >>>>> Hi, >>>>> >>>>> This will need a bug filed and a corresponding CSR request. I suspect >>>>> that historically the form of this command was done to match other tools. >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>> Hi all, >>>>>> >>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>> However debugd mode has different options from other modes. >>>>>> I think debugd should have same options like other modes. >>>>>> >>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. >>>>>> Also I added `--serverid` option for serverid. >>>>>> >>>>>> I attached a patch for this enhancement. >>>>>> This patch passes serviceability/sa jtreg tests. >>>>>> >>>>>> Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . >>>>>> However it has been disabled by JDK-8163805. >>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. >>>>>> >>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Osamu >>>>>> >> >> >> >> -- >> >> Thanks, >> Jc From yasuenag at gmail.com Fri May 10 07:07:39 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 10 May 2019 16:07:39 +0900 Subject: debugd options should regard to jhsdb style In-Reply-To: <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> Message-ID: Hi David, Thank you for checking in CSR, and sorry for my incorrect description. I added my opinion to CSR. Osamu, do you have any opinion? Yasumasa 2019?5?10?(?) 15:16 David Holmes : > > Hi Yasumasa, > > I've made some updates to the CSR request and raised a couple of issues. > > FYI the specification section only needs to contain the actual > specification for what has changed ie the new command-line options; not > the implementation that will bring about those changes. > > Thanks, > David > > On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: > > Thanks JC! > > > > I added key point of this change to specification section in CSR. > > > > > > Yasumasa > > > > 2019?5?10?(?) 12:54 Jean Christophe Beyler : > >> > >> Hi Yasumasa, > >> > >> I'm not a reviewer but the CSR looks good; I feel that the specification section could use some text and then send the reader to the other bug entry :) > >> Jc > >> > >> From: Yasumasa Suenaga > >> Date: Thu, May 9, 2019 at 8:06 PM > >> To: serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net > >> > >>> tests on submit repo have been passed > >>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) > >>> > >>> Could you review the CSR? > >>> > >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > >>> > >>> > >>> Yasumasa > >>> > >>> > >>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : > >>>> > >>>> Hi, > >>>> > >>>> Osamu, your change looks good to me. > >>>> I will sponsor you. > >>>> > >>>> David, I filed this issue and requested to CSR: > >>>> > >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 > >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > >>>> > >>>> I uploaded webrev. I will push it to submit repo. > >>>> > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>> On 2019/05/10 7:30, David Holmes wrote: > >>>>> Hi, > >>>>> > >>>>> This will need a bug filed and a corresponding CSR request. I suspect > >>>>> that historically the form of this command was done to match other tools. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 9/05/2019 6:33 pm, ?? ? wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> I want to use `jhsdb debugd` on my laptop. > >>>>>> However debugd mode has different options from other modes. > >>>>>> I think debugd should have same options like other modes. > >>>>>> > >>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. > >>>>>> Also I added `--serverid` option for serverid. > >>>>>> > >>>>>> I attached a patch for this enhancement. > >>>>>> This patch passes serviceability/sa jtreg tests. > >>>>>> > >>>>>> Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . > >>>>>> However it has been disabled by JDK-8163805. > >>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. > >>>>>> > >>>>>> Could you help? I want to contribute it. I need a sponsor. > >>>>>> (My company has signed to OCA (NTT Comware Corporation)) > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Osamu > >>>>>> > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc From serguei.spitsyn at oracle.com Fri May 10 08:03:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 May 2019 01:03:36 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> Message-ID: <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> Hi David, On 5/9/19 18:51, David Holmes wrote: > Hi Serguei, > > On 10/05/2019 10:32 am, serguei.spitsyn at oracle.com wrote: >> I've updated the webrev v2 in place. > > ?make/hotspot/gensrc/GensrcJvmti.gmk > > You don't need to pass through: -PARAM minorversion $(VERSION_INTERIM) Good catch. How did I missed to remove? > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java > > > ?57???? private static final int minorVersion = > Runtime.version().interim(); > > That should be kept at 0. Okay, fixed. New webrev is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ > > I'd like to see an actual diff of the generated jvmti.h and jvmti.html > files as well please. Some of the XSL stuff looks odd to me. The jvmti.h diff: 2c2 ? * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. 47c47 ???? JVMTI_VERSION = 0x30000000 + (13 * 0x10000) + ( 0 * 0x100) + 0? /* version: 13.0.0 */ The jvmti.html diff: 5c5 JVM(TM) Tool Interface 11.0.0 --- >???????? JVM(TM) Tool Interface 13.0.0 30c30 Version 11.0 --- >????????????

Version 13.0

34931c34931 ???????????????? Version: 13.0.0 Thanks, Serguei > > Thanks, > David > >> Thanks, >> Serguei >> >> >> On 5/9/19 17:28, serguei.spitsyn at oracle.com wrote: >>> David and Jc, >>> >>> Okay, I'll remove this line now. >>> Thank you for your comments. >>> >>> Let's let Jc to file a separate enhancement on this. >>> Then I'll file a CSR and prepare a fix. >>> >>> I hope, you both are Okay with the rest. >>> >>> Thanks! >>> Serguei >>> >>> >>> On 5/9/19 17:17, Jean Christophe Beyler wrote: >>>> Hi Serguei, >>>> >>>> Adding to the difficulties that David is exposing, this won't work. >>>> You need to redo the xls definition because you need the #define to >>>> be the numeric value directly and not the enum; otherwise it won't >>>> work in any usable way at preprocessor time sadly. >>>> >>>> I think it makes sense to just do what you were planning to do here >>>> without this and I'll file a bug and work out the CSR path and >>>> review path separately and see what is do-able or not then because >>>> I think it's too much work now "just for this now" if that makes >>>> sense :) >>>> Jc >>>> >>>> *From: *David Holmes >>> > >>>> *Date: *Thu, May 9, 2019 at 5:11 PM >>>> *To: *serguei.spitsyn at oracle.com >>>> , Jean Christophe Beyler >>>> *Cc: *serviceability-dev >>>> >>>> ??? On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com >>>> ??? wrote: >>>> ??? > Hi Jc, >>>> ??? > >>>> ??? > Okay, you convinced me - thanks! >>>> ??? > Added new line into the generated jvmti.h: >>>> ??? > >>>> ??? >? ? #define JVMTI_VERSION_LATEST JVMTI_VERSION >>>> >>>> ??? That requires a CSR as you are expanding the exported interface. >>>> >>>> ??? Also you need >>>> >>>> ??? #define JVMTI_VERSION_LATEST (JVMTI_VERSION) >>>> >>>> ??? as JVMTI_VERSION is itself an expression not a constant. That >>>> might >>>> ??? limit the utility of having such a define as you won't be able to >>>> ??? use it >>>> ??? in an ifdef guard to test a value AFAICS. >>>> >>>> ??? David >>>> >>>> ??? > I hope, it will help in your case. >>>> ??? > >>>> ??? > >>>> ??? > Updated webrev version is: >>>> ??? > >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ >>>> >>>> ??? > >>>> ??? > >>>> ??? > This version includes suggestions from David. >>>> ??? > >>>> ??? > Thanks, >>>> ??? > Serguei >>>> ??? > >>>> ??? > >>>> ??? > >>>> ??? > On 5/9/19 14:17, Jean Christophe Beyler wrote: >>>> ??? >> Hi Serguei, >>>> ??? >> >>>> ??? >> Of course I can :) >>>> ??? >> >>>> ??? >> Consider, just randomly of course, the heap sampling work that >>>> ??? got >>>> ??? >> added to JVMTI. Now imagine you'd want to test if it is >>>> ??? supported by a >>>> ??? >> given JVMTI version, you would write something like this: >>>> ??? >> >>>> ??? >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >>>> ??? >> ? jvmtiCapabilities caps; >>>> ??? >> ? memset(&caps, 0, sizeof(caps)); >>>> ??? >> ? if (jvmti->GetPotentialCapabilities(&caps) != >>>> ??? JVMTI_ERROR_NONE) { >>>> ??? >> ? ? LOG(WARNING) << "Failed to get potential capabilities, >>>> ??? disabling >>>> ??? >> the heap " >>>> ??? >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >>>> ??? >> ? ? return false; >>>> ??? >> ? } >>>> ??? >> >>>> ??? >> ? return caps.can_generate_sampled_object_alloc_events >>>> ??? >> ? ? ? && caps.can_generate_garbage_collection_events; >>>> ??? >> } >>>> ??? >> >>>> ??? >> Now, the problem is that this code cannot be used if you >>>> ??? compile with >>>> ??? >> an older JDK such as JDK8 for example >>>> ??? >> because?can_generate_sampled_object_alloc_events does not >>>> ??? exist yet >>>> ??? >> for that jvmti.h file. >>>> ??? >> >>>> ??? >> >>>> ??? >> In a perfect world, we might imagine that we are always >>>> ??? compiling with >>>> ??? >> the latest JVMTI headers but that is not always true and, >>>> ??? therefore, >>>> ??? >> to have the code portable, we now have to do: >>>> ??? >> >>>> ??? >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >>>> ??? >> #ifdef ENABLE_HEAP_SAMPLING >>>> ??? >> ? jvmtiCapabilities caps; >>>> ??? >> ? memset(&caps, 0, sizeof(caps)); >>>> ??? >> ? if (jvmti->GetPotentialCapabilities(&caps) != >>>> ??? JVMTI_ERROR_NONE) { >>>> ??? >> ? ? LOG(WARNING) << "Failed to get potential capabilities, >>>> ??? disabling >>>> ??? >> the heap " >>>> ??? >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >>>> ??? >> ? ? return false; >>>> ??? >> ? } >>>> ??? >> >>>> ??? >> ? return caps.can_generate_sampled_object_alloc_events >>>> ??? >> ? ? ? && caps.can_generate_garbage_collection_events; >>>> ??? >> #else >>>> ??? >> ? return false; >>>> ??? >> #endif >>>> ??? >> } >>>> ??? >> >>>> ??? >> Where ENABLE_HEAP_SAMPLING is defined if we did compile with >>>> ??? JDK11 and >>>> ??? >> not defined if we compiled with JDK8. I can't use JVMTI_VERSION >>>> ??? >> because I can't use it in an #if because it is not an enum. >>>> ??? Were it to >>>> ??? >> be a #define or were I to have a #define I could use with a >>>> ??? version >>>> ??? >> number being bumped up, I could write something such as: >>>> ??? >> >>>> ??? >> #ifdef JVMTI_VERSION_11 >>>> ??? >> >>>> ??? >> or something that looks in the value of the JVMTI_VERSION if I >>>> ??? wanted. >>>> ??? >> Right now, I can't even do that! >>>> ??? >> >>>> ??? >> Hopefully this helps understand what I am talking about :-), >>>> ??? >> Jc >>>> ??? >> >>>> ??? >> >>>> ??? >> >>>> ??? >> >>>> ??? >> On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com >>>> ??? >>>> ??? >> >>> ??? > >>> ??? >>>> ??? >> >>> ??? >> wrote: >>>> ??? >> >>>> ??? >>? ? ?Hi Jc, >>>> ??? >> >>>> ??? >>? ? ?Thank you a lot for review! >>>> ??? >>? ? ?Some replies below. >>>> ??? >> >>>> ??? >> >>>> ??? >>? ? ?On 5/9/19 09:10, Jean Christophe Beyler wrote: >>>> ??? >>>? ? ?Hi Serguei, >>>> ??? >>> >>>> ??? >>>? ? ?FWIW, the change looks good and I think it's a good idea >>>> ??? to do. >>>> ??? >>>? ? ?However, there is one thorn in our internal agent code is >>>> ??? that >>>> ??? >>>? ? ?the JVMTI_VERSION is in an enum. This makes us unable to >>>> ??? #if it >>>> ??? >>>? ? ?when adding usages of newer features/methods. >>>> ??? >>> >>>> ??? >>>? ? ?This probably could/should be a different webrev (which I >>>> ??? can do >>>> ??? >>>? ? ?if you like) but is there any way while you are >>>> changing this >>>> ??? >>>? ? ?that the enum for JVMTI_VERSION could become a set of >>>> ??? #define? >>>> ??? >>> >>>> ??? >>>? ? ?So instead of: >>>> ??? >>>? ? ?enum { >>>> ??? >>>? ? ?? ? JVMTI_VERSION_1? ?= 0x30010000, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_0 = 0x30010000, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_1 = 0x30010100, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_2 = 0x30010200, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_9? ?= 0x30090000, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_11? = 0x300B0000, >>>> ??? >>> >>>> ??? >>>? ? ?? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * >>>> ??? 0x100) + >>>> ??? >>>? ? ?0? /* version: 11.0.0 */ >>>> ??? >>>? ? ?}; >>>> ??? >>> >>>> ??? >>>? ? ?We would get: >>>> ??? >>>? ? ?#define JVMTI_VERSION_1 0x30010000 >>>> ??? >>>? ? ?#define JVMTI_VERSION_1_0 0x30010000 >>>> ??? >>>? ? ?#define JVMTI_VERSION_1_1 = 0x30010100 >>>> ??? >>>? ? ?#define JVMTI_VERSION_1_2 = 0x30010200 >>>> ??? >>>? ? ?#define JVMTI_VERSION_9? ?= 0x30090000 >>>> ??? >>>? ? ?#define JVMTI_VERSION_11? = 0x300B0000 >>>> ??? >>>? ? ?#define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + (0 * >>>> ??? 0x100) >>>> ??? >>>? ? ?+ 0? /* version: 11.0.0 */) >>>> ??? >> >>>> ??? >>? ? ?It is interesting concern and suggestion. >>>> ??? >>? ? ?I'm not sure if it requires a CSR. >>>> ??? >> >>>> ??? >> >>>> ??? >>>? ? ?I actually don't care about any define of these except for >>>> ??? >>>? ? ?JVMTI_VERSION; basically it would be useful so that in >>>> ??? our agent >>>> ??? >>>? ? ?code we can test the JVMTI_VERSION with #if macros to >>>> ??? protect the >>>> ??? >>>? ? ?code when new elements show up in future versions. So >>>> it also >>>> ??? >>>? ? ?could be: >>>> ??? >>>? ? ?enum { >>>> ??? >>>? ? ?? ? JVMTI_VERSION_1? ?= 0x30010000, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_0 = 0x30010000, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_1 = 0x30010100, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_2 = 0x30010200, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_9? ?= 0x30090000, >>>> ??? >>>? ? ?? ? JVMTI_VERSION_11? = 0x300B0000, >>>> ??? >>> >>>> ??? >>>? ? ?? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * >>>> ??? 0x100) + >>>> ??? >>>? ? ?0? /* version: 11.0.0 */ >>>> ??? >>>? ? ?}; >>>> ??? >>> >>>> ??? >>>? ? ?#define JVMTI_LATEST_VERSION (0x30000000 + (11 * 0x10000) >>>> ??? + (0 * >>>> ??? >>>? ? ?0x100) + 0? /* version: 11.0.0 */) >>>> ??? >> >>>> ??? >>? ? ?I is not a problem to implement this one. >>>> ??? >>? ? ?But I'm not sure how does this really help in your case. >>>> ??? >>? ? ?I do not see a point to test the JVMTI_VERSION with #if as >>>> ??? it is >>>> ??? >>? ? ?always defined. >>>> ??? >>? ? ?Could you, please, elaborate a little bit more? >>>> ??? >> >>>> ??? >>? ? ?Thanks, >>>> ??? >>? ? ?Serguei >>>> ??? >> >>>> ??? >>>? ? ?Right now, I have to do weird things where I detect the >>>> ??? jvmti.h >>>> ??? >>>? ? ?used at compile time to then do -DUSING_JDK11 for the >>>> ??? agent at >>>> ??? >>>? ? ?compile time. >>>> ??? >>> >>>> ??? >>>? ? ?Thanks! >>>> ??? >>>? ? ?Jc >>>> ??? >>> >>>> ??? >>> >>>> ??? >>> >>>> ??? >>> >>>> ??? >>>? ? ?On Thu, May 9, 2019 at 8:48 AM serguei.spitsyn at oracle.com >>>> ??? >>>> ??? >>>? ? ?>>> ??? > >>> ??? >>>> ??? >>>? ? ?>>> ??? >> wrote: >>>> ??? >>> >>>> ??? >>>? ? ? ? ?I'll try to get rid of VERSION_INTERIM. >>>> ??? >>>? ? ? ? ?Always using just VERSION_FEATURE.0.0 should not >>>> ??? create problems >>>> ??? >>>? ? ? ? ?if we do not change JVMTI spec in VERSION_UPDATE. >>>> ??? >>>? ? ? ? ?I do not see why we would change the JVMTI spec in >>>> update >>>> ??? >>>? ? ? ? ?releases. >>>> ??? >>>? ? ? ? ?But if we do then using VERSION_UPDATE as >>>> ??? microversion would >>>> ??? >>>? ? ? ? ?be good enough. >>>> ??? >>> >>>> ??? >>>? ? ? ? ?Thanks! >>>> ??? >>>? ? ? ? ?Serguei >>>> ??? >>> >>>> ??? >>> >>>> ??? >>>? ? ? ? ?On 5/9/19 06:13, David Holmes wrote: >>>> ??? >>>? ? ? ? ?> Hi Serguei, >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com >>>> ??? >>>> ??? >>> ?>>> ??? > wrote: >>>> ??? >>>? ? ? ? ?>> Hi David, >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> Thank you a lot for review! >>>> ??? >>>? ? ? ? ?>> There are some replies below. >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> On 5/8/19 18:42, David Holmes wrote: >>>> ??? >>>? ? ? ? ?>>> Hi Serguei, >>>> ??? >>>? ? ? ? ?>>> >>>> ??? >>>? ? ? ? ?>>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com >>>> ??? >>>> ??? >>> ?>>> ??? > wrote: >>>> ??? >>>? ? ? ? ?>>>> Please, review a fix for the task: >>>> ??? >>>? ? ? ? ?>>>> https://bugs.openjdk.java.net/browse/JDK-8219023 >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>>? ? ? ? ?>>>> Webrev: >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>> >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >>>> >>>> ??? >>> >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>>? ? ? ? ?>>>> Summary: >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>>? ? ? ? ?>>>> ??By design as we have never bumped the JVMTI >>>> ??? version unless >>>> ??? >>>? ? ? ? ?>>>> ??there were spec changes for that release. Now >>>> ??? we want >>>> ??? >>>? ? ? ? ?to sync >>>> ??? >>>? ? ? ? ?>>>> ??the JVMTI version with the JDK version >>>> ??? regardless of >>>> ??? >>>? ? ? ? ?whether >>>> ??? >>>? ? ? ? ?>>>> ??or not spec changes have occurred in that >>>> release. >>>> ??? >>>? ? ? ? ?>>>> ??Also, we want it automatically set by the >>>> ??? build system >>>> ??? >>>? ? ? ? ?so that >>>> ??? >>>? ? ? ? ?>>>> ??no manual updates are needed for each release. >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>>? ? ? ? ?>>>> ??The jvmti.h and jvmti.html (JVMTI spec) are >>>> ??? generated from >>>> ??? >>>? ? ? ? ?>>>> ??the jvmti.xsl with the XSLT scripts now. So, >>>> ??? the fix >>>> ??? >>>? ? ? ? ?removes >>>> ??? >>>? ? ? ? ?>>>> ??hard coded major, minor and micro versions >>>> ??? from the >>>> ??? >>>? ? ? ? ?jvmti.xml >>>> ??? >>>? ? ? ? ?>>>> ??and passes major and minor parameters with the >>>> ??? -PARAMETER >>>> ??? >>>? ? ? ? ?>>>> ??to the XSL transformation. >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>>? ? ? ? ?>>>> ??Another part of the fix is in the JDI which >>>> starts >>>> ??? >>>? ? ? ? ?using JDK >>>> ??? >>>? ? ? ? ?>>>> ??versions now instead of maintaining its own, >>>> ??? and in >>>> ??? >>>? ? ? ? ?the JDWP >>>> ??? >>>? ? ? ? ?>>>> ??agent which is using the JVMTI versions >>>> ??? instead of its >>>> ??? >>>? ? ? ? ?own. >>>> ??? >>>? ? ? ? ?>>> >>>> ??? >>>? ? ? ? ?>>> This all seems reasonable (though I'm no expert on >>>> ??? >>>? ? ? ? ?working with XSL >>>> ??? >>>? ? ? ? ?>>> etc). >>>> ??? >>>? ? ? ? ?>>> >>>> ??? >>>? ? ? ? ?>>> One thing I am unclear of is why you bother with >>>> ??? using >>>> ??? >>>? ? ? ? ?>>> VERSION_INTERIM when the actual version check >>>> ??? will only >>>> ??? >>>? ? ? ? ?consider >>>> ??? >>>? ? ? ? ?>>> VERSION_FEATURE (aka major). Couldn't you just >>>> ??? leave the >>>> ??? >>>? ? ? ? ?"minor" >>>> ??? >>>? ? ? ? ?>>> part 0 the same as the "micro" part? >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> This is right question to ask. >>>> ??? >>>? ? ? ? ?>> I was two-folded on this. >>>> ??? >>>? ? ? ? ?>> But finally decided to maintain minor version (aka >>>> ??? >>>? ? ? ? ?VERSION_INTERIM). >>>> ??? >>>? ? ? ? ?>> Then the JVMTI and debugger version will match the >>>> ??? VM and >>>> ??? >>>? ? ? ? ?JDK version >>>> ??? >>>? ? ? ? ?>> for update releases. >>>> ??? >>>? ? ? ? ?>> If understand it correctly, we are still going >>>> to have >>>> ??? >>>? ? ? ? ?major.minor >>>> ??? >>>? ? ? ? ?>> versions. >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> Not really. What we have now are things like >>>> 11.0.3 and >>>> ??? >>>? ? ? ? ?12.0.1 - only >>>> ??? >>>? ? ? ? ?> using the first and third parts. The full 4 part >>>> ??? version >>>> ??? >>>? ? ? ? ?string is: >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> >>>> ??? >>> >>>> ?$VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> and we typically only update version_feature and >>>> ??? >>>? ? ? ? ?version_update. >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> https://openjdk.java.net/jeps/322 >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?>> Also, the JVMTI GetVersionNumberspec still tells >>>> about >>>> ??? >>>? ? ? ? ?both minor and >>>> ??? >>>? ? ? ? ?>> micro versions. >>>> ??? >>>? ? ? ? ?>> It also defines special constants for >>>> ??? corresponding masks >>>> ??? >>>? ? ? ? ?and shifts: >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> ??? Version Masks >>>> ??? >>>? ? ? ? ?>> ??? Constant???? Value Description >>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 >>>> ??? >>>? ? ? ? ?Mask to >>>> ??? >>>? ? ? ? ?>> extract >>>> ??? >>>? ? ? ? ?>> ??? interface type. The value of the version >>>> ??? returned by >>>> ??? >>>? ? ? ? ?this function >>>> ??? >>>? ? ? ? ?>> ??? masked with >>>> ??? |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always >>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_INTERFACE_JVMTI| since this is a >>>> JVMTI >>>> ??? >>>? ? ? ? ?function. >>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000???? Mask to >>>> ??? >>>? ? ? ? ?extract major >>>> ??? >>>? ? ? ? ?>> ??? version number. >>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00???? Mask to >>>> ??? >>>? ? ? ? ?extract minor >>>> ??? >>>? ? ? ? ?>> ??? version number. >>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MICRO| 0x000000FF???? Mask to >>>> ??? >>>? ? ? ? ?extract micro >>>> ??? >>>? ? ? ? ?>> ??? version number. >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> ??? Version Shifts >>>> ??? >>>? ? ? ? ?>> ??? Constant???? Value Description >>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MAJOR|???? 16 Shift to >>>> ??? extract major >>>> ??? >>>? ? ? ? ?>> version number. >>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MINOR|???? 8 Shift to extract >>>> ??? minor >>>> ??? >>>? ? ? ? ?>> version number. >>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MICRO|???? 0 Shift to extract >>>> ??? micro >>>> ??? >>>? ? ? ? ?>> version number. >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> This is link to the spec: >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>> >>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber >>>> ??? >>> >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> It seems, changing (and/or deprecating) this >>>> will give >>>> ??? >>>? ? ? ? ?more problems >>>> ??? >>>? ? ? ? ?>> than benefits. >>>> ??? >>>? ? ? ? ?>> It is better to remain compatible with previous >>>> ??? releases. >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> This is a problem that was flagged when the new >>>> ??? versioning >>>> ??? >>>? ? ? ? ?scheme was >>>> ??? >>>? ? ? ? ?> introduced but I'm guessing nothing was actually >>>> ??? done about >>>> ??? >>>? ? ? ? ?it. They >>>> ??? >>>? ? ? ? ?> are not really compatible beyond the major/feature >>>> ??? part. >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> If we only update the spec version with the feature >>>> ??? version >>>> ??? >>>? ? ? ? ?then all >>>> ??? >>>? ? ? ? ?> versions will have the form N.0.0. However your >>>> changes >>>> ??? >>>? ? ? ? ?will also >>>> ??? >>>? ? ? ? ?> update if we happen to use a VERSION_INTERIM for >>>> some >>>> ??? >>>? ? ? ? ?reason - though >>>> ??? >>>? ? ? ? ?> the version check will ignore that anyway. I'm not >>>> ??? really >>>> ??? >>>? ? ? ? ?seeing the >>>> ??? >>>? ? ? ? ?> point in having that happen. >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> Maybe we do need to define a new version API that >>>> ??? maps to >>>> ??? >>>? ? ? ? ?the new >>>> ??? >>>? ? ? ? ?> versioning scheme of OpenJDK ? But if we did that >>>> we'd >>>> ??? >>>? ? ? ? ?still have to >>>> ??? >>>? ? ? ? ?> support the legacy mapping and I'd still advocate >>>> ??? simply using >>>> ??? >>>? ? ? ? ?> VERSION_FEATURE.0.0. >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> It's tricky. >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?> David >>>> ??? >>>? ? ? ? ?> ----- >>>> ??? >>>? ? ? ? ?> >>>> ??? >>>? ? ? ? ?>>> For the record I considered whether this needs >>>> a CSR >>>> ??? >>>? ? ? ? ?request and >>>> ??? >>>? ? ? ? ?>>> concluded it did not as it doesn't involve >>>> ??? changing any >>>> ??? >>>? ? ? ? ?actual >>>> ??? >>>? ? ? ? ?>>> specifications. >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> Okay, thanks. >>>> ??? >>>? ? ? ? ?>> I considered it too, made the same conclusion but >>>> ??? still >>>> ??? >>>? ? ? ? ?have some >>>> ??? >>>? ? ? ? ?>> doubt. :) >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>> Thanks! >>>> ??? >>>? ? ? ? ?>> Serguei >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>>? ? ? ? ?>>> >>>> ??? >>>? ? ? ? ?>>> Thanks, >>>> ??? >>>? ? ? ? ?>>> David >>>> ??? >>>? ? ? ? ?>>> >>>> ??? >>>? ? ? ? ?>>>> Testing: >>>> ??? >>>? ? ? ? ?>>>> ??Generated docs and jvmti.h and checked the >>>> ??? versions >>>> ??? >>>? ? ? ? ?are correct. >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>>? ? ? ? ?>>>> One could ask if we have to use same or similar >>>> ??? approach for >>>> ??? >>>? ? ? ? ?>>>> other API's and tools, like JNI, JMX and so on. >>>> ??? >>>? ? ? ? ?>>>> But these are not areas of my expertise or >>>> ??? responsibility. >>>> ??? >>>? ? ? ? ?>>>> It just feels like there is some room for >>>> ??? unification here. >>>> ??? >>>? ? ? ? ?>>>> >>>> ??? >>>? ? ? ? ?>>>> Thanks, >>>> ??? >>>? ? ? ? ?>>>> Serguei >>>> ??? >>>? ? ? ? ?>> >>>> ??? >>> >>>> ??? >>> >>>> ??? >>> >>>> ??? >>>? ? ?-- >>>> ??? >>> >>>> ??? >>>? ? ?Thanks, >>>> ??? >>>? ? ?Jc >>>> ??? >> >>>> ??? >> >>>> ??? >> >>>> ??? >> -- >>>> ??? >> >>>> ??? >> Thanks, >>>> ??? >> Jc >>>> ??? > >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc >>> >> From sakamoto.osamu at nttcom.co.jp Fri May 10 08:46:47 2019 From: sakamoto.osamu at nttcom.co.jp (=?utf-8?B?5Z2C5pysIOe1sQ==?=) Date: Fri, 10 May 2019 08:46:47 +0000 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> Message-ID: <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> Hi, I agree with Yasumasa's opinion in CSR. I wrote new debugd format and usage to match other modes(jstack, jmap and so on) in jhdsb. Certainly, usage of debugd which I proposed does not explain that and cannot be used together, but it is not limited to debugd - other modes have similar issue. I think it is helpful to detail help description in each jhsdb modes, but I'd like to separate as another issue because this is not limited to debugd. -----Original Message----- From: Yasumasa Suenaga Sent: Friday, May 10, 2019 4:08 PM To: David Holmes Cc: Jean Christophe Beyler ; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net ; ?? ? Subject: Re: debugd options should regard to jhsdb style Hi David, Thank you for checking in CSR, and sorry for my incorrect description. I added my opinion to CSR. Osamu, do you have any opinion? Yasumasa 2019?5?10?(?) 15:16 David Holmes : > > Hi Yasumasa, > > I've made some updates to the CSR request and raised a couple of issues. > > FYI the specification section only needs to contain the actual > specification for what has changed ie the new command-line options; > not the implementation that will bring about those changes. > > Thanks, > David > > On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: > > Thanks JC! > > > > I added key point of this change to specification section in CSR. > > > > > > Yasumasa > > > > 2019?5?10?(?) 12:54 Jean Christophe Beyler : > >> > >> Hi Yasumasa, > >> > >> I'm not a reviewer but the CSR looks good; I feel that the > >> specification section could use some text and then send the reader > >> to the other bug entry :) Jc > >> > >> From: Yasumasa Suenaga > >> Date: Thu, May 9, 2019 at 8:06 PM > >> To: serviceability-dev at openjdk.java.net > >> serviceability-dev at openjdk.java.net > >> > >>> tests on submit repo have been passed > >>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) > >>> > >>> Could you review the CSR? > >>> > >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > >>> > >>> > >>> Yasumasa > >>> > >>> > >>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : > >>>> > >>>> Hi, > >>>> > >>>> Osamu, your change looks good to me. > >>>> I will sponsor you. > >>>> > >>>> David, I filed this issue and requested to CSR: > >>>> > >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 > >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > >>>> > >>>> I uploaded webrev. I will push it to submit repo. > >>>> > >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ > >>>> > >>>> > >>>> Thanks, > >>>> > >>>> Yasumasa > >>>> > >>>> > >>>> On 2019/05/10 7:30, David Holmes wrote: > >>>>> Hi, > >>>>> > >>>>> This will need a bug filed and a corresponding CSR request. I > >>>>> suspect that historically the form of this command was done to match other tools. > >>>>> > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>> On 9/05/2019 6:33 pm, ?? ? wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> I want to use `jhsdb debugd` on my laptop. > >>>>>> However debugd mode has different options from other modes. > >>>>>> I think debugd should have same options like other modes. > >>>>>> > >>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. > >>>>>> Also I added `--serverid` option for serverid. > >>>>>> > >>>>>> I attached a patch for this enhancement. > >>>>>> This patch passes serviceability/sa jtreg tests. > >>>>>> > >>>>>> Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . > >>>>>> However it has been disabled by JDK-8163805. > >>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. > >>>>>> > >>>>>> Could you help? I want to contribute it. I need a sponsor. > >>>>>> (My company has signed to OCA (NTT Comware Corporation)) > >>>>>> > >>>>>> Thanks, > >>>>>> > >>>>>> Osamu > >>>>>> > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc From serguei.spitsyn at oracle.com Fri May 10 09:16:12 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 May 2019 02:16:12 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 10 18:17:41 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 May 2019 11:17:41 -0700 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> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> Message-ID: <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> Dear Lin, Sorry for the late reply. I've edited the CSR a little bit to fix some incorrect spots. Now, a couple of spots are not clear to me. > - incremental[:], enable the incremental dump of heap, dumped >?? data will be saved to, by default it is "IncrementalHisto.dump" ?Q1: Should the be full path or short name? ?? ? Is there any default path? What is the path of the "IncrementalHisto.dump" file? > - chunksize=, size of objects (in KB) will be dumped in one chunk. ?Q2: Should it be chunk of dump, not chunk of objects? > - maxfilesize=, size of the incremental data dump file (in KB), when data size >?? is larger than maxfilesize, the file is erased and latest data will be written. ?Q3: What is a relation and limitations between chunksize and maxfilesize? ???? Should the maxfilesize be multiple of the chunksize? ?Q4: The sentence "the file is erased and latest data will be written" is not clear enough. ???? Why the whole file needs to be erased ???? Should the incremental file behave like a cyclic buffer? ???? If so, then only next chunk needs to be erased. ???? Then the chunks need to be numbered in order, so the earliest one can be found. ???? (I do not want you to accept my suggestions right away. It is just a discussion point. ????? You need to prove that your approach is good and clean enough.) If we resolve the questions (or get into agreement) then I'll update the CSR as needed. Thanks, Serguei On 5/5/19 00:34, ?? wrote: > Dear All, > I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8222319 > May I ask your help to review it? > When it is finalized, I will refine the webrev. > > BRs, > Lin > >> Dear Serguei? >> Thanks a lot for your reviewing. >> >> >> >>> System.err.println(" incremental dump support:"); >>> + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); >>> + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); >>> >>> >>> From this description is not clear at all what does the chunkcount mean. >>> Is it to define how many heap objects are dumped in one chunk? >>> If so, would it better to name it chunksize instead where chunksize is measured in heap objects? >>> Then would it better to use the same units to define the maxfilesize as well? >>> (I'm not insisting on this, just asking.) >> The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. >> For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and >> when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. >> >> The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. >> Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. >> BRs, >> Lin From chris.plummer at oracle.com Fri May 10 18:43:28 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 10 May 2019 11:43:28 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 10 18:44:38 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 May 2019 11:44:38 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri May 10 19:02:37 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 10 May 2019 12:02:37 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> Message-ID: Hi Serguei, Looks good to me too :) Jc *From: *serguei.spitsyn at oracle.com *Date: *Fri, May 10, 2019 at 11:44 AM *To: *Chris Plummer, David Holmes, Jean Christophe Beyler *Cc: *serviceability-dev Thanks a lot, Chris! > Serguei > > > On 5/10/19 11:43, Chris Plummer wrote: > > Hi Serguei, > > I won't pretend to understand your xsl changes for lastchangeversion, but > it seems to be producing the proper result. I've re-looked at all the other > changes too, and looks good to me. > > thanks, > > Chris > > On 5/10/19 2:16 AM, serguei.spitsyn at oracle.com wrote: > > Hi David, > > I've noticed a minor problem in the jvmti.html diff below: > > 5c5 > < JVM(TM) Tool Interface 11.0.0 > --- > > JVM(TM) Tool Interface 13.0.0 > 30c30 > <

Version 11.0

> --- > >

Version 13.0

> 34931c34931 > < Version: 11.0.0 > --- > > Version: 13.0.0 > > > There should not be the last difference as this is the version of last > JVMTI spec update: > > *11.0.0* > 7 February 2018 Minor update for new class file NestHost and NestMembers > attributes: - Specify that RedefineClasses and RetransformClasses are not > allowed to change the class file NestHost and NestMembers attributes. - Add > new error JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED that > can be returned by RedefineClasses and RetransformClasses. > > I've updated the webrev: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ > > The newly updated file is: > src/hotspot/share/prims/jvmti.xml > > which has this change: > > ++ + + + + ++ > >
>
>

Change History

> Last update:
- Version: + Version: > > > New jvmti.html diff is: > 5c5 > < JVM(TM) Tool Interface 11.0.0 > --- > > JVM(TM) Tool Interface 13.0.0 > 30c30 > <

Version 11.0

> --- > >

Version 13.0

> > > Thanks, > Serguei > > > On 5/10/19 01:03, serguei.spitsyn at oracle.com wrote: > > Hi David, > > > On 5/9/19 18:51, David Holmes wrote: > > Hi Serguei, > > On 10/05/2019 10:32 am, serguei.spitsyn at oracle.com wrote: > > I've updated the webrev v2 in place. > > > make/hotspot/gensrc/GensrcJvmti.gmk > > You don't need to pass through: -PARAM minorversion $(VERSION_INTERIM) > > > Good catch. > How did I missed to remove? > > > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java > > 57 private static final int minorVersion = > Runtime.version().interim(); > > That should be kept at 0. > > > Okay, fixed. > > New webrev is: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ > > > > I'd like to see an actual diff of the generated jvmti.h and jvmti.html > files as well please. Some of the XSL stuff looks odd to me. > > > The jvmti.h diff: > > 2c2 > < * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights > reserved. > --- > > * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights > reserved. > 47c47 > < JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 /* > version: 11.0.0 */ > --- > > JVMTI_VERSION = 0x30000000 + (13 * 0x10000) + ( 0 * 0x100) + 0 /* > version: 13.0.0 */ > > > > The jvmti.html diff: > > 5c5 > < JVM(TM) Tool Interface 11.0.0 > --- > > JVM(TM) Tool Interface 13.0.0 > 30c30 > <

Version 11.0

> --- > >

Version 13.0

> 34931c34931 > < Version: 11.0.0 > --- > > Version: 13.0.0 > > > > Thanks, > Serguei > > > Thanks, > David > > Thanks, > Serguei > > > On 5/9/19 17:28, serguei.spitsyn at oracle.com wrote: > > David and Jc, > > Okay, I'll remove this line now. > Thank you for your comments. > > Let's let Jc to file a separate enhancement on this. > Then I'll file a CSR and prepare a fix. > > I hope, you both are Okay with the rest. > > Thanks! > Serguei > > > On 5/9/19 17:17, Jean Christophe Beyler wrote: > > Hi Serguei, > > Adding to the difficulties that David is exposing, this won't work. You > need to redo the xls definition because you need the #define to be the > numeric value directly and not the enum; otherwise it won't work in any > usable way at preprocessor time sadly. > > I think it makes sense to just do what you were planning to do here > without this and I'll file a bug and work out the CSR path and review path > separately and see what is do-able or not then because I think it's too > much work now "just for this now" if that makes sense :) > Jc > > *From: *David Holmes > > *Date: *Thu, May 9, 2019 at 5:11 PM > *To: *serguei.spitsyn at oracle.com > , Jean Christophe Beyler > *Cc: *serviceability-dev > > On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com > > wrote: > > Hi Jc, > > > > Okay, you convinced me - thanks! > > Added new line into the generated jvmti.h: > > > > #define JVMTI_VERSION_LATEST JVMTI_VERSION > > That requires a CSR as you are expanding the exported interface. > > Also you need > > #define JVMTI_VERSION_LATEST (JVMTI_VERSION) > > as JVMTI_VERSION is itself an expression not a constant. That might > limit the utility of having such a define as you won't be able to > use it > in an ifdef guard to test a value AFAICS. > > David > > > I hope, it will help in your case. > > > > > > Updated webrev version is: > > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ > > > > > > This version includes suggestions from David. > > > > Thanks, > > Serguei > > > > > > > > On 5/9/19 14:17, Jean Christophe Beyler wrote: > >> Hi Serguei, > >> > >> Of course I can :) > >> > >> Consider, just randomly of course, the heap sampling work that > got > >> added to JVMTI. Now imagine you'd want to test if it is > supported by a > >> given JVMTI version, you would write something like this: > >> > >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { > >> jvmtiCapabilities caps; > >> memset(&caps, 0, sizeof(caps)); > >> if (jvmti->GetPotentialCapabilities(&caps) != > JVMTI_ERROR_NONE) { > >> LOG(WARNING) << "Failed to get potential capabilities, > disabling > >> the heap " > >> << "sampling monitor"; > >> return false; > >> } > >> > >> return caps.can_generate_sampled_object_alloc_events > >> && caps.can_generate_garbage_collection_events; > >> } > >> > >> Now, the problem is that this code cannot be used if you > compile with > >> an older JDK such as JDK8 for example > >> because can_generate_sampled_object_alloc_events does not > exist yet > >> for that jvmti.h file. > >> > >> > >> In a perfect world, we might imagine that we are always > compiling with > >> the latest JVMTI headers but that is not always true and, > therefore, > >> to have the code portable, we now have to do: > >> > >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { > >> #ifdef ENABLE_HEAP_SAMPLING > >> jvmtiCapabilities caps; > >> memset(&caps, 0, sizeof(caps)); > >> if (jvmti->GetPotentialCapabilities(&caps) != > JVMTI_ERROR_NONE) { > >> LOG(WARNING) << "Failed to get potential capabilities, > disabling > >> the heap " > >> << "sampling monitor"; > >> return false; > >> } > >> > >> return caps.can_generate_sampled_object_alloc_events > >> && caps.can_generate_garbage_collection_events; > >> #else > >> return false; > >> #endif > >> } > >> > >> Where ENABLE_HEAP_SAMPLING is defined if we did compile with > JDK11 and > >> not defined if we compiled with JDK8. I can't use JVMTI_VERSION > >> because I can't use it in an #if because it is not an enum. > Were it to > >> be a #define or were I to have a #define I could use with a > version > >> number being bumped up, I could write something such as: > >> > >> #ifdef JVMTI_VERSION_11 > >> > >> or something that looks in the value of the JVMTI_VERSION if I > wanted. > >> Right now, I can't even do that! > >> > >> Hopefully this helps understand what I am talking about :-), > >> Jc > >> > >> > >> > >> > >> On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com > > >> > > < > serguei.spitsyn at oracle.com > > >> > >> > wrote: > >> > >> Hi Jc, > >> > >> Thank you a lot for review! > >> Some replies below. > >> > >> > >> On 5/9/19 09:10, Jean Christophe Beyler wrote: > >>> Hi Serguei, > >>> > >>> FWIW, the change looks good and I think it's a good idea > to do. > >>> However, there is one thorn in our internal agent code is > that > >>> the JVMTI_VERSION is in an enum. This makes us unable to > #if it > >>> when adding usages of newer features/methods. > >>> > >>> This probably could/should be a different webrev (which I > can do > >>> if you like) but is there any way while you are changing this > >>> that the enum for JVMTI_VERSION could become a set of > #define? > >>> > >>> So instead of: > >>> enum { > >>> JVMTI_VERSION_1 = 0x30010000, > >>> JVMTI_VERSION_1_0 = 0x30010000, > >>> JVMTI_VERSION_1_1 = 0x30010100, > >>> JVMTI_VERSION_1_2 = 0x30010200, > >>> JVMTI_VERSION_9 = 0x30090000, > >>> JVMTI_VERSION_11 = 0x300B0000, > >>> > >>> JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * > 0x100) + > >>> 0 /* version: 11.0.0 */ > >>> }; > >>> > >>> We would get: > >>> #define JVMTI_VERSION_1 0x30010000 > >>> #define JVMTI_VERSION_1_0 0x30010000 > >>> #define JVMTI_VERSION_1_1 = 0x30010100 > >>> #define JVMTI_VERSION_1_2 = 0x30010200 > >>> #define JVMTI_VERSION_9 = 0x30090000 > >>> #define JVMTI_VERSION_11 = 0x300B0000 > >>> #define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + (0 * > 0x100) > >>> + 0 /* version: 11.0.0 */) > >> > >> It is interesting concern and suggestion. > >> I'm not sure if it requires a CSR. > >> > >> > >>> I actually don't care about any define of these except for > >>> JVMTI_VERSION; basically it would be useful so that in > our agent > >>> code we can test the JVMTI_VERSION with #if macros to > protect the > >>> code when new elements show up in future versions. So it also > >>> could be: > >>> enum { > >>> JVMTI_VERSION_1 = 0x30010000, > >>> JVMTI_VERSION_1_0 = 0x30010000, > >>> JVMTI_VERSION_1_1 = 0x30010100, > >>> JVMTI_VERSION_1_2 = 0x30010200, > >>> JVMTI_VERSION_9 = 0x30090000, > >>> JVMTI_VERSION_11 = 0x300B0000, > >>> > >>> JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * > 0x100) + > >>> 0 /* version: 11.0.0 */ > >>> }; > >>> > >>> #define JVMTI_LATEST_VERSION (0x30000000 + (11 * 0x10000) > + (0 * > >>> 0x100) + 0 /* version: 11.0.0 */) > >> > >> I is not a problem to implement this one. > >> But I'm not sure how does this really help in your case. > >> I do not see a point to test the JVMTI_VERSION with #if as > it is > >> always defined. > >> Could you, please, elaborate a little bit more? > >> > >> Thanks, > >> Serguei > >> > >>> Right now, I have to do weird things where I detect the > jvmti.h > >>> used at compile time to then do -DUSING_JDK11 for the > agent at > >>> compile time. > >>> > >>> Thanks! > >>> Jc > >>> > >>> > >>> > >>> > >>> On Thu, May 9, 2019 at 8:48 AM serguei.spitsyn at oracle.com > > >>> > > < > serguei.spitsyn at oracle.com > > >>> > >> > wrote: > >>> > >>> I'll try to get rid of VERSION_INTERIM. > >>> Always using just VERSION_FEATURE.0.0 should not > create problems > >>> if we do not change JVMTI spec in VERSION_UPDATE. > >>> I do not see why we would change the JVMTI spec in update > >>> releases. > >>> But if we do then using VERSION_UPDATE as > microversion would > >>> be good enough. > >>> > >>> Thanks! > >>> Serguei > >>> > >>> > >>> On 5/9/19 06:13, David Holmes wrote: > >>> > Hi Serguei, > >>> > > >>> > On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com > > >>> > > > wrote: > >>> >> Hi David, > >>> >> > >>> >> Thank you a lot for review! > >>> >> There are some replies below. > >>> >> > >>> >> > >>> >> On 5/8/19 18:42, David Holmes wrote: > >>> >>> Hi Serguei, > >>> >>> > >>> >>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com > > >>> > ?? > > wrote: > >>> >>>> Please, review a fix for the task: > >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8219023 > >>> >>>> > >>> >>>> Webrev: > >>> >>>> > >>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ > >>> > >>> >>>> > >>> >>>> > >>> >>>> Summary: > >>> >>>> > >>> >>>> By design as we have never bumped the JVMTI > version unless > >>> >>>> there were spec changes for that release. Now > we want > >>> to sync > >>> >>>> the JVMTI version with the JDK version > regardless of > >>> whether > >>> >>>> or not spec changes have occurred in that release. > >>> >>>> Also, we want it automatically set by the > build system > >>> so that > >>> >>>> no manual updates are needed for each release. > >>> >>>> > >>> >>>> The jvmti.h and jvmti.html (JVMTI spec) are > generated from > >>> >>>> the jvmti.xsl with the XSLT scripts now. So, > the fix > >>> removes > >>> >>>> hard coded major, minor and micro versions > from the > >>> jvmti.xml > >>> >>>> and passes major and minor parameters with the > -PARAMETER > >>> >>>> to the XSL transformation. > >>> >>>> > >>> >>>> Another part of the fix is in the JDI which starts > >>> using JDK > >>> >>>> versions now instead of maintaining its own, > and in > >>> the JDWP > >>> >>>> agent which is using the JVMTI versions > instead of its > >>> own. > >>> >>> > >>> >>> This all seems reasonable (though I'm no expert on > >>> working with XSL > >>> >>> etc). > >>> >>> > >>> >>> One thing I am unclear of is why you bother with > using > >>> >>> VERSION_INTERIM when the actual version check > will only > >>> consider > >>> >>> VERSION_FEATURE (aka major). Couldn't you just > leave the > >>> "minor" > >>> >>> part 0 the same as the "micro" part? > >>> >> > >>> >> This is right question to ask. > >>> >> I was two-folded on this. > >>> >> But finally decided to maintain minor version (aka > >>> VERSION_INTERIM). > >>> >> Then the JVMTI and debugger version will match the > VM and > >>> JDK version > >>> >> for update releases. > >>> >> If understand it correctly, we are still going to have > >>> major.minor > >>> >> versions. > >>> > > >>> > Not really. What we have now are things like 11.0.3 and > >>> 12.0.1 - only > >>> > using the first and third parts. The full 4 part > version > >>> string is: > >>> > > >>> > > >>> $VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH > >>> > > >>> > and we typically only update version_feature and > >>> version_update. > >>> > > >>> > https://openjdk.java.net/jeps/322 > >>> > > >>> >> Also, the JVMTI GetVersionNumberspec still tells about > >>> both minor and > >>> >> micro versions. > >>> >> It also defines special constants for > corresponding masks > >>> and shifts: > >>> >> > >>> >> Version Masks > >>> >> Constant Value Description > >>> >> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 > >>> Mask to > >>> >> extract > >>> >> interface type. The value of the version > returned by > >>> this function > >>> >> masked with > |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always > >>> >> |JVMTI_VERSION_INTERFACE_JVMTI| since this is a JVMTI > >>> function. > >>> >> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000 Mask to > >>> extract major > >>> >> version number. > >>> >> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00 Mask to > >>> extract minor > >>> >> version number. > >>> >> |JVMTI_VERSION_MASK_MICRO| 0x000000FF Mask to > >>> extract micro > >>> >> version number. > >>> >> > >>> >> Version Shifts > >>> >> Constant Value Description > >>> >> |JVMTI_VERSION_SHIFT_MAJOR| 16 Shift to > extract major > >>> >> version number. > >>> >> |JVMTI_VERSION_SHIFT_MINOR| 8 Shift to extract > minor > >>> >> version number. > >>> >> |JVMTI_VERSION_SHIFT_MICRO| 0 Shift to extract > micro > >>> >> version number. > >>> >> > >>> >> > >>> >> This is link to the spec: > >>> >> > >>> > > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber > >>> > >>> >> > >>> >> > >>> >> It seems, changing (and/or deprecating) this will give > >>> more problems > >>> >> than benefits. > >>> >> It is better to remain compatible with previous > releases. > >>> > > >>> > This is a problem that was flagged when the new > versioning > >>> scheme was > >>> > introduced but I'm guessing nothing was actually > done about > >>> it. They > >>> > are not really compatible beyond the major/feature > part. > >>> > > >>> > If we only update the spec version with the feature > version > >>> then all > >>> > versions will have the form N.0.0. However your changes > >>> will also > >>> > update if we happen to use a VERSION_INTERIM for some > >>> reason - though > >>> > the version check will ignore that anyway. I'm not > really > >>> seeing the > >>> > point in having that happen. > >>> > > >>> > Maybe we do need to define a new version API that > maps to > >>> the new > >>> > versioning scheme of OpenJDK ? But if we did that we'd > >>> still have to > >>> > support the legacy mapping and I'd still advocate > simply using > >>> > VERSION_FEATURE.0.0. > >>> > > >>> > It's tricky. > >>> > > >>> > David > >>> > ----- > >>> > > >>> >>> For the record I considered whether this needs a CSR > >>> request and > >>> >>> concluded it did not as it doesn't involve > changing any > >>> actual > >>> >>> specifications. > >>> >> > >>> >> Okay, thanks. > >>> >> I considered it too, made the same conclusion but > still > >>> have some > >>> >> doubt. :) > >>> >> > >>> >> Thanks! > >>> >> Serguei > >>> >> > >>> >>> > >>> >>> Thanks, > >>> >>> David > >>> >>> > >>> >>>> Testing: > >>> >>>> Generated docs and jvmti.h and checked the > versions > >>> are correct. > >>> >>>> > >>> >>>> One could ask if we have to use same or similar > approach for > >>> >>>> other API's and tools, like JNI, JMX and so on. > >>> >>>> But these are not areas of my expertise or > responsibility. > >>> >>>> It just feels like there is some room for > unification here. > >>> >>>> > >>> >>>> Thanks, > >>> >>>> Serguei > >>> >> > >>> > >>> > >>> > >>> -- > >>> > >>> Thanks, > >>> Jc > >> > >> > >> > >> -- > >> > >> Thanks, > >> Jc > > > > > > -- > > Thanks, > Jc > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 10 19:04:25 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 10 May 2019 12:04:25 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> Message-ID: <9982df23-b415-dcf1-9b97-48beb788835d@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Sat May 11 02:10:27 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Fri, 10 May 2019 19:10:27 -0700 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null Message-ID: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> Please review the change that fixes an intermittent failure of the test. The tests checks the implementation of the com.sun.tools.jdi.ClassLoaderReference class. The problem here is that while com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() iterates over all loaded classes to retrieve a classloader and compares it to the current one, some of the classes might become unloaded and garbage collected (e.g. org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this happens then the attempt to retrieve a classloader for the collected class results in com.sun.jdi.ObjectCollectedException being thrown. The fix catches this com.sun.jdi.ObjectCollectedException and continues iterating over the rest of the classes. Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 Thanks! --Daniil From jcbeyler at google.com Sat May 11 02:20:30 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 10 May 2019 19:20:30 -0700 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> Message-ID: Hi Daniil, Looks good to me :) Jc *From: *Daniil Titov *Date: *Fri, May 10, 2019 at 7:11 PM *To: *OpenJDK Serviceability Please review the change that fixes an intermittent failure of the test. > > The tests checks the implementation of the > com.sun.tools.jdi.ClassLoaderReference class. The problem here is that > while com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() iterates > over all loaded classes to retrieve a classloader and compares it to the > current one, some of the classes might become unloaded and garbage > collected (e.g. org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 > or jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > happens then the attempt to retrieve a classloader for the collected class > results in com.sun.jdi.ObjectCollectedException being thrown. > > The fix catches this com.sun.jdi.ObjectCollectedException and continues > iterating over the rest of the classes. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > Thanks! > --Daniil > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat May 11 03:59:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 May 2019 13:59:19 +1000 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> Message-ID: <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> Hi Daniil, On 11/05/2019 12:10 pm, Daniil Titov wrote: > Please review the change that fixes an intermittent failure of the test. > > The tests checks the implementation of the com.sun.tools.jdi.ClassLoaderReference class. The problem here is that while com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() iterates over all loaded classes to retrieve a classloader and compares it to the current one, some of the classes might become unloaded and garbage collected (e.g. org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this happens then the attempt to retrieve a classloader for the collected class results in com.sun.jdi.ObjectCollectedException being thrown. That seems odd to me. If you have a reference to the Class then it can't be unloaded. I would not expect allClasses() to have weak-references, so a class should not be unloadable while you are examining it. Unless it is finding VM anonymous classes (which it should not!). David ----- > The fix catches this com.sun.jdi.ObjectCollectedException and continues iterating over the rest of the classes. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > Thanks! > --Daniil > > From chris.plummer at oracle.com Sat May 11 04:03:47 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 10 May 2019 21:03:47 -0700 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> Message-ID: On 5/10/19 8:59 PM, David Holmes wrote: > Hi Daniil, > > On 11/05/2019 12:10 pm, Daniil Titov wrote: >> Please review the change that fixes an intermittent failure of the test. >> >> The tests checks the implementation of? the >> com.sun.tools.jdi.ClassLoaderReference class. The problem here is >> that while >> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() iterates >> over all loaded classes to retrieve a classloader and compares it to >> the current one, some of the classes might become unloaded and >> garbage collected (e.g. >> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or >> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this >> happens then the attempt to retrieve a classloader for the collected >> class results in com.sun.jdi.ObjectCollectedException being thrown. > > That seems odd to me. If you have a reference to the Class then it > can't be unloaded. I would not expect allClasses() to have > weak-references, so a class should not be unloadable while you are > examining it. Unless it is finding VM anonymous classes (which it > should not!). > I was just typing up something similar. Shouldn't the test do a vm.suspend() and then call disableCollection() on each class returned by vm.allClasses()? Chris > David > ----- > >> The fix catches this com.sun.jdi.ObjectCollectedException and >> continues iterating over the rest of the classes. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 >> >> Thanks! >> --Daniil >> >> From chris.plummer at oracle.com Sat May 11 04:06:37 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 10 May 2019 21:06:37 -0700 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> Message-ID: On 5/10/19 9:03 PM, Chris Plummer wrote: > On 5/10/19 8:59 PM, David Holmes wrote: >> Hi Daniil, >> >> On 11/05/2019 12:10 pm, Daniil Titov wrote: >>> Please review the change that fixes an intermittent failure of the >>> test. >>> >>> The tests checks the implementation of? the >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is >>> that while >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() iterates >>> over all loaded classes to retrieve a classloader and compares it to >>> the current one, some of the classes might become unloaded and >>> garbage collected (e.g. >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this >>> happens then the attempt to retrieve a classloader for the collected >>> class results in com.sun.jdi.ObjectCollectedException being thrown. >> >> That seems odd to me. If you have a reference to the Class then it >> can't be unloaded. I would not expect allClasses() to have >> weak-references, so a class should not be unloadable while you are >> examining it. Unless it is finding VM anonymous classes (which it >> should not!). >> > I was just typing up something similar. Shouldn't the test do a > vm.suspend() and then call disableCollection() on each class returned > by vm.allClasses()? Oh wait, this isn't a test. It's part of JDI. I guess it would be up to the user of ClassLoaderReference.definedClasses() to do the suspend. In fact I'm not sure there's much purpose in calling ClassLoaderReference.definedClasses() without suspending first. Even with your changes, the list returned can end up with references to unloaded classes. Chris > > Chris >> David >> ----- >> >>> The fix catches this com.sun.jdi.ObjectCollectedException and >>> continues iterating over the rest of the classes. >>> >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 >>> >>> Thanks! >>> --Daniil >>> >>> > > From jcbeyler at google.com Sat May 11 04:14:43 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 10 May 2019 21:14:43 -0700 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> Message-ID: Isn't that the point? The list returned could have unloaded classes and we can catch it via this exception (from the comment above the ReferenceType interface): * Any method on ReferenceType or which directly or indirectly takes * ReferenceType as parameter may throw * {@link ObjectCollectedException} if the mirrored type has been unloaded. Turns out that even in the definedClasses, we can get that exception so we should check for it while walking the reference types as well? Jc *From: *Chris Plummer *Date: *Fri, May 10, 2019 at 9:09 PM *To: *David Holmes, Daniil Titov, OpenJDK Serviceability On 5/10/19 9:03 PM, Chris Plummer wrote: > > On 5/10/19 8:59 PM, David Holmes wrote: > >> Hi Daniil, > >> > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > >>> Please review the change that fixes an intermittent failure of the > >>> test. > >>> > >>> The tests checks the implementation of the > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > >>> that while > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() iterates > >>> over all loaded classes to retrieve a classloader and compares it to > >>> the current one, some of the classes might become unloaded and > >>> garbage collected (e.g. > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > >>> happens then the attempt to retrieve a classloader for the collected > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > >> > >> That seems odd to me. If you have a reference to the Class then it > >> can't be unloaded. I would not expect allClasses() to have > >> weak-references, so a class should not be unloadable while you are > >> examining it. Unless it is finding VM anonymous classes (which it > >> should not!). > >> > > I was just typing up something similar. Shouldn't the test do a > > vm.suspend() and then call disableCollection() on each class returned > > by vm.allClasses()? > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > the user of ClassLoaderReference.definedClasses() to do the suspend. In > fact I'm not sure there's much purpose in calling > ClassLoaderReference.definedClasses() without suspending first. Even > with your changes, the list returned can end up with references to > unloaded classes. > > Chris > > > > Chris > >> David > >> ----- > >> > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > >>> continues iterating over the rest of the classes. > >>> > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > >>> > >>> Thanks! > >>> --Daniil > >>> > >>> > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat May 11 04:34:13 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 10 May 2019 21:34:13 -0700 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Sat May 11 10:39:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 11 May 2019 20:39:36 +1000 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> Message-ID: On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > Isn't that the point? The list returned could have unloaded classes? and > we can catch it via this exception (from the comment above > the?ReferenceType interface): > > ?* Any method on ReferenceType or which directly or > indirectly takes > ?* ReferenceType as parameter may throw > ?* {@link ObjectCollectedException} if the mirrored type has been unloaded. > > Turns out that even in the definedClasses, we can get that exception so > we should check for it while walking the reference types as well? I understand that the list returned to the "debugger" process may contain ReferenceTypes for types that have actually been unloaded by the time it queries them (unless the debuggee is suspended of course). But I don't see how we can encounter those types while compiling the list in the debuggee in the first place. Something seems amiss here ... possibly just my understanding ... David > Jc > > *From: *Chris Plummer > > *Date: *Fri, May 10, 2019 at 9:09 PM > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > On 5/10/19 8:59 PM, David Holmes wrote: > >> Hi Daniil, > >> > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > >>> Please review the change that fixes an intermittent failure of the > >>> test. > >>> > >>> The tests checks the implementation of? the > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > >>> that while > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > iterates > >>> over all loaded classes to retrieve a classloader and compares > it to > >>> the current one, some of the classes might become unloaded and > >>> garbage collected (e.g. > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > >>> happens then the attempt to retrieve a classloader for the > collected > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > >> > >> That seems odd to me. If you have a reference to the Class then it > >> can't be unloaded. I would not expect allClasses() to have > >> weak-references, so a class should not be unloadable while you are > >> examining it. Unless it is finding VM anonymous classes (which it > >> should not!). > >> > > I was just typing up something similar. Shouldn't the test do a > > vm.suspend() and then call disableCollection() on each class > returned > > by vm.allClasses()? > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > the user of ClassLoaderReference.definedClasses() to do the suspend. In > fact I'm not sure there's much purpose in calling > ClassLoaderReference.definedClasses() without suspending first. Even > with your changes, the list returned can end up with references to > unloaded classes. > > Chris > > > > Chris > >> David > >> ----- > >> > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > >>> continues iterating over the rest of the classes. > >>> > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > >>> > >>> Thanks! > >>> --Daniil > >>> > >>> > > > > > > > > > -- > > Thanks, > Jc From chris.hegarty at oracle.com Sat May 11 10:39:42 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 11 May 2019 11:39:42 +0100 Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com> Message-ID: <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com> > On 7 May 2019, at 19:40, serguei.spitsyn at oracle.com wrote: > > Hi guys, > > We need a couple of partial reviews for this enhancement: > > - From the net-dev to check IPv6-addresses related part. > It does not need to be a thorough review. > We need another pair of eyes to check for obvious typos or misses. > Included Chris H. to mailing list in hope for some assistance. > (Chris, we need some help to find one of the IPv6 experts.) > > - From the serviceability-dev to check if compatibility > is not broken and nothing is missed. > This includes part of code that is not directly involved > into manipulations with the IPv4/IPv6 addresses. > The related spec update is tracked by a sub-task: > https://bugs.openjdk.java.net/browse/JDK-8221707 > > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223104 > > The latest webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c 223 if (domain == AF_INET6) { 224 int off = 0; 225 // make the socket a dual mode socket 226 setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&off, sizeof(off)); 227 } 228 } This code is fine, but maybe you want to expand the comment to mention that the setsockopt may fail if IPv4 is not supported. And that?s OK. I cannot find a similar setting of IPV6_V6ONLY for the unix equivalent. Why not, or where can it be found? src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c There is a lot of native code here, I skimmed over it, seems reasonable. There is an obvious lack of any reference to IPv6 scopes. Can the address given to bind be an IPv6 link-local? If so, then the scope will need to be parsed / set appropriately. ( seems that the new test skips all scoped addresses? ) -Chris. From daniel.daugherty at oracle.com Sat May 11 13:11:23 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 11 May 2019 09:11:23 -0400 Subject: RFR: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> Message-ID: <7efcf24b-8467-9352-6c51-05f43a3f5a82@oracle.com> On 5/11/19 6:39 AM, David Holmes wrote: > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: >> Isn't that the point? The list returned could have unloaded classes? >> and we can catch it via this exception (from the comment above >> the?ReferenceType interface): >> >> ??* Any method on ReferenceType or which directly or >> indirectly takes >> ??* ReferenceType as parameter may throw >> ??* {@link ObjectCollectedException} if the mirrored type has been >> unloaded. >> >> Turns out that even in the definedClasses, we can get that exception >> so we should check for it while walking the reference types as well? > > I understand that the list returned to the "debugger" process may > contain ReferenceTypes for types that have actually been unloaded by > the time it queries them (unless the debuggee is suspended of course). > But I don't see how we can encounter those types while compiling the > list in the debuggee in the first place. > > Something seems amiss here ... possibly just my understanding ... JC quoted the right bits of spec: > ?* Any method on ReferenceType or which directly or > indirectly takes > ?* ReferenceType as parameter may throw > ?* {@link ObjectCollectedException} if the mirrored type has been > unloaded. The JDI client is working with mirrored type references. The debuggee has the real type references. If the JDI client has not suspended the debuggee, then the JDI client must guard against ObjectCollectedException. At one point, we talked about keeping a reference (global JNI handle) in the debuggee agent, but we quickly came to the conclusion that we would never know when it would be safe to release those references. Dan > > David > >> Jc >> >> *From: *Chris Plummer > > >> *Date: *Fri, May 10, 2019 at 9:09 PM >> *To: *David Holmes, Daniil Titov, OpenJDK Serviceability >> >> ??? On 5/10/19 9:03 PM, Chris Plummer wrote: >> ???? > On 5/10/19 8:59 PM, David Holmes wrote: >> ???? >> Hi Daniil, >> ???? >> >> ???? >> On 11/05/2019 12:10 pm, Daniil Titov wrote: >> ???? >>> Please review the change that fixes an intermittent failure >> of the >> ???? >>> test. >> ???? >>> >> ???? >>> The tests checks the implementation of? the >> ???? >>> com.sun.tools.jdi.ClassLoaderReference class. The problem >> here is >> ???? >>> that while >> ???? >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() >> ??? iterates >> ???? >>> over all loaded classes to retrieve a classloader and compares >> ??? it to >> ???? >>> the current one, some of the classes might become unloaded and >> ???? >>> garbage collected (e.g. >> ???? >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or >> ???? >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). >> If this >> ???? >>> happens then the attempt to retrieve a classloader for the >> ??? collected >> ???? >>> class results in com.sun.jdi.ObjectCollectedException being >> thrown. >> ???? >> >> ???? >> That seems odd to me. If you have a reference to the Class >> then it >> ???? >> can't be unloaded. I would not expect allClasses() to have >> ???? >> weak-references, so a class should not be unloadable while >> you are >> ???? >> examining it. Unless it is finding VM anonymous classes >> (which it >> ???? >> should not!). >> ???? >> >> ???? > I was just typing up something similar. Shouldn't the test do a >> ???? > vm.suspend() and then call disableCollection() on each class >> ??? returned >> ???? > by vm.allClasses()? >> ??? Oh wait, this isn't a test. It's part of JDI. I guess it would be >> up to >> ??? the user of ClassLoaderReference.definedClasses() to do the >> suspend. In >> ??? fact I'm not sure there's much purpose in calling >> ??? ClassLoaderReference.definedClasses() without suspending first. Even >> ??? with your changes, the list returned can end up with references to >> ??? unloaded classes. >> >> ??? Chris >> ???? > >> ???? > Chris >> ???? >> David >> ???? >> ----- >> ???? >> >> ???? >>> The fix catches this com.sun.jdi.ObjectCollectedException and >> ???? >>> continues iterating over the rest of the classes. >> ???? >>> >> ???? >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 >> ???? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 >> ???? >>> >> ???? >>> Thanks! >> ???? >>> --Daniil >> ???? >>> >> ???? >>> >> ???? > >> ???? > >> >> >> >> >> -- >> >> Thanks, >> Jc > From daniil.x.titov at oracle.com Sat May 11 17:14:22 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Sat, 11 May 2019 10:14:22 -0700 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> Message-ID: <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> Hi David, There are two ways how these reference types (for the classes that become unloaded later) could appear in the collection com.sun.tools.jdi.VirtualMachineImpl maintains and stores in VirtualMachineImpl.typesBySignature instance variable: 1) Initial load when all classes are requested from the debuggee 2) Or added later when ClassPrepare event for a specific class is posted and handled The reference types are removed from VirtualMachineImpl.typesBySignature when ClassUnload event is processed. However, additional tracing showed ( pleases see below the sample output) that in some cases these ClassUnload events are received after we entered definedClasses() method and started iterating over the copy of the collection of the classes returned by vm.allClasses() method. Based on the output below it seems as all unloaded classes are the generated ones or lambda forms. --> debugger: ......getting: List definedClasses = clRef.definedClasses(); Received Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; Handled Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; Exception while getting classloader for type jdk.internal.reflect.GeneratedConstructorAccessor1 # ERROR: ##> debugger: ERROR: Exception : com.sun.jdi.ObjectCollectedException Thanks! --Daniil ?On 5/11/19, 3:39 AM, "David Holmes" wrote: On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > Isn't that the point? The list returned could have unloaded classes and > we can catch it via this exception (from the comment above > the ReferenceType interface): > > * Any method on ReferenceType or which directly or > indirectly takes > * ReferenceType as parameter may throw > * {@link ObjectCollectedException} if the mirrored type has been unloaded. > > Turns out that even in the definedClasses, we can get that exception so > we should check for it while walking the reference types as well? I understand that the list returned to the "debugger" process may contain ReferenceTypes for types that have actually been unloaded by the time it queries them (unless the debuggee is suspended of course). But I don't see how we can encounter those types while compiling the list in the debuggee in the first place. Something seems amiss here ... possibly just my understanding ... David > Jc > > *From: *Chris Plummer > > *Date: *Fri, May 10, 2019 at 9:09 PM > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > On 5/10/19 8:59 PM, David Holmes wrote: > >> Hi Daniil, > >> > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > >>> Please review the change that fixes an intermittent failure of the > >>> test. > >>> > >>> The tests checks the implementation of the > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > >>> that while > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > iterates > >>> over all loaded classes to retrieve a classloader and compares > it to > >>> the current one, some of the classes might become unloaded and > >>> garbage collected (e.g. > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > >>> happens then the attempt to retrieve a classloader for the > collected > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > >> > >> That seems odd to me. If you have a reference to the Class then it > >> can't be unloaded. I would not expect allClasses() to have > >> weak-references, so a class should not be unloadable while you are > >> examining it. Unless it is finding VM anonymous classes (which it > >> should not!). > >> > > I was just typing up something similar. Shouldn't the test do a > > vm.suspend() and then call disableCollection() on each class > returned > > by vm.allClasses()? > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > the user of ClassLoaderReference.definedClasses() to do the suspend. In > fact I'm not sure there's much purpose in calling > ClassLoaderReference.definedClasses() without suspending first. Even > with your changes, the list returned can end up with references to > unloaded classes. > > Chris > > > > Chris > >> David > >> ----- > >> > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > >>> continues iterating over the rest of the classes. > >>> > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > >>> > >>> Thanks! > >>> --Daniil > >>> > >>> > > > > > > > > > -- > > Thanks, > Jc From david.holmes at oracle.com Sun May 12 22:19:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 May 2019 08:19:44 +1000 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> Message-ID: Hi Daniil, On 12/05/2019 3:14 am, Daniil Titov wrote: > Hi David, > > There are two ways how these reference types (for the classes that become unloaded later) could appear in the collection com.sun.tools.jdi.VirtualMachineImpl maintains and stores in VirtualMachineImpl.typesBySignature instance variable: > 1) Initial load when all classes are requested from the debuggee > 2) Or added later when ClassPrepare event for a specific class is posted and handled > > The reference types are removed from VirtualMachineImpl.typesBySignature when ClassUnload event is processed. However, additional tracing showed ( pleases see below the sample output) that in some cases these ClassUnload events are received after we entered definedClasses() method and started iterating over the copy of the collection of the classes returned by vm.allClasses() method. Thanks for clarifying that for me. I was thinking in this case that definedClasses() was directly querying the target VM, but it isn't it's iterating the existing set of known classes cached in the client (vm.allClasses()). Though it seems that whether or not we will hit this ObjectCollectedException depends on what we have already done with a particular ReferenceType. In this case we hit the exception when invoking classLoader() but that will only throw the exception if we do not already have the classLoader cached and have to go and seek it from the target VM. I do wonder why this issue should suddenly appear now? Encountering an unloaded class, like a generated reflection accessor, should always have been possible and so we should have seen this before. Something must have changed recently. ?? I'm also concerned about other code that iterates through vm.allClasses() and which does not seem to be aware of the possibility of CollectedObjectException. For example in ClassTypeImpl.java we have: public List subclasses() { List subs = new ArrayList<>(); for (ReferenceType refType : vm.allClasses()) { if (refType instanceof ClassType) { ClassType clazz = (ClassType)refType; ClassType superclass = clazz.superclass(); if ((superclass != null) && superclass.equals(this)) { subs.add((ClassType)refType); } } } return subs; } If the superclass is already cached then this will work, but if it has to call to the target VM over JDWP then we will have the same bug I think. Which again raises the question for me as to why we are not seeing tests fail here? > Based on the output below it seems as all unloaded classes are the generated ones or lambda forms. > > --> debugger: ......getting: List definedClasses = clRef.definedClasses(); > > Received Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > Handled Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; This is fine - generated reflection accessor are loaded in a custom classloader specifically so they can be unloaded promptly. But ... > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; ... these are I believe definitions of VM anonymous classes (they have names of the form foo/ which are not legal class names). Should these even be visible to JDI? Thanks, David ----- > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > Exception while getting classloader for type jdk.internal.reflect.GeneratedConstructorAccessor1 > # ERROR: ##> debugger: ERROR: Exception : com.sun.jdi.ObjectCollectedException > > > Thanks! > --Daniil > > > > ?On 5/11/19, 3:39 AM, "David Holmes" wrote: > > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > > Isn't that the point? The list returned could have unloaded classes and > > we can catch it via this exception (from the comment above > > the ReferenceType interface): > > > > * Any method on ReferenceType or which directly or > > indirectly takes > > * ReferenceType as parameter may throw > > * {@link ObjectCollectedException} if the mirrored type has been unloaded. > > > > Turns out that even in the definedClasses, we can get that exception so > > we should check for it while walking the reference types as well? > > I understand that the list returned to the "debugger" process may > contain ReferenceTypes for types that have actually been unloaded by the > time it queries them (unless the debuggee is suspended of course). But I > don't see how we can encounter those types while compiling the list in > the debuggee in the first place. > > Something seems amiss here ... possibly just my understanding ... > > David > > > Jc > > > > *From: *Chris Plummer > > > > *Date: *Fri, May 10, 2019 at 9:09 PM > > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > > On 5/10/19 8:59 PM, David Holmes wrote: > > >> Hi Daniil, > > >> > > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > > >>> Please review the change that fixes an intermittent failure of the > > >>> test. > > >>> > > >>> The tests checks the implementation of the > > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > > >>> that while > > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > > iterates > > >>> over all loaded classes to retrieve a classloader and compares > > it to > > >>> the current one, some of the classes might become unloaded and > > >>> garbage collected (e.g. > > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > > >>> happens then the attempt to retrieve a classloader for the > > collected > > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > > >> > > >> That seems odd to me. If you have a reference to the Class then it > > >> can't be unloaded. I would not expect allClasses() to have > > >> weak-references, so a class should not be unloadable while you are > > >> examining it. Unless it is finding VM anonymous classes (which it > > >> should not!). > > >> > > > I was just typing up something similar. Shouldn't the test do a > > > vm.suspend() and then call disableCollection() on each class > > returned > > > by vm.allClasses()? > > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > > the user of ClassLoaderReference.definedClasses() to do the suspend. In > > fact I'm not sure there's much purpose in calling > > ClassLoaderReference.definedClasses() without suspending first. Even > > with your changes, the list returned can end up with references to > > unloaded classes. > > > > Chris > > > > > > Chris > > >> David > > >> ----- > > >> > > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > > >>> continues iterating over the rest of the classes. > > >>> > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > >>> > > >>> Thanks! > > >>> --Daniil > > >>> > > >>> > > > > > > > > > > > > > > > > -- > > > > Thanks, > > Jc > > > From sakamoto.osamu at nttcom.co.jp Mon May 13 06:38:42 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Mon, 13 May 2019 15:38:42 +0900 Subject: debugd options should regard to jhsdb style In-Reply-To: <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> Message-ID: <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> Hi, David I saw your comment in this CSR. CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 I understand that the problem is that the help description of debugd I proposed and current other modes is not helpful for users. What should we do to go through this CSR? IMHO we should update help description of all jhsdb modes more helpful. Do you have any ideas about this? Thanks, Osamu On 5/10/19 17:46, ?? ? wrote: > Hi, > > I agree with Yasumasa's opinion in CSR. > > I wrote new debugd format and usage to match other modes(jstack, jmap and so on) in jhdsb. > Certainly, usage of debugd which I proposed does not explain that and cannot be used together, but it is not limited to debugd - other modes have similar issue. > > I think it is helpful to detail help description in each jhsdb modes, but I'd like to separate as another issue because this is not limited to debugd. > > -----Original Message----- > From: Yasumasa Suenaga > Sent: Friday, May 10, 2019 4:08 PM > To: David Holmes > Cc: Jean Christophe Beyler ; serviceability-dev at openjdk.java.net serviceability-dev at openjdk.java.net ; ?? ? > Subject: Re: debugd options should regard to jhsdb style > > Hi David, > > Thank you for checking in CSR, and sorry for my incorrect description. > I added my opinion to CSR. > > Osamu, do you have any opinion? > > > Yasumasa > > > 2019?5?10?(?) 15:16 David Holmes : >> >> Hi Yasumasa, >> >> I've made some updates to the CSR request and raised a couple of issues. >> >> FYI the specification section only needs to contain the actual >> specification for what has changed ie the new command-line options; >> not the implementation that will bring about those changes. >> >> Thanks, >> David >> >> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>> Thanks JC! >>> >>> I added key point of this change to specification section in CSR. >>> >>> >>> Yasumasa >>> >>> 2019?5?10?(?) 12:54 Jean Christophe Beyler : >>>> >>>> Hi Yasumasa, >>>> >>>> I'm not a reviewer but the CSR looks good; I feel that the >>>> specification section could use some text and then send the reader >>>> to the other bug entry :) Jc >>>> >>>> From: Yasumasa Suenaga >>>> Date: Thu, May 9, 2019 at 8:06 PM >>>> To: serviceability-dev at openjdk.java.net >>>> serviceability-dev at openjdk.java.net >>>> >>>>> tests on submit repo have been passed >>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>> >>>>> Could you review the CSR? >>>>> >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>> >>>>>> Hi, >>>>>> >>>>>> Osamu, your change looks good to me. >>>>>> I will sponsor you. >>>>>> >>>>>> David, I filed this issue and requested to CSR: >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>> >>>>>> I uploaded webrev. I will push it to submit repo. >>>>>> >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>> suspect that historically the form of this command was done to match other tools. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>> However debugd mode has different options from other modes. >>>>>>>> I think debugd should have same options like other modes. >>>>>>>> >>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd --pid `. >>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>> >>>>>>>> I attached a patch for this enhancement. >>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>> >>>>>>>> Testcase for debugd is available as serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my proposal has been merged. >>>>>>>> >>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Osamu >>>>>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Jc From david.holmes at oracle.com Mon May 13 07:00:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 May 2019 17:00:11 +1000 Subject: debugd options should regard to jhsdb style In-Reply-To: <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> Message-ID: <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: > Hi, David > > I saw your comment in this CSR. > CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 > > I understand that the problem is that the help description of debugd I > proposed and current other modes is not helpful for users. > > What should we do to go through this CSR? > IMHO we should update help description of all jhsdb modes more helpful. > Do you have any ideas about this? I think a RFE should be filed to improve the general jhsdb help output, so that it explains that --pid and --exe are mutually exclusive options. That way this CSR, and thus the associated RFE can proceed. I'll add the same info the CSR. Thanks, David > Thanks, > Osamu > > > On 5/10/19 17:46, ?? ? wrote: >> Hi, >> >> I agree with Yasumasa's opinion in CSR. >> >> I wrote new debugd format and usage to match other modes(jstack, jmap >> and so on) in jhdsb. >> Certainly, usage of debugd which I proposed does not explain that >> and cannot be used together, but it is not limited to >> debugd - other modes have similar issue. >> >> I think it is helpful to detail help description in each jhsdb modes, >> but I'd like to separate as another issue because this is not limited >> to debugd. >> >> -----Original Message----- >> From: Yasumasa Suenaga >> Sent: Friday, May 10, 2019 4:08 PM >> To: David Holmes >> Cc: Jean Christophe Beyler ; >> serviceability-dev at openjdk.java.net >> serviceability-dev at openjdk.java.net >> ; ?? ? >> >> Subject: Re: debugd options should regard to jhsdb style >> >> Hi David, >> >> Thank you for checking in CSR, and sorry for my incorrect description. >> I added my opinion to CSR. >> >> Osamu, do you have any opinion? >> >> >> Yasumasa >> >> >> 2019?5?10?(?) 15:16 David Holmes : >>> >>> Hi Yasumasa, >>> >>> I've made some updates to the CSR request and raised a couple of issues. >>> >>> FYI the specification section only needs to contain the actual >>> specification for what has changed ie the new command-line options; >>> not the implementation that will bring about those changes. >>> >>> Thanks, >>> David >>> >>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>> Thanks JC! >>>> >>>> I added key point of this change to specification section in CSR. >>>> >>>> >>>> Yasumasa >>>> >>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler : >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>> specification section could use some text and then send the reader >>>>> to the other bug entry :) Jc >>>>> >>>>> From: Yasumasa Suenaga >>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>> To: serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> >>>>>> tests on submit repo have been passed >>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>> >>>>>> Could you review the CSR? >>>>>> >>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Osamu, your change looks good to me. >>>>>>> I will sponsor you. >>>>>>> >>>>>>> David, I filed this issue and requested to CSR: >>>>>>> >>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>> >>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>> >>>>>>> ???? http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>> suspect that historically the form of this command was done to >>>>>>>> match other tools. >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>> >>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd --pid >>>>>>>>> `. >>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>> >>>>>>>>> I attached a patch for this enhancement. >>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>> >>>>>>>>> Testcase for debugd is available as >>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>> proposal has been merged. >>>>>>>>> >>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Osamu >>>>>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Thanks, >>>>> Jc From sakamoto.osamu at nttcom.co.jp Mon May 13 08:06:37 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Mon, 13 May 2019 17:06:37 +0900 Subject: debugd options should regard to jhsdb style In-Reply-To: <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> Message-ID: Hi David, Thank you for updating the CSR. I agree with filing a RFE to improve the general jhsdb help output. Could you file the RFE? (I can't access JBS.) I would like to contribute it if the RFE will be filed. My proposal (webrev.00) has been reviewed by Yasumasa and JC. So I will request Yasumasa to push it to jdk/jdk when the status of CSR changes to Approved, and RFE for jhsdb help is filed. Thanks, Osamu On 5/13/19 16:00, David Holmes wrote: > > On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >> Hi, David >> >> I saw your comment in this CSR. >> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >> >> I understand that the problem is that the help description of debugd I >> proposed and current other modes is not helpful for users. >> >> What should we do to go through this CSR? >> IMHO we should update help description of all jhsdb modes more helpful. >> Do you have any ideas about this? > > I think a RFE should be filed to improve the general jhsdb help output, > so that it explains that --pid and --exe are mutually exclusive options. > That way this CSR, and thus the associated RFE can proceed. I'll add the > same info the CSR. > > Thanks, > David > >> Thanks, >> Osamu >> >> >> On 5/10/19 17:46, ?? ? wrote: >>> Hi, >>> >>> I agree with Yasumasa's opinion in CSR. >>> >>> I wrote new debugd format and usage to match other modes(jstack, jmap >>> and so on) in jhdsb. >>> Certainly, usage of debugd which I proposed does not explain that >>> and cannot be used together, but it is not limited to >>> debugd - other modes have similar issue. >>> >>> I think it is helpful to detail help description in each jhsdb modes, >>> but I'd like to separate as another issue because this is not limited >>> to debugd. >>> >>> -----Original Message----- >>> From: Yasumasa Suenaga >>> Sent: Friday, May 10, 2019 4:08 PM >>> To: David Holmes >>> Cc: Jean Christophe Beyler ; >>> serviceability-dev at openjdk.java.net >>> serviceability-dev at openjdk.java.net >>> ; ?? ? >>> >>> Subject: Re: debugd options should regard to jhsdb style >>> >>> Hi David, >>> >>> Thank you for checking in CSR, and sorry for my incorrect description. >>> I added my opinion to CSR. >>> >>> Osamu, do you have any opinion? >>> >>> >>> Yasumasa >>> >>> >>> 2019?5?10?(?) 15:16 David Holmes : >>>> >>>> Hi Yasumasa, >>>> >>>> I've made some updates to the CSR request and raised a couple of >>>> issues. >>>> >>>> FYI the specification section only needs to contain the actual >>>> specification for what has changed ie the new command-line options; >>>> not the implementation that will bring about those changes. >>>> >>>> Thanks, >>>> David >>>> >>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>> Thanks JC! >>>>> >>>>> I added key point of this change to specification section in CSR. >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler : >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>> specification section could use some text and then send the reader >>>>>> to the other bug entry :) Jc >>>>>> >>>>>> From: Yasumasa Suenaga >>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>> To: serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> >>>>>>> tests on submit repo have been passed >>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>> >>>>>>> Could you review the CSR? >>>>>>> >>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Osamu, your change looks good to me. >>>>>>>> I will sponsor you. >>>>>>>> >>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>> >>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>> >>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>> >>>>>>>> ???? http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>> suspect that historically the form of this command was done to >>>>>>>>> match other tools. >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>> >>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>> --pid `. >>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>> >>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>> >>>>>>>>>> Testcase for debugd is available as >>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>> proposal has been merged. >>>>>>>>>> >>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Osamu >>>>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc From jcbeyler at google.com Mon May 13 15:18:20 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 13 May 2019 08:18:20 -0700 Subject: RFR (XS) 8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test) Message-ID: Hi all, Here is a small patch for fixing a fastdebug linking error: Bug is : https://bugs.openjdk.java.net/browse/JDK-8223779 Diff is: diff -r 85ccac8a8c13 make/test/JtregNativeHotspot.gmk --- a/make/test/JtregNativeHotspot.gmk Mon May 13 16:43:47 2019 +0200 +++ b/make/test/JtregNativeHotspot.gmk Mon May 13 08:13:11 2019 -0700 @@ -864,7 +864,7 @@ BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exestack-gap := -ljvm -lpthread BUILD_TEST_exeinvoke_exeinvoke.c_OPTIMIZATION := NONE BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exeFPRegs := -ldl - BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAsyncGetCallTraceTest := -ldl + BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libAsyncGetCallTraceTest := -ldl else BUILD_HOTSPOT_JTREG_EXCLUDE += libtest-rw.c libtest-rwx.c libTestJNI.c \ exeinvoke.c exestack-gap.c libAsyncGetCallTraceTest.cpp Important note: it passes with or without this patch on my dev machine but Aleksey Shipilev saw the failure and saw that the patch helps. So I think this should be done; I'm sending it to the submit-repo at the same time. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon May 13 16:21:55 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 May 2019 09:21:55 -0700 Subject: RFR (XS) 8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test) In-Reply-To: References: Message-ID: <51d86b7d-d592-e66a-e242-80afb4f82f12@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Mon May 13 19:56:59 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 13 May 2019 12:56:59 -0700 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> Message-ID: <5D669D64-3296-4F34-BDA0-17E467F2F94A@oracle.com> Hi David, It seems as the chances that class unloading happens during the life-time of these tests are extremely low and switching Graal on increases these chances. At least without Graal I could not locate any test result that showed that ClassUnload event was posted. With Graal on 1 of 500 tests fails (at least on Windows platform, on other platforms it must be more rare if not zero) and I could not find any successful test showing that ClassUnload event was ever posted for any class. You are right, the similar problem exists for ClassTypeImpl. subclasses() method and there is a separate issue for that: JDK-8223492. And while I was not able to reproduce it so far the logs provided in JDK-8223492 show that the problem here is the same. Initially I planned to keep these issues separated and proceed with JDK-8223492 after the current review is completed. But if you think it makes sense I could update the current webrev to include changes for ClassTypeImpl. subclasses() and then close JDK-8223492 as a duplicate. I am also curious whether lambda forms, e.g. org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388, are supposed to be visible in JDI but I could not locate any discussion about this. Thanks! --Daniil Per tests data and additional tracing it seems as with Graal on the chances that class unloading happens during the test run are about 1/200 and only on Windows platform. Without Graal there were no single occurrence of the test when any ClassUnload event was posted. ?On 5/12/19, 3:19 PM, "David Holmes" wrote: Hi Daniil, On 12/05/2019 3:14 am, Daniil Titov wrote: > Hi David, > > There are two ways how these reference types (for the classes that become unloaded later) could appear in the collection com.sun.tools.jdi.VirtualMachineImpl maintains and stores in VirtualMachineImpl.typesBySignature instance variable: > 1) Initial load when all classes are requested from the debuggee > 2) Or added later when ClassPrepare event for a specific class is posted and handled > > The reference types are removed from VirtualMachineImpl.typesBySignature when ClassUnload event is processed. However, additional tracing showed ( pleases see below the sample output) that in some cases these ClassUnload events are received after we entered definedClasses() method and started iterating over the copy of the collection of the classes returned by vm.allClasses() method. Thanks for clarifying that for me. I was thinking in this case that definedClasses() was directly querying the target VM, but it isn't it's iterating the existing set of known classes cached in the client (vm.allClasses()). Though it seems that whether or not we will hit this ObjectCollectedException depends on what we have already done with a particular ReferenceType. In this case we hit the exception when invoking classLoader() but that will only throw the exception if we do not already have the classLoader cached and have to go and seek it from the target VM. I do wonder why this issue should suddenly appear now? Encountering an unloaded class, like a generated reflection accessor, should always have been possible and so we should have seen this before. Something must have changed recently. ?? I'm also concerned about other code that iterates through vm.allClasses() and which does not seem to be aware of the possibility of CollectedObjectException. For example in ClassTypeImpl.java we have: public List subclasses() { List subs = new ArrayList<>(); for (ReferenceType refType : vm.allClasses()) { if (refType instanceof ClassType) { ClassType clazz = (ClassType)refType; ClassType superclass = clazz.superclass(); if ((superclass != null) && superclass.equals(this)) { subs.add((ClassType)refType); } } } return subs; } If the superclass is already cached then this will work, but if it has to call to the target VM over JDWP then we will have the same bug I think. Which again raises the question for me as to why we are not seeing tests fail here? > Based on the output below it seems as all unloaded classes are the generated ones or lambda forms. > > --> debugger: ......getting: List definedClasses = clRef.definedClasses(); > > Received Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > Handled Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; This is fine - generated reflection accessor are loaded in a custom classloader specifically so they can be unloaded promptly. But ... > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; ... these are I believe definitions of VM anonymous classes (they have names of the form foo/ which are not legal class names). Should these even be visible to JDI? Thanks, David ----- > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > Exception while getting classloader for type jdk.internal.reflect.GeneratedConstructorAccessor1 > # ERROR: ##> debugger: ERROR: Exception : com.sun.jdi.ObjectCollectedException > > > Thanks! > --Daniil > > > > ?On 5/11/19, 3:39 AM, "David Holmes" wrote: > > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > > Isn't that the point? The list returned could have unloaded classes and > > we can catch it via this exception (from the comment above > > the ReferenceType interface): > > > > * Any method on ReferenceType or which directly or > > indirectly takes > > * ReferenceType as parameter may throw > > * {@link ObjectCollectedException} if the mirrored type has been unloaded. > > > > Turns out that even in the definedClasses, we can get that exception so > > we should check for it while walking the reference types as well? > > I understand that the list returned to the "debugger" process may > contain ReferenceTypes for types that have actually been unloaded by the > time it queries them (unless the debuggee is suspended of course). But I > don't see how we can encounter those types while compiling the list in > the debuggee in the first place. > > Something seems amiss here ... possibly just my understanding ... > > David > > > Jc > > > > *From: *Chris Plummer > > > > *Date: *Fri, May 10, 2019 at 9:09 PM > > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > > On 5/10/19 8:59 PM, David Holmes wrote: > > >> Hi Daniil, > > >> > > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > > >>> Please review the change that fixes an intermittent failure of the > > >>> test. > > >>> > > >>> The tests checks the implementation of the > > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > > >>> that while > > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > > iterates > > >>> over all loaded classes to retrieve a classloader and compares > > it to > > >>> the current one, some of the classes might become unloaded and > > >>> garbage collected (e.g. > > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > > >>> happens then the attempt to retrieve a classloader for the > > collected > > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > > >> > > >> That seems odd to me. If you have a reference to the Class then it > > >> can't be unloaded. I would not expect allClasses() to have > > >> weak-references, so a class should not be unloadable while you are > > >> examining it. Unless it is finding VM anonymous classes (which it > > >> should not!). > > >> > > > I was just typing up something similar. Shouldn't the test do a > > > vm.suspend() and then call disableCollection() on each class > > returned > > > by vm.allClasses()? > > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > > the user of ClassLoaderReference.definedClasses() to do the suspend. In > > fact I'm not sure there's much purpose in calling > > ClassLoaderReference.definedClasses() without suspending first. Even > > with your changes, the list returned can end up with references to > > unloaded classes. > > > > Chris > > > > > > Chris > > >> David > > >> ----- > > >> > > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > > >>> continues iterating over the rest of the classes. > > >>> > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > >>> > > >>> Thanks! > > >>> --Daniil > > >>> > > >>> > > > > > > > > > > > > > > > > -- > > > > Thanks, > > Jc > > > From serguei.spitsyn at oracle.com Mon May 13 20:03:12 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 May 2019 13:03:12 -0700 Subject: RFR (XS) 8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test) In-Reply-To: <51d86b7d-d592-e66a-e242-80afb4f82f12@oracle.com> References: <51d86b7d-d592-e66a-e242-80afb4f82f12@oracle.com> Message-ID: <9ed813be-4194-d9cf-162a-3f61cda9bcf2@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Mon May 13 20:33:48 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 13 May 2019 13:33:48 -0700 Subject: RFR (XS) 8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test) In-Reply-To: <9ed813be-4194-d9cf-162a-3f61cda9bcf2@oracle.com> References: <51d86b7d-d592-e66a-e242-80afb4f82f12@oracle.com> <9ed813be-4194-d9cf-162a-3f61cda9bcf2@oracle.com> Message-ID: Hi all, Submit repo seems down, could someone test it via mach1 testing please? Here is the webrev: http://cr.openjdk.java.net/~jcbeyler/8223779/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8223779 (Or I can wait until submit repo comes back online for me :-)) Thanks! Jc *From: *serguei.spitsyn at oracle.com *Date: *Mon, May 13, 2019 at 1:03 PM *To: *Chris Plummer, Jean Christophe Beyler, OpenJDK Serviceability *Cc: *Aleksey Shipilev On 5/13/19 09:21, Chris Plummer wrote: > Hi Jc, > > +1 > > Thanks, > Serguei > > > Hi JC, > > Your fix is consistent with the one done for > https://bugs.openjdk.java.net/browse/JDK-8169261, so thumbs up. > > thanks, > > Chris > > On 5/13/19 8:18 AM, Jean Christophe Beyler wrote: > > Hi all, > > Here is a small patch for fixing a fastdebug linking error: > > Bug is : https://bugs.openjdk.java.net/browse/JDK-8223779 > Diff is: > > diff -r 85ccac8a8c13 make/test/JtregNativeHotspot.gmk > --- a/make/test/JtregNativeHotspot.gmk Mon May 13 16:43:47 2019 +0200 > +++ b/make/test/JtregNativeHotspot.gmk Mon May 13 08:13:11 2019 -0700 > @@ -864,7 +864,7 @@ > BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exestack-gap := -ljvm -lpthread > BUILD_TEST_exeinvoke_exeinvoke.c_OPTIMIZATION := NONE > BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exeFPRegs := -ldl > - BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAsyncGetCallTraceTest := -ldl > + BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libAsyncGetCallTraceTest := -ldl > else > BUILD_HOTSPOT_JTREG_EXCLUDE += libtest-rw.c libtest-rwx.c libTestJNI.c \ > exeinvoke.c exestack-gap.c libAsyncGetCallTraceTest.cpp > > Important note: it passes with or without this patch on my dev machine > but Aleksey Shipilev saw the failure and saw that the patch helps. So I > think this should be done; I'm sending it to the submit-repo at the same > time. > > Thanks, > Jc > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon May 13 20:36:23 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 May 2019 13:36:23 -0700 Subject: RFR (XS) 8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test) In-Reply-To: References: <51d86b7d-d592-e66a-e242-80afb4f82f12@oracle.com> <9ed813be-4194-d9cf-162a-3f61cda9bcf2@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Mon May 13 21:06:12 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 13 May 2019 14:06:12 -0700 Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com> <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com> Message-ID: <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com> Hi Chris, Serguei, Updated webrev: http://cr.openjdk.java.net/~amenkov/IPv6/webrev.05/ CSR (approved): https://bugs.openjdk.java.net/browse/JDK-8223104 Changes (vs. webrev.04): - setsockopt(IPV6_V6ONLY) was moved from Win-specific code to shared setOptionsCommon function (in socketTransport.c) the value by default is "true" on Windows and is "false" on Unix, but it can be overridden, so lets set it explicitly; - a comment why the result of setsockopt(IPV6_V6ONLY) is ignored is added; - added some comments as per Serguei request. About scopes support - I thought that the functionality is not important for debugger, but I can implement it (I'd prefer to do it by separate RFE). --alex On 05/11/2019 03:39, Chris Hegarty wrote: > > >> On 7 May 2019, at 19:40, serguei.spitsyn at oracle.com wrote: >> >> Hi guys, >> >> We need a couple of partial reviews for this enhancement: >> >> - From the net-dev to check IPv6-addresses related part. >> It does not need to be a thorough review. >> We need another pair of eyes to check for obvious typos or misses. >> Included Chris H. to mailing list in hope for some assistance. >> (Chris, we need some help to find one of the IPv6 experts.) >> >> - From the serviceability-dev to check if compatibility >> is not broken and nothing is missed. >> This includes part of code that is not directly involved >> into manipulations with the IPv4/IPv6 addresses. >> The related spec update is tracked by a sub-task: >> https://bugs.openjdk.java.net/browse/JDK-8221707 >> >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223104 >> >> The latest webrev: >> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ > > > src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c > > 223 if (domain == AF_INET6) { > 224 int off = 0; > 225 // make the socket a dual mode socket > 226 setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (char *)&off, sizeof(off)); > 227 } > 228 } > > This code is fine, but maybe you want to expand the comment to > mention that the setsockopt may fail if IPv4 is not supported. And > that?s OK. > > I cannot find a similar setting of IPV6_V6ONLY for the unix > equivalent. Why not, or where can it be found? > > src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c > > There is a lot of native code here, I skimmed over it, seems > reasonable. There is an obvious lack of any reference to IPv6 > scopes. Can the address given to bind be an IPv6 link-local? > If so, then the scope will need to be parsed / set appropriately. > ( seems that the new test skips all scoped addresses? ) > > -Chris. > From david.holmes at oracle.com Mon May 13 21:59:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 07:59:05 +1000 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: <5D669D64-3296-4F34-BDA0-17E467F2F94A@oracle.com> References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> <5D669D64-3296-4F34-BDA0-17E467F2F94A@oracle.com> Message-ID: <8386d219-7680-63e7-cd0b-4e671938cac6@oracle.com> Hi Daniil, On 14/05/2019 5:56 am, Daniil Titov wrote: > Hi David, > > It seems as the chances that class unloading happens during the life-time of these tests are extremely low and switching Graal on increases these chances. At least without Graal I could not locate any test result that showed that ClassUnload event was posted. With Graal on 1 of 500 tests fails (at least on Windows platform, on other platforms it must be more rare if not zero) and I could not find any successful test showing that ClassUnload event was ever posted for any class. Interesting that only Graal exposes this ... though it may be that the reflection accessor actually relates to Graal code, hence the reason the unloading only shows up with Graal. It may mean there is a hole in our test coverage with JDI - may need some tests that involve executing reflection code with accessors eagerly generated so that we do see class-unload events. Though timing would be problematic. > You are right, the similar problem exists for ClassTypeImpl. subclasses() method and there is a separate issue for that: JDK-8223492. And while I was not able to reproduce it so far the logs provided in JDK-8223492 show that the problem here is the same. Initially I planned to keep these issues separated and proceed with JDK-8223492 after the current review is completed. But if you think it makes sense I could update the current webrev to include changes for ClassTypeImpl. subclasses() and then close JDK-8223492 as a duplicate. Entirely up to you. But I would be suspicious of all of the code that iterates vm.allClasses(). > I am also curious whether lambda forms, e.g. org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388, are supposed to be visible in JDI but I could not locate any discussion about this. I'm trying to find that out too - but we can deal with that as a separate issue. Thanks, David > Thanks! > --Daniil > > > Per tests data and additional tracing it seems as with Graal on the chances that class unloading happens during the test run are about 1/200 and only on Windows platform. Without Graal there were no single occurrence of the test when any ClassUnload event was posted. > > ?On 5/12/19, 3:19 PM, "David Holmes" wrote: > > Hi Daniil, > > On 12/05/2019 3:14 am, Daniil Titov wrote: > > Hi David, > > > > There are two ways how these reference types (for the classes that become unloaded later) could appear in the collection com.sun.tools.jdi.VirtualMachineImpl maintains and stores in VirtualMachineImpl.typesBySignature instance variable: > > 1) Initial load when all classes are requested from the debuggee > > 2) Or added later when ClassPrepare event for a specific class is posted and handled > > > > The reference types are removed from VirtualMachineImpl.typesBySignature when ClassUnload event is processed. However, additional tracing showed ( pleases see below the sample output) that in some cases these ClassUnload events are received after we entered definedClasses() method and started iterating over the copy of the collection of the classes returned by vm.allClasses() method. > > Thanks for clarifying that for me. I was thinking in this case that > definedClasses() was directly querying the target VM, but it isn't it's > iterating the existing set of known classes cached in the client > (vm.allClasses()). > > Though it seems that whether or not we will hit this > ObjectCollectedException depends on what we have already done with a > particular ReferenceType. In this case we hit the exception when > invoking classLoader() but that will only throw the exception if we do > not already have the classLoader cached and have to go and seek it from > the target VM. > > I do wonder why this issue should suddenly appear now? Encountering an > unloaded class, like a generated reflection accessor, should always have > been possible and so we should have seen this before. Something must > have changed recently. ?? > > I'm also concerned about other code that iterates through > vm.allClasses() and which does not seem to be aware of the possibility > of CollectedObjectException. For example in ClassTypeImpl.java we have: > > public List subclasses() { > List subs = new ArrayList<>(); > for (ReferenceType refType : vm.allClasses()) { > if (refType instanceof ClassType) { > ClassType clazz = (ClassType)refType; > ClassType superclass = clazz.superclass(); > if ((superclass != null) && superclass.equals(this)) { > subs.add((ClassType)refType); > } > } > } > > return subs; > } > > If the superclass is already cached then this will work, but if it has > to call to the target VM over JDWP then we will have the same bug I > think. Which again raises the question for me as to why we are not > seeing tests fail here? > > > Based on the output below it seems as all unloaded classes are the generated ones or lambda forms. > > > > --> debugger: ......getting: List definedClasses = clRef.definedClasses(); > > > > Received Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > Handled Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > This is fine - generated reflection accessor are loaded in a custom > classloader specifically so they can be unloaded promptly. But ... > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > ... these are I believe definitions of VM anonymous classes (they have > names of the form foo/ which are not legal class names). Should > these even be visible to JDI? > > Thanks, > David > ----- > > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > > Exception while getting classloader for type jdk.internal.reflect.GeneratedConstructorAccessor1 > > # ERROR: ##> debugger: ERROR: Exception : com.sun.jdi.ObjectCollectedException > > > > > > Thanks! > > --Daniil > > > > > > > > ?On 5/11/19, 3:39 AM, "David Holmes" wrote: > > > > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > > > Isn't that the point? The list returned could have unloaded classes and > > > we can catch it via this exception (from the comment above > > > the ReferenceType interface): > > > > > > * Any method on ReferenceType or which directly or > > > indirectly takes > > > * ReferenceType as parameter may throw > > > * {@link ObjectCollectedException} if the mirrored type has been unloaded. > > > > > > Turns out that even in the definedClasses, we can get that exception so > > > we should check for it while walking the reference types as well? > > > > I understand that the list returned to the "debugger" process may > > contain ReferenceTypes for types that have actually been unloaded by the > > time it queries them (unless the debuggee is suspended of course). But I > > don't see how we can encounter those types while compiling the list in > > the debuggee in the first place. > > > > Something seems amiss here ... possibly just my understanding ... > > > > David > > > > > Jc > > > > > > *From: *Chris Plummer > > > > > > *Date: *Fri, May 10, 2019 at 9:09 PM > > > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > > > > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > > > On 5/10/19 8:59 PM, David Holmes wrote: > > > >> Hi Daniil, > > > >> > > > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > > > >>> Please review the change that fixes an intermittent failure of the > > > >>> test. > > > >>> > > > >>> The tests checks the implementation of the > > > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > > > >>> that while > > > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > > > iterates > > > >>> over all loaded classes to retrieve a classloader and compares > > > it to > > > >>> the current one, some of the classes might become unloaded and > > > >>> garbage collected (e.g. > > > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > > > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > > > >>> happens then the attempt to retrieve a classloader for the > > > collected > > > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > > > >> > > > >> That seems odd to me. If you have a reference to the Class then it > > > >> can't be unloaded. I would not expect allClasses() to have > > > >> weak-references, so a class should not be unloadable while you are > > > >> examining it. Unless it is finding VM anonymous classes (which it > > > >> should not!). > > > >> > > > > I was just typing up something similar. Shouldn't the test do a > > > > vm.suspend() and then call disableCollection() on each class > > > returned > > > > by vm.allClasses()? > > > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > > > the user of ClassLoaderReference.definedClasses() to do the suspend. In > > > fact I'm not sure there's much purpose in calling > > > ClassLoaderReference.definedClasses() without suspending first. Even > > > with your changes, the list returned can end up with references to > > > unloaded classes. > > > > > > Chris > > > > > > > > Chris > > > >> David > > > >> ----- > > > >> > > > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > > > >>> continues iterating over the rest of the classes. > > > >>> > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > > > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > > >>> > > > >>> Thanks! > > > >>> --Daniil > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > > From serguei.spitsyn at oracle.com Mon May 13 23:33:24 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 May 2019 16:33:24 -0700 Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com> <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com> <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com> Message-ID: <4101dda6-021c-5a3c-270e-fa0a10b82ae4@oracle.com> Hi Alex, Thank you for the update! It looks good to me. Thanks, Serguei On 5/13/19 14:06, Alex Menkov wrote: > Hi Chris, Serguei, > > Updated webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.05/ > CSR (approved): > https://bugs.openjdk.java.net/browse/JDK-8223104 > > Changes (vs. webrev.04): > > - setsockopt(IPV6_V6ONLY) was moved from Win-specific code to shared > setOptionsCommon function (in socketTransport.c) > ? the value by default is "true" on Windows and is "false" on Unix, > but it can be overridden, so lets set it explicitly; > - a comment why the result of setsockopt(IPV6_V6ONLY) is ignored is > added; > - added some comments as per Serguei request. > > About scopes support - I thought that the functionality is not > important for debugger, but I can implement it (I'd prefer to do it by > separate RFE). > > --alex > > On 05/11/2019 03:39, Chris Hegarty wrote: >> >> >>> On 7 May 2019, at 19:40, serguei.spitsyn at oracle.com wrote: >>> >>> Hi guys, >>> >>> We need a couple of partial reviews for this enhancement: >>> >>> ? - From the net-dev to check IPv6-addresses related part. >>> ??? It does not need to be a thorough review. >>> ??? We need another pair of eyes to check for obvious typos or misses. >>> ??? Included Chris H. to mailing list in hope for some assistance. >>> ??? (Chris, we need some help to find one of the IPv6 experts.) >>> >>> ? - From the serviceability-dev to check if compatibility >>> ??? is not broken and nothing is missed. >>> ??? This includes part of code that is not directly involved >>> ??? into manipulations with the IPv4/IPv6 addresses. >>> ??? The related spec update is tracked by a sub-task: >>> ????? https://bugs.openjdk.java.net/browse/JDK-8221707 >>> >>> >>> Related CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8223104 >>> >>> The latest webrev: >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ >> >> >> src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c >> >> ??? 223???? if (domain == AF_INET6) { >> ??? 224???????? int off = 0; >> ??? 225???????? // make the socket a dual mode socket >> ??? 226???????? setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (char >> *)&off, sizeof(off)); >> ??? 227???? } >> ??? 228?? } >> >> ?? This code is fine, but maybe you want to expand the comment to >> ?? mention that the setsockopt may fail if IPv4 is not supported. And >> ?? that?s OK. >> >> ?? I cannot find a similar setting of IPV6_V6ONLY for the unix >> ?? equivalent. Why not, or where can it be found? >> >> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >> >> ?? There is a lot of native code here, I skimmed over it, seems >> ?? reasonable. There is an obvious lack of any reference to IPv6 >> ?? scopes. Can the address given to bind be an IPv6 link-local? >> ?? If so, then the scope will need to be parsed / set appropriately. >> ?? ( seems that the new test skips all scoped addresses? ) >> >> -Chris. >> From serguei.spitsyn at oracle.com Tue May 14 02:36:18 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 May 2019 19:36:18 -0700 Subject: RFC: 8223740: Clarify Instrumentation interface should not be implemented outside java.instrument module Message-ID: <28fb2148-a8df-9637-aa80-ea5f8c5f4a6d@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Tue May 14 03:30:58 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 13 May 2019 20:30:58 -0700 Subject: RFR (XS) 8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test) In-Reply-To: References: <51d86b7d-d592-e66a-e242-80afb4f82f12@oracle.com> <9ed813be-4194-d9cf-162a-3f61cda9bcf2@oracle.com> Message-ID: <02fcb188-24ad-ad12-4ffa-dac460b98d12@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue May 14 03:45:52 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 13 May 2019 20:45:52 -0700 Subject: RFR (XS) 8223779: Build failure after 8223040 (Add a AsyncGetCallTrace test) In-Reply-To: <02fcb188-24ad-ad12-4ffa-dac460b98d12@oracle.com> References: <51d86b7d-d592-e66a-e242-80afb4f82f12@oracle.com> <9ed813be-4194-d9cf-162a-3f61cda9bcf2@oracle.com> <02fcb188-24ad-ad12-4ffa-dac460b98d12@oracle.com> Message-ID: Thanks Chris! Much appreciated, Jc *From: *Chris Plummer *Date: *Mon, May 13, 2019 at 8:31 PM *To: *Jean Christophe Beyler, serguei.spitsyn at oracle.com *Cc: *OpenJDK Serviceability, Aleksey Shipilev Sorry about the delay. Ran into a couple of issues (both my fault). After > correcting them the testing went through ok. > > Chris > > On 5/13/19 1:36 PM, Chris Plummer wrote: > > I can do that. > > Chris > > > On 5/13/19 1:33 PM, Jean Christophe Beyler wrote: > > Hi all, > > Submit repo seems down, could someone test it via mach1 testing please? > > Here is the webrev:? > http://cr.openjdk.java.net/~jcbeyler/8223779/webrev.00/ > Bug:? https://bugs.openjdk.java.net/browse/JDK-8223779 > > (Or I can wait until submit repo comes back online for me :-)) > > Thanks! > Jc > > *From: *serguei.spitsyn at oracle.com > *Date: *Mon, May 13, 2019 at 1:03 PM > *To: *Chris Plummer, Jean Christophe Beyler, OpenJDK Serviceability > *Cc: *Aleksey Shipilev > > On 5/13/19 09:21, Chris Plummer wrote: >> Hi Jc, >> >> +1 >> >> Thanks, >> Serguei >> >> >> Hi JC, >> >> Your fix is consistent with the one done for >> https://bugs.openjdk.java.net/browse/JDK-8169261, so thumbs up. >> >> thanks, >> >> Chris >> >> On 5/13/19 8:18 AM, Jean Christophe Beyler wrote: >> >> Hi all, >> >> Here is a small patch for fixing a fastdebug linking error: >> >> Bug is :? https://bugs.openjdk.java.net/browse/JDK-8223779 >> Diff is: >> >> diff -r 85ccac8a8c13 make/test/JtregNativeHotspot.gmk >> --- a/make/test/JtregNativeHotspot.gmk? Mon May 13 16:43:47 2019 +0200 >> +++ b/make/test/JtregNativeHotspot.gmk? Mon May 13 08:13:11 2019 -0700 >> @@ -864,7 +864,7 @@ >> ? ? ? BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exestack-gap := -ljvm >> -lpthread >> ? ? ? BUILD_TEST_exeinvoke_exeinvoke.c_OPTIMIZATION := NONE >> ? ? ? BUILD_HOTSPOT_JTREG_EXECUTABLES_LIBS_exeFPRegs := -ldl >> -? ? BUILD_HOTSPOT_JTREG_LIBRARIES_LDFLAGS_libAsyncGetCallTraceTest := >> -ldl >> +? ? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libAsyncGetCallTraceTest := -ldl >> ? else >> ? ? BUILD_HOTSPOT_JTREG_EXCLUDE += libtest-rw.c libtest-rwx.c >> libTestJNI.c \ >> ? ? ? ? exeinvoke.c exestack-gap.c libAsyncGetCallTraceTest.cpp >> >> Important note: it passes with or without this patch on my dev machine >> but? ? Aleksey Shipilev saw the failure and saw that the patch helps. So I >> think this should be done; I'm sending it to the submit-repo at the same >> time. >> >> Thanks, >> Jc >> >> >> >> > > -- > > Thanks, > Jc > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From just.mychris at googlemail.com Mon May 13 21:38:32 2019 From: just.mychris at googlemail.com (Chris) Date: Mon, 13 May 2019 23:38:32 +0200 Subject: JVMTI ExceptionCatch event clarification Message-ID: <96510b52-76ea-5ece-d87d-b090abb8e6a1@googlemail.com> Hi, I hope this is the correct mailing list, if not, please guide me to the one I should use. If I understand the JVMTI ExceptionCatch event correctly, an event should be generated if a native method catches an exception. The docs say: "If the exception is caught in a native method, the event is generated as soon as control is returned to a Java programming language method." I am not able to see this behavior, if a JNI method catches a Java exception using the "ExceptionClear" JNI function (or is there another way to catch an exception in native code?). My test scenario is as follows: Java method *main* calls the native method *native0*, which calls the Java method *throwing*. *throwing* throws an exception, and *native0* clears the exception (by calling "ExceptionClear") before returning. According to the documentation, a JVMTI event should be generated, after *native0* returned, but this is not the case. The exception catch event is never generated. Please see the reproducing example at the end of this mail. My assumption is, that the example produces an output like: MAIN THROW! CATCH! THROW! CATCH! But the actual output, with an OpenJDK 8, and OpenJDK 11 HotSpot JVM, is: MAIN THROW! THROW! CATCH! Java versions (download from adoptopenjdk.net): openjdk version "1.8.0_212" OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03) OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b03, mixed mode) openjdk version "11.0.3" 2019-04-16 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode) running on Arch Linux: $ uname -srvmo Linux 5.0.13-arch1-1-ARCH #1 SMP PREEMPT Sun May 5 18:05:41 UTC 2019 x86_64 GNU/Linux Could you please elaborate if my assumption about the behavior is correct? If not, is there a way to get a callback if the "ExceptionClear" function catches an Exception in native code (beside using the JNI Function Interception feature)? If my assumption is correct and this is an actual bug, could you please point me to the correct place to submit a bug report? Thanks, Christoph ======================================================================== // Test.java class Test { public static void main(String... args) throws Exception { System.out.println("MAIN"); try { native0(true); } catch (UnsupportedOperationException t) {} try { native0(false); } catch (UnsupportedOperationException t) {} } public static void throwing() { throw new UnsupportedOperationException(); } public static native void native0(boolean doCatch); } ======================================================================== ======================================================================== // test.cpp #include #include void JNICALL on_exception(jvmtiEnv*, JNIEnv*, jthread, jmethodID, jlocation, jobject, jmethodID, jlocation) { printf("THROW!\n"); } void JNICALL on_exception_catch(jvmtiEnv*, JNIEnv*, jthread, jmethodID, jlocation, jobject) { printf("CATCH!\n"); } JNIEXPORT jint JNICALL Agent_OnLoad(JavaVM* jvm, char* options, void* reserved) { jvmtiEnv* jvmti; jvm->GetEnv((void**) &jvmti, JVMTI_VERSION); jvmtiCapabilities requiredCaps = {}; requiredCaps.can_generate_exception_events = 1; jvmti->AddCapabilities(&requiredCaps); jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_EXCEPTION, NULL); jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_EXCEPTION_CATCH, NULL); jvmtiEventCallbacks eventCallbacks = {}; eventCallbacks.Exception = on_exception; eventCallbacks.ExceptionCatch = on_exception_catch; jvmti->SetEventCallbacks(&eventCallbacks, sizeof(eventCallbacks)); return 0; } extern "C" JNIEXPORT void JNICALL Java_Test_native0(JNIEnv* jni, jclass klass, jboolean do_catch) { jmethodID throwingMethod; throwingMethod = jni->GetStaticMethodID(klass,"throwing","()V"); jni->CallStaticVoidMethod(klass, throwingMethod); if (jni->ExceptionCheck() == JNI_TRUE && do_catch == JNI_TRUE) jni->ExceptionClear(); } ======================================================================== From serguei.spitsyn at oracle.com Tue May 14 05:07:29 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 13 May 2019 22:07:29 -0700 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> Message-ID: <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue May 14 05:34:56 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 15:34:56 +1000 Subject: JVMTI ExceptionCatch event clarification In-Reply-To: <96510b52-76ea-5ece-d87d-b090abb8e6a1@googlemail.com> References: <96510b52-76ea-5ece-d87d-b090abb8e6a1@googlemail.com> Message-ID: <8829b41e-e5e8-574f-dade-9a30bccf10ac@oracle.com> Hi Chris, On 14/05/2019 7:38 am, Chris wrote: > Hi, > > I hope this is the correct mailing list, if not, please guide me to the > one I should use. This is absolutely the right list. > If I understand the JVMTI ExceptionCatch event correctly, an event > should be generated if a native method catches an exception. The docs say: > > "If the exception is caught in a native method, the event is generated > as soon as control is returned to a Java programming language method." > > I am not able to see this behavior, if a JNI method catches a Java > exception using the "ExceptionClear" JNI function (or is there another > way to catch an exception in native code?). My test scenario is as follows: > > Java method *main* calls the native method *native0*, which calls the > Java method *throwing*. *throwing* throws an exception, and *native0* > clears the exception (by calling "ExceptionClear") before returning. > According to the documentation, a JVMTI event should be generated, after > ?*native0* returned, but this is not the case. The exception catch > event is never generated. Please see the reproducing example at the end > of this mail. > > My assumption is, that the example produces an output like: > > MAIN > THROW! > CATCH! > THROW! > CATCH! > > But the actual output, with an OpenJDK 8, and OpenJDK 11 HotSpot JVM, is: > > MAIN > THROW! > THROW! > CATCH! I can see the code in jni_ExceptionClear clearly setting that the exception has been caught. So the question is whether the reporting aspect of this is buggy ... I'm looking at: JvmtiExport::notice_unwind_due_to_exception and it looks wrong to me. It only does the callback if we're in the exception handler frame - which handles the "caught by Java" case. AFAICS it should also be doing the callback if we're not in the handler frame and the exception is already marked caught. So yes I would say this is a bug. I filed: https://bugs.openjdk.java.net/browse/JDK-8223812 "JVM TI ExceptionCatch event is not posted when an exception is caught by a native method" Fix seems simple enough. Cheers, David ----- > Java versions (download from adoptopenjdk.net): > > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_212-b03) > OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.212-b03, mixed mode) > > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7) > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode) > > running on Arch Linux: > > $ uname -srvmo > Linux 5.0.13-arch1-1-ARCH #1 SMP PREEMPT Sun May 5 18:05:41 UTC 2019 > x86_64 GNU/Linux > > Could you please elaborate if my assumption about the behavior is correct? > If not, is there a way to get a callback if the "ExceptionClear" > function catches an Exception in native code (beside using the JNI > Function Interception feature)? > If my assumption is correct and this is an actual bug, could you please > point me to the correct place to submit a bug report? > > Thanks, Christoph > > ======================================================================== > // Test.java > class Test { > ??? public static void main(String... args) throws Exception { > ??????? System.out.println("MAIN"); > ??????? try { > ??????????? native0(true); > ??????? } catch (UnsupportedOperationException t) {} > ??????? try { > ??????????? native0(false); > ??????? } catch (UnsupportedOperationException t) {} > ??? } > > ??? public static void throwing() { > ??????? throw new UnsupportedOperationException(); > ??? } > > ??? public static native void native0(boolean doCatch); > } > ======================================================================== > > ======================================================================== > // test.cpp > #include > #include > > void JNICALL > on_exception(jvmtiEnv*, JNIEnv*, jthread, jmethodID, jlocation, jobject, > ???????????? jmethodID, jlocation) { > ??? printf("THROW!\n"); > } > > void JNICALL > on_exception_catch(jvmtiEnv*, JNIEnv*, jthread, jmethodID, jlocation, > ?????????????????? jobject) { > ??? printf("CATCH!\n"); > } > > JNIEXPORT jint JNICALL > Agent_OnLoad(JavaVM* jvm, char* options, void* reserved) { > ??? jvmtiEnv* jvmti; > ??? jvm->GetEnv((void**) &jvmti, JVMTI_VERSION); > > ??? jvmtiCapabilities requiredCaps = {}; > ??? requiredCaps.can_generate_exception_events = 1; > ??? jvmti->AddCapabilities(&requiredCaps); > > ??? jvmti->SetEventNotificationMode(JVMTI_ENABLE, > ??????????????????????????????????? JVMTI_EVENT_EXCEPTION, NULL); > ??? jvmti->SetEventNotificationMode(JVMTI_ENABLE, > ??????????????????????????????????? JVMTI_EVENT_EXCEPTION_CATCH, NULL); > > ??? jvmtiEventCallbacks eventCallbacks = {}; > ??? eventCallbacks.Exception = on_exception; > ??? eventCallbacks.ExceptionCatch = on_exception_catch; > ??? jvmti->SetEventCallbacks(&eventCallbacks, sizeof(eventCallbacks)); > > ??? return 0; > } > > extern "C" JNIEXPORT void JNICALL > Java_Test_native0(JNIEnv* jni, jclass klass, jboolean do_catch) { > ??? jmethodID throwingMethod; > ??? throwingMethod = jni->GetStaticMethodID(klass,"throwing","()V"); > ??? jni->CallStaticVoidMethod(klass, throwingMethod); > ??? if (jni->ExceptionCheck() == JNI_TRUE && do_catch == JNI_TRUE) > ??????? jni->ExceptionClear(); > } > ======================================================================== From david.holmes at oracle.com Tue May 14 06:04:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 16:04:54 +1000 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> Message-ID: <49c3eaeb-80bc-74c5-eb1a-c4012bf3082f@oracle.com> Hi Osamu, On 13/05/2019 6:06 pm, Osamu Sakamoto wrote: > Hi David, > > Thank you for updating the CSR. > I agree with filing a RFE to improve the general jhsdb help output. > > Could you file the RFE? (I can't access JBS.) https://bugs.openjdk.java.net/browse/JDK-8223814 "8223814: SA: jhsdb common help needs to be more detailed" > I would like to contribute it if the RFE will be filed. > > My proposal (webrev.00) has been reviewed by Yasumasa and JC. > So I will request Yasumasa to push it to jdk/jdk when the status of CSR > changes to Approved, and RFE for jhsdb help is filed. Okay, but please wait for Serguei's approval as well. Thanks, David > > Thanks, > Osamu > > > On 5/13/19 16:00, David Holmes wrote: >> >> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>> Hi, David >>> >>> I saw your comment in this CSR. >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>> >>> I understand that the problem is that the help description of debugd >>> I proposed and current other modes is not helpful for users. >>> >>> What should we do to go through this CSR? >>> IMHO we should update help description of all jhsdb modes more helpful. >>> Do you have any ideas about this? >> >> I think a RFE should be filed to improve the general jhsdb help >> output, so that it explains that --pid and --exe are mutually >> exclusive options. That way this CSR, and thus the associated RFE can >> proceed. I'll add the same info the CSR. >> >> Thanks, >> David >> >>> Thanks, >>> Osamu >>> >>> >>> On 5/10/19 17:46, ?? ? wrote: >>>> Hi, >>>> >>>> I agree with Yasumasa's opinion in CSR. >>>> >>>> I wrote new debugd format and usage to match other modes(jstack, >>>> jmap and so on) in jhdsb. >>>> Certainly, usage of debugd which I proposed does not explain that >>>> and cannot be used together, but it is not limited to >>>> debugd - other modes have similar issue. >>>> >>>> I think it is helpful to detail help description in each jhsdb >>>> modes, but I'd like to separate as another issue because this is not >>>> limited to debugd. >>>> >>>> -----Original Message----- >>>> From: Yasumasa Suenaga >>>> Sent: Friday, May 10, 2019 4:08 PM >>>> To: David Holmes >>>> Cc: Jean Christophe Beyler ; >>>> serviceability-dev at openjdk.java.net >>>> serviceability-dev at openjdk.java.net >>>> ; ?? ? >>>> >>>> Subject: Re: debugd options should regard to jhsdb style >>>> >>>> Hi David, >>>> >>>> Thank you for checking in CSR, and sorry for my incorrect description. >>>> I added my opinion to CSR. >>>> >>>> Osamu, do you have any opinion? >>>> >>>> >>>> Yasumasa >>>> >>>> >>>> 2019?5?10?(?) 15:16 David Holmes : >>>>> >>>>> Hi Yasumasa, >>>>> >>>>> I've made some updates to the CSR request and raised a couple of >>>>> issues. >>>>> >>>>> FYI the specification section only needs to contain the actual >>>>> specification for what has changed ie the new command-line options; >>>>> not the implementation that will bring about those changes. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>> Thanks JC! >>>>>> >>>>>> I added key point of this change to specification section in CSR. >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler : >>>>>>> >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>> specification section could use some text and then send the reader >>>>>>> to the other bug entry :) Jc >>>>>>> >>>>>>> From: Yasumasa Suenaga >>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> >>>>>>>> tests on submit repo have been passed >>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>> >>>>>>>> Could you review the CSR? >>>>>>>> >>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Osamu, your change looks good to me. >>>>>>>>> I will sponsor you. >>>>>>>>> >>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>> >>>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>> >>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>> >>>>>>>>> ???? http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>>> suspect that historically the form of this command was done to >>>>>>>>>> match other tools. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>> >>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>> --pid `. >>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>> >>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>> >>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>> proposal has been merged. >>>>>>>>>>> >>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Osamu >>>>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thanks, >>>>>>> Jc From zanglin5 at jd.com Tue May 14 06:46:55 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Tue, 14 May 2019 06:46:55 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <32BE694F-58A4-4BC0-88A9-9295FE9411F6@amazon.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> , <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> Message-ID: <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> Dear Serguei, Thanks for your comments. > > - incremental[:], enable the incremental dump of heap, dumped > > data will be saved to, by default it is "IncrementalHisto.dump" > > Q1: Should the be full path or short name? > Is there any default path? What is the path of the > "IncrementalHisto.dump" file? The original design doesn't have the option so the file is hardcoded named "IncrementalHisto.dump" and save to the same path as "file=" specified. Or print to whatever output stream is if "file=" is not set. With the new design, I suggest firstly parse , if the value contains folder path, use the specified path, if not, use same path as "file=" value, and if "file=" is not set, use output stream. (The reason I prefer to use same path as "file=" is I assume that users prefer to save all data file under the same folder.) > > - chunksize=, size of objects (in KB) will be dumped in one chunk. > > Q2: Should it be chunk of dump, not chunk of objects? The purpose of "chunksize" is to decide how many objects' info are dumped at once. for example use "chunksize=1" on a "Xmx1m", there will be at max 1MB/1KB = 1000 chunks, which indicates that there will be 1000 times of file writing when do "jmap -histo". > > - maxfilesize=, size of the incremental data dump file (in KB), when data size > > is larger than maxfilesize, the file is erased and latest data will be written. > Q3: What is a relation and limitations between chunksize and maxfilesize? > Should the maxfilesize be multiple of the chunksize? > Q4: The sentence "the file is erased and latest data will be written" is not clear enough. > Why the whole file needs to be erased > Should the incremental file behave like a cyclic buffer? > If so, then only next chunk needs to be erased. > Then the chunks need to be numbered in order, so the earliest one can be found. The "maxfilesize" controls the file size not to be too large, so when the dumped data is larger than "maxfilesize", the file is erased and latest data are written.The reason I erase whole file is that chunk data is accumulative, so the latest data includes the previous statistical ones. And this way may make the file easy to read. I agree that we can add ordered number in chunks, I think it more or less help user to get to know how object distributed in heap. I think maybe it is reasonable to have the incremental file behave like gclog, when maxfilesize is reached, the file is renamed with numbered suffix, and new file is created to use. so there can be IncrementalHisto.dump.0 and IncrementalHisto.dump.1 etc for large heap. what do you think? Thanks, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Saturday, May 11, 2019 2:17:41 AM To: ??; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear Lin, Sorry for the late reply. I've edited the CSR a little bit to fix some incorrect spots. Now, a couple of spots are not clear to me. > - incremental[:], enable the incremental dump of heap, dumped >?? data will be saved to, by default it is "IncrementalHisto.dump" Q1: Should the be full path or short name? Is there any default path? What is the path of the "IncrementalHisto.dump" file? > - chunksize=, size of objects (in KB) will be dumped in one chunk. Q2: Should it be chunk of dump, not chunk of objects? > - maxfilesize=, size of the incremental data dump file (in KB), when data size >?? is larger than maxfilesize, the file is erased and latest data will be written. Q3: What is a relation and limitations between chunksize and maxfilesize? Should the maxfilesize be multiple of the chunksize? Q4: The sentence "the file is erased and latest data will be written" is not clear enough. Why the whole file needs to be erased Should the incremental file behave like a cyclic buffer? If so, then only next chunk needs to be erased. Then the chunks need to be numbered in order, so the earliest one can be found. (I do not want you to accept my suggestions right away. It is just a discussion point. You need to prove that your approach is good and clean enough.) If we resolve the questions (or get into agreement) then I'll update the CSR as needed. Thanks, Serguei On 5/5/19 00:34, ?? wrote: > Dear All, > I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8222319 > May I ask your help to review it? > When it is finalized, I will refine the webrev. > > BRs, > Lin > >> Dear Serguei? >> Thanks a lot for your reviewing. >> >> >> >>> System.err.println(" incremental dump support:"); >>> + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); >>> + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); >>> >>> >>> From this description is not clear at all what does the chunkcount mean. >>> Is it to define how many heap objects are dumped in one chunk? >>> If so, would it better to name it chunksize instead where chunksize is measured in heap objects? >>> Then would it better to use the same units to define the maxfilesize as well? >>> (I'm not insisting on this, just asking.) >> The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. >> For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and >> when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. >> >> The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. >> Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. >> BRs, >> Lin From david.holmes at oracle.com Tue May 14 07:13:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 14 May 2019 17:13:40 +1000 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> Message-ID: Hi Serguei, For the delay in getting back to this. Everything seems fine to me now. Thanks, David ----- On 10/05/2019 7:16 pm, serguei.spitsyn at oracle.com wrote: > Hi David, > > I've noticed a minor problem in the jvmti.html diff below: > > 5c5 > JVM(TM) Tool Interface 11.0.0 > --- > >???????? JVM(TM) Tool Interface 13.0.0 > 30c30 > Version 11.0 > --- > >????????????

Version 13.0

> 34931c34931 > --- > >???????????????? Version: 13.0.0 > > > There should not be the last difference as this is the version of last > JVMTI spec update: > > *11.0.0* > 7 February 2018 Minor update for new class file NestHost and > NestMembers attributes: - Specify that RedefineClasses and > RetransformClasses are not allowed to change the class file NestHost and > NestMembers attributes. - Add new error > JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED that can be > returned by RedefineClasses and RetransformClasses. > > > > I've updated the webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ > > The newly updated file is: > || src/hotspot/share/prims/jvmti.xml > > which has this change: > > + > + > + > + > + > + > + > + > >
>
>

Change History

> Last update:
> - Version: > + Version: > > > New jvmti.html diff is: > 5c5 > JVM(TM) Tool Interface 11.0.0 > --- > >???????? JVM(TM) Tool Interface 13.0.0 > 30c30 > Version 11.0 > --- > >????????????

Version 13.0

> > > Thanks, > Serguei > > > On 5/10/19 01:03, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 5/9/19 18:51, David Holmes wrote: >>> Hi Serguei, >>> >>> On 10/05/2019 10:32 am, serguei.spitsyn at oracle.com wrote: >>>> I've updated the webrev v2 in place. >>> >>> ?make/hotspot/gensrc/GensrcJvmti.gmk >>> >>> You don't need to pass through: -PARAM minorversion $(VERSION_INTERIM) >> >> Good catch. >> How did I missed to remove? >> >> >>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >>> >>> >>> ?57???? private static final int minorVersion = >>> Runtime.version().interim(); >>> >>> That should be kept at 0. >> >> Okay, fixed. >> >> New webrev is: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ >> >> >>> >>> I'd like to see an actual diff of the generated jvmti.h and >>> jvmti.html files as well please. Some of the XSL stuff looks odd to me. >> >> The jvmti.h diff: >> >> 2c2 >> > rights reserved. >> --- >> >? * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >> rights reserved. >> 47c47 >> > /* version: 11.0.0 */ >> --- >> >???? JVMTI_VERSION = 0x30000000 + (13 * 0x10000) + ( 0 * 0x100) + 0 >> /* version: 13.0.0 */ >> >> >> >> The jvmti.html diff: >> >> 5c5 >> JVM(TM) Tool Interface 11.0.0 >> --- >> >???????? JVM(TM) Tool Interface 13.0.0 >> 30c30 >> Version 11.0 >> --- >> >????????????

Version 13.0

>> 34931c34931 >> > --- >> >???????????????? Version: 13.0.0 >> >> >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/9/19 17:28, serguei.spitsyn at oracle.com wrote: >>>>> David and Jc, >>>>> >>>>> Okay, I'll remove this line now. >>>>> Thank you for your comments. >>>>> >>>>> Let's let Jc to file a separate enhancement on this. >>>>> Then I'll file a CSR and prepare a fix. >>>>> >>>>> I hope, you both are Okay with the rest. >>>>> >>>>> Thanks! >>>>> Serguei >>>>> >>>>> >>>>> On 5/9/19 17:17, Jean Christophe Beyler wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> Adding to the difficulties that David is exposing, this won't >>>>>> work. You need to redo the xls definition because you need the >>>>>> #define to be the numeric value directly and not the enum; >>>>>> otherwise it won't work in any usable way at preprocessor time sadly. >>>>>> >>>>>> I think it makes sense to just do what you were planning to do >>>>>> here without this and I'll file a bug and work out the CSR path >>>>>> and review path separately and see what is do-able or not then >>>>>> because I think it's too much work now "just for this now" if that >>>>>> makes sense :) >>>>>> Jc >>>>>> >>>>>> *From: *David Holmes >>>>> > >>>>>> *Date: *Thu, May 9, 2019 at 5:11 PM >>>>>> *To: *serguei.spitsyn at oracle.com >>>>>> , Jean Christophe Beyler >>>>>> *Cc: *serviceability-dev >>>>>> >>>>>> ??? On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com >>>>>> wrote: >>>>>> ??? > Hi Jc, >>>>>> ??? > >>>>>> ??? > Okay, you convinced me - thanks! >>>>>> ??? > Added new line into the generated jvmti.h: >>>>>> ??? > >>>>>> ??? >? ? #define JVMTI_VERSION_LATEST JVMTI_VERSION >>>>>> >>>>>> ??? That requires a CSR as you are expanding the exported interface. >>>>>> >>>>>> ??? Also you need >>>>>> >>>>>> ??? #define JVMTI_VERSION_LATEST (JVMTI_VERSION) >>>>>> >>>>>> ??? as JVMTI_VERSION is itself an expression not a constant. That >>>>>> might >>>>>> ??? limit the utility of having such a define as you won't be able to >>>>>> ??? use it >>>>>> ??? in an ifdef guard to test a value AFAICS. >>>>>> >>>>>> ??? David >>>>>> >>>>>> ??? > I hope, it will help in your case. >>>>>> ??? > >>>>>> ??? > >>>>>> ??? > Updated webrev version is: >>>>>> ??? > >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ >>>>>> >>>>>> ??? > >>>>>> ??? > >>>>>> ??? > This version includes suggestions from David. >>>>>> ??? > >>>>>> ??? > Thanks, >>>>>> ??? > Serguei >>>>>> ??? > >>>>>> ??? > >>>>>> ??? > >>>>>> ??? > On 5/9/19 14:17, Jean Christophe Beyler wrote: >>>>>> ??? >> Hi Serguei, >>>>>> ??? >> >>>>>> ??? >> Of course I can :) >>>>>> ??? >> >>>>>> ??? >> Consider, just randomly of course, the heap sampling work that >>>>>> ??? got >>>>>> ??? >> added to JVMTI. Now imagine you'd want to test if it is >>>>>> ??? supported by a >>>>>> ??? >> given JVMTI version, you would write something like this: >>>>>> ??? >> >>>>>> ??? >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >>>>>> ??? >> ? jvmtiCapabilities caps; >>>>>> ??? >> ? memset(&caps, 0, sizeof(caps)); >>>>>> ??? >> ? if (jvmti->GetPotentialCapabilities(&caps) != >>>>>> ??? JVMTI_ERROR_NONE) { >>>>>> ??? >> ? ? LOG(WARNING) << "Failed to get potential capabilities, >>>>>> ??? disabling >>>>>> ??? >> the heap " >>>>>> ??? >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >>>>>> ??? >> ? ? return false; >>>>>> ??? >> ? } >>>>>> ??? >> >>>>>> ??? >> ? return caps.can_generate_sampled_object_alloc_events >>>>>> ??? >> ? ? ? && caps.can_generate_garbage_collection_events; >>>>>> ??? >> } >>>>>> ??? >> >>>>>> ??? >> Now, the problem is that this code cannot be used if you >>>>>> ??? compile with >>>>>> ??? >> an older JDK such as JDK8 for example >>>>>> ??? >> because?can_generate_sampled_object_alloc_events does not >>>>>> ??? exist yet >>>>>> ??? >> for that jvmti.h file. >>>>>> ??? >> >>>>>> ??? >> >>>>>> ??? >> In a perfect world, we might imagine that we are always >>>>>> ??? compiling with >>>>>> ??? >> the latest JVMTI headers but that is not always true and, >>>>>> ??? therefore, >>>>>> ??? >> to have the code portable, we now have to do: >>>>>> ??? >> >>>>>> ??? >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >>>>>> ??? >> #ifdef ENABLE_HEAP_SAMPLING >>>>>> ??? >> ? jvmtiCapabilities caps; >>>>>> ??? >> ? memset(&caps, 0, sizeof(caps)); >>>>>> ??? >> ? if (jvmti->GetPotentialCapabilities(&caps) != >>>>>> ??? JVMTI_ERROR_NONE) { >>>>>> ??? >> ? ? LOG(WARNING) << "Failed to get potential capabilities, >>>>>> ??? disabling >>>>>> ??? >> the heap " >>>>>> ??? >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >>>>>> ??? >> ? ? return false; >>>>>> ??? >> ? } >>>>>> ??? >> >>>>>> ??? >> ? return caps.can_generate_sampled_object_alloc_events >>>>>> ??? >> ? ? ? && caps.can_generate_garbage_collection_events; >>>>>> ??? >> #else >>>>>> ??? >> ? return false; >>>>>> ??? >> #endif >>>>>> ??? >> } >>>>>> ??? >> >>>>>> ??? >> Where ENABLE_HEAP_SAMPLING is defined if we did compile with >>>>>> ??? JDK11 and >>>>>> ??? >> not defined if we compiled with JDK8. I can't use >>>>>> JVMTI_VERSION >>>>>> ??? >> because I can't use it in an #if because it is not an enum. >>>>>> ??? Were it to >>>>>> ??? >> be a #define or were I to have a #define I could use with a >>>>>> ??? version >>>>>> ??? >> number being bumped up, I could write something such as: >>>>>> ??? >> >>>>>> ??? >> #ifdef JVMTI_VERSION_11 >>>>>> ??? >> >>>>>> ??? >> or something that looks in the value of the JVMTI_VERSION if I >>>>>> ??? wanted. >>>>>> ??? >> Right now, I can't even do that! >>>>>> ??? >> >>>>>> ??? >> Hopefully this helps understand what I am talking about :-), >>>>>> ??? >> Jc >>>>>> ??? >> >>>>>> ??? >> >>>>>> ??? >> >>>>>> ??? >> >>>>>> ??? >> On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com >>>>>> >>>>>> ??? >> >>>>> > >>>>> >>>>>> ??? >> >>>>> >> wrote: >>>>>> ??? >> >>>>>> ??? >>? ? ?Hi Jc, >>>>>> ??? >> >>>>>> ??? >>? ? ?Thank you a lot for review! >>>>>> ??? >>? ? ?Some replies below. >>>>>> ??? >> >>>>>> ??? >> >>>>>> ??? >>? ? ?On 5/9/19 09:10, Jean Christophe Beyler wrote: >>>>>> ??? >>>? ? ?Hi Serguei, >>>>>> ??? >>> >>>>>> ??? >>>? ? ?FWIW, the change looks good and I think it's a good idea >>>>>> ??? to do. >>>>>> ??? >>>? ? ?However, there is one thorn in our internal agent code is >>>>>> ??? that >>>>>> ??? >>>? ? ?the JVMTI_VERSION is in an enum. This makes us unable to >>>>>> ??? #if it >>>>>> ??? >>>? ? ?when adding usages of newer features/methods. >>>>>> ??? >>> >>>>>> ??? >>>? ? ?This probably could/should be a different webrev (which I >>>>>> ??? can do >>>>>> ??? >>>? ? ?if you like) but is there any way while you are >>>>>> changing this >>>>>> ??? >>>? ? ?that the enum for JVMTI_VERSION could become a set of >>>>>> ??? #define? >>>>>> ??? >>> >>>>>> ??? >>>? ? ?So instead of: >>>>>> ??? >>>? ? ?enum { >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1? ?= 0x30010000, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_0 = 0x30010000, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_1 = 0x30010100, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_2 = 0x30010200, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_9? ?= 0x30090000, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_11? = 0x300B0000, >>>>>> ??? >>> >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * >>>>>> ??? 0x100) + >>>>>> ??? >>>? ? ?0? /* version: 11.0.0 */ >>>>>> ??? >>>? ? ?}; >>>>>> ??? >>> >>>>>> ??? >>>? ? ?We would get: >>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1 0x30010000 >>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_0 0x30010000 >>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_1 = 0x30010100 >>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_2 = 0x30010200 >>>>>> ??? >>>? ? ?#define JVMTI_VERSION_9? ?= 0x30090000 >>>>>> ??? >>>? ? ?#define JVMTI_VERSION_11? = 0x300B0000 >>>>>> ??? >>>? ? ?#define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + (0 * >>>>>> ??? 0x100) >>>>>> ??? >>>? ? ?+ 0? /* version: 11.0.0 */) >>>>>> ??? >> >>>>>> ??? >>? ? ?It is interesting concern and suggestion. >>>>>> ??? >>? ? ?I'm not sure if it requires a CSR. >>>>>> ??? >> >>>>>> ??? >> >>>>>> ??? >>>? ? ?I actually don't care about any define of these except >>>>>> for >>>>>> ??? >>>? ? ?JVMTI_VERSION; basically it would be useful so that in >>>>>> ??? our agent >>>>>> ??? >>>? ? ?code we can test the JVMTI_VERSION with #if macros to >>>>>> ??? protect the >>>>>> ??? >>>? ? ?code when new elements show up in future versions. So >>>>>> it also >>>>>> ??? >>>? ? ?could be: >>>>>> ??? >>>? ? ?enum { >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1? ?= 0x30010000, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_0 = 0x30010000, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_1 = 0x30010100, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_2 = 0x30010200, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_9? ?= 0x30090000, >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_11? = 0x300B0000, >>>>>> ??? >>> >>>>>> ??? >>>? ? ?? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * >>>>>> ??? 0x100) + >>>>>> ??? >>>? ? ?0? /* version: 11.0.0 */ >>>>>> ??? >>>? ? ?}; >>>>>> ??? >>> >>>>>> ??? >>>? ? ?#define JVMTI_LATEST_VERSION (0x30000000 + (11 * 0x10000) >>>>>> ??? + (0 * >>>>>> ??? >>>? ? ?0x100) + 0? /* version: 11.0.0 */) >>>>>> ??? >> >>>>>> ??? >>? ? ?I is not a problem to implement this one. >>>>>> ??? >>? ? ?But I'm not sure how does this really help in your case. >>>>>> ??? >>? ? ?I do not see a point to test the JVMTI_VERSION with #if as >>>>>> ??? it is >>>>>> ??? >>? ? ?always defined. >>>>>> ??? >>? ? ?Could you, please, elaborate a little bit more? >>>>>> ??? >> >>>>>> ??? >>? ? ?Thanks, >>>>>> ??? >>? ? ?Serguei >>>>>> ??? >> >>>>>> ??? >>>? ? ?Right now, I have to do weird things where I detect the >>>>>> ??? jvmti.h >>>>>> ??? >>>? ? ?used at compile time to then do -DUSING_JDK11 for the >>>>>> ??? agent at >>>>>> ??? >>>? ? ?compile time. >>>>>> ??? >>> >>>>>> ??? >>>? ? ?Thanks! >>>>>> ??? >>>? ? ?Jc >>>>>> ??? >>> >>>>>> ??? >>> >>>>>> ??? >>> >>>>>> ??? >>> >>>>>> ??? >>>? ? ?On Thu, May 9, 2019 at 8:48 AM serguei.spitsyn at oracle.com >>>>>> >>>>>> ??? >>>? ? ?>>>>> > >>>>> >>>>>> ??? >>>? ? ?>>>>> >> wrote: >>>>>> ??? >>> >>>>>> ??? >>>? ? ? ? ?I'll try to get rid of VERSION_INTERIM. >>>>>> ??? >>>? ? ? ? ?Always using just VERSION_FEATURE.0.0 should not >>>>>> ??? create problems >>>>>> ??? >>>? ? ? ? ?if we do not change JVMTI spec in VERSION_UPDATE. >>>>>> ??? >>>? ? ? ? ?I do not see why we would change the JVMTI spec in >>>>>> update >>>>>> ??? >>>? ? ? ? ?releases. >>>>>> ??? >>>? ? ? ? ?But if we do then using VERSION_UPDATE as >>>>>> ??? microversion would >>>>>> ??? >>>? ? ? ? ?be good enough. >>>>>> ??? >>> >>>>>> ??? >>>? ? ? ? ?Thanks! >>>>>> ??? >>>? ? ? ? ?Serguei >>>>>> ??? >>> >>>>>> ??? >>> >>>>>> ??? >>>? ? ? ? ?On 5/9/19 06:13, David Holmes wrote: >>>>>> ??? >>>? ? ? ? ?> Hi Serguei, >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com >>>>>> >>>>>> ??? >>> ?>>>>> > wrote: >>>>>> ??? >>>? ? ? ? ?>> Hi David, >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> Thank you a lot for review! >>>>>> ??? >>>? ? ? ? ?>> There are some replies below. >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> On 5/8/19 18:42, David Holmes wrote: >>>>>> ??? >>>? ? ? ? ?>>> Hi Serguei, >>>>>> ??? >>>? ? ? ? ?>>> >>>>>> ??? >>>? ? ? ? ?>>> On 9/05/2019 8:57 am, serguei.spitsyn at oracle.com >>>>>> >>>>>> ??? >>> ?>>>>> ???? > wrote: >>>>>> ??? >>>? ? ? ? ?>>>> Please, review a fix for the task: >>>>>> ??? >>>? ? ? ? ?>>>> https://bugs.openjdk.java.net/browse/JDK-8219023 >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>>? ? ? ? ?>>>> Webrev: >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>> >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >>>>>> >>>>>> ??? >>> >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>>? ? ? ? ?>>>> Summary: >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>>? ? ? ? ?>>>> ??By design as we have never bumped the JVMTI >>>>>> ??? version unless >>>>>> ??? >>>? ? ? ? ?>>>> ??there were spec changes for that release. Now >>>>>> ??? we want >>>>>> ??? >>>? ? ? ? ?to sync >>>>>> ??? >>>? ? ? ? ?>>>> ??the JVMTI version with the JDK version >>>>>> ??? regardless of >>>>>> ??? >>>? ? ? ? ?whether >>>>>> ??? >>>? ? ? ? ?>>>> ??or not spec changes have occurred in that >>>>>> release. >>>>>> ??? >>>? ? ? ? ?>>>> ??Also, we want it automatically set by the >>>>>> ??? build system >>>>>> ??? >>>? ? ? ? ?so that >>>>>> ??? >>>? ? ? ? ?>>>> ??no manual updates are needed for each release. >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>>? ? ? ? ?>>>> ??The jvmti.h and jvmti.html (JVMTI spec) are >>>>>> ??? generated from >>>>>> ??? >>>? ? ? ? ?>>>> ??the jvmti.xsl with the XSLT scripts now. So, >>>>>> ??? the fix >>>>>> ??? >>>? ? ? ? ?removes >>>>>> ??? >>>? ? ? ? ?>>>> ??hard coded major, minor and micro versions >>>>>> ??? from the >>>>>> ??? >>>? ? ? ? ?jvmti.xml >>>>>> ??? >>>? ? ? ? ?>>>> ??and passes major and minor parameters with the >>>>>> ??? -PARAMETER >>>>>> ??? >>>? ? ? ? ?>>>> ??to the XSL transformation. >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>>? ? ? ? ?>>>> ??Another part of the fix is in the JDI which >>>>>> starts >>>>>> ??? >>>? ? ? ? ?using JDK >>>>>> ??? >>>? ? ? ? ?>>>> ??versions now instead of maintaining its own, >>>>>> ??? and in >>>>>> ??? >>>? ? ? ? ?the JDWP >>>>>> ??? >>>? ? ? ? ?>>>> ??agent which is using the JVMTI versions >>>>>> ??? instead of its >>>>>> ??? >>>? ? ? ? ?own. >>>>>> ??? >>>? ? ? ? ?>>> >>>>>> ??? >>>? ? ? ? ?>>> This all seems reasonable (though I'm no >>>>>> expert on >>>>>> ??? >>>? ? ? ? ?working with XSL >>>>>> ??? >>>? ? ? ? ?>>> etc). >>>>>> ??? >>>? ? ? ? ?>>> >>>>>> ??? >>>? ? ? ? ?>>> One thing I am unclear of is why you bother with >>>>>> ??? using >>>>>> ??? >>>? ? ? ? ?>>> VERSION_INTERIM when the actual version check >>>>>> ??? will only >>>>>> ??? >>>? ? ? ? ?consider >>>>>> ??? >>>? ? ? ? ?>>> VERSION_FEATURE (aka major). Couldn't you just >>>>>> ??? leave the >>>>>> ??? >>>? ? ? ? ?"minor" >>>>>> ??? >>>? ? ? ? ?>>> part 0 the same as the "micro" part? >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> This is right question to ask. >>>>>> ??? >>>? ? ? ? ?>> I was two-folded on this. >>>>>> ??? >>>? ? ? ? ?>> But finally decided to maintain minor version (aka >>>>>> ??? >>>? ? ? ? ?VERSION_INTERIM). >>>>>> ??? >>>? ? ? ? ?>> Then the JVMTI and debugger version will match the >>>>>> ??? VM and >>>>>> ??? >>>? ? ? ? ?JDK version >>>>>> ??? >>>? ? ? ? ?>> for update releases. >>>>>> ??? >>>? ? ? ? ?>> If understand it correctly, we are still going >>>>>> to have >>>>>> ??? >>>? ? ? ? ?major.minor >>>>>> ??? >>>? ? ? ? ?>> versions. >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> Not really. What we have now are things like >>>>>> 11.0.3 and >>>>>> ??? >>>? ? ? ? ?12.0.1 - only >>>>>> ??? >>>? ? ? ? ?> using the first and third parts. The full 4 part >>>>>> ??? version >>>>>> ??? >>>? ? ? ? ?string is: >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>> >>>>>> ?$VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> and we typically only update version_feature and >>>>>> ??? >>>? ? ? ? ?version_update. >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> https://openjdk.java.net/jeps/322 >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?>> Also, the JVMTI GetVersionNumberspec still >>>>>> tells about >>>>>> ??? >>>? ? ? ? ?both minor and >>>>>> ??? >>>? ? ? ? ?>> micro versions. >>>>>> ??? >>>? ? ? ? ?>> It also defines special constants for >>>>>> ??? corresponding masks >>>>>> ??? >>>? ? ? ? ?and shifts: >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> ??? Version Masks >>>>>> ??? >>>? ? ? ? ?>> ??? Constant???? Value Description >>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 >>>>>> ??? >>>? ? ? ? ?Mask to >>>>>> ??? >>>? ? ? ? ?>> extract >>>>>> ??? >>>? ? ? ? ?>> ??? interface type. The value of the version >>>>>> ??? returned by >>>>>> ??? >>>? ? ? ? ?this function >>>>>> ??? >>>? ? ? ? ?>> ??? masked with >>>>>> ??? |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always >>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_INTERFACE_JVMTI| since this is a >>>>>> JVMTI >>>>>> ??? >>>? ? ? ? ?function. >>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000???? Mask to >>>>>> ??? >>>? ? ? ? ?extract major >>>>>> ??? >>>? ? ? ? ?>> ??? version number. >>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00???? Mask to >>>>>> ??? >>>? ? ? ? ?extract minor >>>>>> ??? >>>? ? ? ? ?>> ??? version number. >>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MICRO| 0x000000FF???? Mask to >>>>>> ??? >>>? ? ? ? ?extract micro >>>>>> ??? >>>? ? ? ? ?>> ??? version number. >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> ??? Version Shifts >>>>>> ??? >>>? ? ? ? ?>> ??? Constant???? Value Description >>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MAJOR|???? 16 Shift to >>>>>> ??? extract major >>>>>> ??? >>>? ? ? ? ?>> version number. >>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MINOR|???? 8 Shift to extract >>>>>> ??? minor >>>>>> ??? >>>? ? ? ? ?>> version number. >>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MICRO|???? 0 Shift to extract >>>>>> ??? micro >>>>>> ??? >>>? ? ? ? ?>> version number. >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> This is link to the spec: >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>> >>>>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber >>>>>> >>>>>> ??? >>> >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> It seems, changing (and/or deprecating) this >>>>>> will give >>>>>> ??? >>>? ? ? ? ?more problems >>>>>> ??? >>>? ? ? ? ?>> than benefits. >>>>>> ??? >>>? ? ? ? ?>> It is better to remain compatible with previous >>>>>> ??? releases. >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> This is a problem that was flagged when the new >>>>>> ??? versioning >>>>>> ??? >>>? ? ? ? ?scheme was >>>>>> ??? >>>? ? ? ? ?> introduced but I'm guessing nothing was actually >>>>>> ??? done about >>>>>> ??? >>>? ? ? ? ?it. They >>>>>> ??? >>>? ? ? ? ?> are not really compatible beyond the major/feature >>>>>> ??? part. >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> If we only update the spec version with the feature >>>>>> ??? version >>>>>> ??? >>>? ? ? ? ?then all >>>>>> ??? >>>? ? ? ? ?> versions will have the form N.0.0. However your >>>>>> changes >>>>>> ??? >>>? ? ? ? ?will also >>>>>> ??? >>>? ? ? ? ?> update if we happen to use a VERSION_INTERIM for >>>>>> some >>>>>> ??? >>>? ? ? ? ?reason - though >>>>>> ??? >>>? ? ? ? ?> the version check will ignore that anyway. I'm not >>>>>> ??? really >>>>>> ??? >>>? ? ? ? ?seeing the >>>>>> ??? >>>? ? ? ? ?> point in having that happen. >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> Maybe we do need to define a new version API that >>>>>> ??? maps to >>>>>> ??? >>>? ? ? ? ?the new >>>>>> ??? >>>? ? ? ? ?> versioning scheme of OpenJDK ? But if we did >>>>>> that we'd >>>>>> ??? >>>? ? ? ? ?still have to >>>>>> ??? >>>? ? ? ? ?> support the legacy mapping and I'd still advocate >>>>>> ??? simply using >>>>>> ??? >>>? ? ? ? ?> VERSION_FEATURE.0.0. >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> It's tricky. >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?> David >>>>>> ??? >>>? ? ? ? ?> ----- >>>>>> ??? >>>? ? ? ? ?> >>>>>> ??? >>>? ? ? ? ?>>> For the record I considered whether this needs >>>>>> a CSR >>>>>> ??? >>>? ? ? ? ?request and >>>>>> ??? >>>? ? ? ? ?>>> concluded it did not as it doesn't involve >>>>>> ??? changing any >>>>>> ??? >>>? ? ? ? ?actual >>>>>> ??? >>>? ? ? ? ?>>> specifications. >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> Okay, thanks. >>>>>> ??? >>>? ? ? ? ?>> I considered it too, made the same conclusion but >>>>>> ??? still >>>>>> ??? >>>? ? ? ? ?have some >>>>>> ??? >>>? ? ? ? ?>> doubt. :) >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>> Thanks! >>>>>> ??? >>>? ? ? ? ?>> Serguei >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>>? ? ? ? ?>>> >>>>>> ??? >>>? ? ? ? ?>>> Thanks, >>>>>> ??? >>>? ? ? ? ?>>> David >>>>>> ??? >>>? ? ? ? ?>>> >>>>>> ??? >>>? ? ? ? ?>>>> Testing: >>>>>> ??? >>>? ? ? ? ?>>>> ??Generated docs and jvmti.h and checked the >>>>>> ??? versions >>>>>> ??? >>>? ? ? ? ?are correct. >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>>? ? ? ? ?>>>> One could ask if we have to use same or similar >>>>>> ??? approach for >>>>>> ??? >>>? ? ? ? ?>>>> other API's and tools, like JNI, JMX and so on. >>>>>> ??? >>>? ? ? ? ?>>>> But these are not areas of my expertise or >>>>>> ??? responsibility. >>>>>> ??? >>>? ? ? ? ?>>>> It just feels like there is some room for >>>>>> ??? unification here. >>>>>> ??? >>>? ? ? ? ?>>>> >>>>>> ??? >>>? ? ? ? ?>>>> Thanks, >>>>>> ??? >>>? ? ? ? ?>>>> Serguei >>>>>> ??? >>>? ? ? ? ?>> >>>>>> ??? >>> >>>>>> ??? >>> >>>>>> ??? >>> >>>>>> ??? >>>? ? ?-- >>>>>> ??? >>> >>>>>> ??? >>>? ? ?Thanks, >>>>>> ??? >>>? ? ?Jc >>>>>> ??? >> >>>>>> ??? >> >>>>>> ??? >> >>>>>> ??? >> -- >>>>>> ??? >> >>>>>> ??? >> Thanks, >>>>>> ??? >> Jc >>>>>> ??? > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc >>>>> >>>> >> > From sakamoto.osamu at nttcom.co.jp Tue May 14 07:21:50 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Tue, 14 May 2019 16:21:50 +0900 Subject: debugd options should regard to jhsdb style In-Reply-To: <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> Message-ID: <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> Hi Serguei, Thank you for reviewing the CSR. I answer your questions. Q1 & Q2: and can accept both full path and relative path. Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently have the same format, and need not to be updated. By the way, you've added angle brackets to jhsdb debugd --help in the CSR. But current other commands --help don't have it. I think this modification should be also added to other commands --help if it is added to debugd --help. This CSR relates on only debugd, so I think this modification should be included to the RFE which David filed.(JDK-8223814) What do you think about this? Yasumasa has uploaded webrev.00.1 that angle bracket is added to debugd --help. I will request him to push the better one when this is clear Thanks, Osamu On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: > Hi Osamu, > > Sorry for reacting on this so late. > This work on cmd-line options unification is very welcome! > > I looked at the CSR and it looks pretty good in general. > > I've added angle brackets to the jhsdb debugd --help: > > |$ jhsdb debugd --help --serverid > --exe --core --pid process to attach> But this needs to be unified with other commands |||(clhsdb, hsdb, jstack, etc|), of course. | > > Also, added a comment with the questions: > > |Q1: Should the be always a full path name or it > can be a relative path? Q2: Should the be always a > full path name or it can be a relative path? Q3: Do all other commans > (clhsdb, hsdb, jstack, jmap, etc.) currently have the same format or > they also need to be updated?| > > > I can update the CSR description if you answer these questions. > They'll file an RFE for this. > > Thanks, > Serguei > > > > On 5/13/19 01:06, Osamu Sakamoto wrote: >> Hi David, >> >> Thank you for updating the CSR. >> I agree with filing a RFE to improve the general jhsdb help output. >> >> Could you file the RFE? (I can't access JBS.) >> I would like to contribute it if the RFE will be filed. >> >> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >> So I will request Yasumasa to push it to jdk/jdk when the status of >> CSR changes to Approved, and RFE for jhsdb help is filed. >> >> Thanks, >> Osamu >> >> >> On 5/13/19 16:00, David Holmes wrote: >>> >>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>> Hi, David >>>> >>>> I saw your comment in this CSR. >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>> >>>> I understand that the problem is that the help description of debugd >>>> I proposed and current other modes is not helpful for users. >>>> >>>> What should we do to go through this CSR? >>>> IMHO we should update help description of all jhsdb modes more helpful. >>>> Do you have any ideas about this? >>> >>> I think a RFE should be filed to improve the general jhsdb help >>> output, so that it explains that --pid and --exe are mutually >>> exclusive options. That way this CSR, and thus the associated RFE can >>> proceed. I'll add the same info the CSR. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/10/19 17:46, ?? ? wrote: >>>>> Hi, >>>>> >>>>> I agree with Yasumasa's opinion in CSR. >>>>> >>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>> jmap and so on) in jhdsb. >>>>> Certainly, usage of debugd which I proposed does not explain that >>>>> and cannot be used together, but it is not limited to >>>>> debugd - other modes have similar issue. >>>>> >>>>> I think it is helpful to detail help description in each jhsdb >>>>> modes, but I'd like to separate as another issue because this is >>>>> not limited to debugd. >>>>> >>>>> -----Original Message----- >>>>> From: Yasumasa Suenaga >>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>> To: David Holmes >>>>> Cc: Jean Christophe Beyler ; >>>>> serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> ; ?? ? >>>>> >>>>> Subject: Re: debugd options should regard to jhsdb style >>>>> >>>>> Hi David, >>>>> >>>>> Thank you for checking in CSR, and sorry for my incorrect description. >>>>> I added my opinion to CSR. >>>>> >>>>> Osamu, do you have any opinion? >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> I've made some updates to the CSR request and raised a couple of >>>>>> issues. >>>>>> >>>>>> FYI the specification section only needs to contain the actual >>>>>> specification for what has changed ie the new command-line options; >>>>>> not the implementation that will bring about those changes. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>> Thanks JC! >>>>>>> >>>>>>> I added key point of this change to specification section in CSR. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>> : >>>>>>>> >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>> specification section could use some text and then send the reader >>>>>>>> to the other bug entry :) Jc >>>>>>>> >>>>>>>> From: Yasumasa Suenaga >>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>> >>>>>>>>> tests on submit repo have been passed >>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>> >>>>>>>>> Could you review the CSR? >>>>>>>>> >>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>> I will sponsor you. >>>>>>>>>> >>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>> >>>>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>> >>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>> to match other tools. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>> >>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>> --pid `. >>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>> >>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>> >>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>> >>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Osamu >>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jc > From sakamoto.osamu at nttcom.co.jp Tue May 14 07:34:11 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Tue, 14 May 2019 16:34:11 +0900 Subject: debugd options should regard to jhsdb style In-Reply-To: <49c3eaeb-80bc-74c5-eb1a-c4012bf3082f@oracle.com> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <49c3eaeb-80bc-74c5-eb1a-c4012bf3082f@oracle.com> Message-ID: <5efdc914-bf4b-7601-64bf-dd3a2ad7eb81@nttcom.co.jp> Hi David, Thank you for filing the RFE. > Okay, but please wait for Serguei's approval as well. Okay, I wait for his approval. I will try to this RFE when the CSR is approved. Thanks, Osamu On 5/14/19 15:04, David Holmes wrote: > Hi Osamu, > > On 13/05/2019 6:06 pm, Osamu Sakamoto wrote: >> Hi David, >> >> Thank you for updating the CSR. >> I agree with filing a RFE to improve the general jhsdb help output. >> >> Could you file the RFE? (I can't access JBS.) > > https://bugs.openjdk.java.net/browse/JDK-8223814 > > "8223814: SA: jhsdb common help needs to be more detailed" > >> I would like to contribute it if the RFE will be filed. >> >> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >> So I will request Yasumasa to push it to jdk/jdk when the status of >> CSR changes to Approved, and RFE for jhsdb help is filed. > > Okay, but please wait for Serguei's approval as well. > > Thanks, > David > >> >> Thanks, >> Osamu >> >> >> On 5/13/19 16:00, David Holmes wrote: >>> >>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>> Hi, David >>>> >>>> I saw your comment in this CSR. >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>> >>>> I understand that the problem is that the help description of debugd >>>> I proposed and current other modes is not helpful for users. >>>> >>>> What should we do to go through this CSR? >>>> IMHO we should update help description of all jhsdb modes more helpful. >>>> Do you have any ideas about this? >>> >>> I think a RFE should be filed to improve the general jhsdb help >>> output, so that it explains that --pid and --exe are mutually >>> exclusive options. That way this CSR, and thus the associated RFE can >>> proceed. I'll add the same info the CSR. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/10/19 17:46, ?? ? wrote: >>>>> Hi, >>>>> >>>>> I agree with Yasumasa's opinion in CSR. >>>>> >>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>> jmap and so on) in jhdsb. >>>>> Certainly, usage of debugd which I proposed does not explain that >>>>> and cannot be used together, but it is not limited to >>>>> debugd - other modes have similar issue. >>>>> >>>>> I think it is helpful to detail help description in each jhsdb >>>>> modes, but I'd like to separate as another issue because this is >>>>> not limited to debugd. >>>>> >>>>> -----Original Message----- >>>>> From: Yasumasa Suenaga >>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>> To: David Holmes >>>>> Cc: Jean Christophe Beyler ; >>>>> serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> ; ?? ? >>>>> >>>>> Subject: Re: debugd options should regard to jhsdb style >>>>> >>>>> Hi David, >>>>> >>>>> Thank you for checking in CSR, and sorry for my incorrect description. >>>>> I added my opinion to CSR. >>>>> >>>>> Osamu, do you have any opinion? >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> I've made some updates to the CSR request and raised a couple of >>>>>> issues. >>>>>> >>>>>> FYI the specification section only needs to contain the actual >>>>>> specification for what has changed ie the new command-line options; >>>>>> not the implementation that will bring about those changes. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>> Thanks JC! >>>>>>> >>>>>>> I added key point of this change to specification section in CSR. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>> : >>>>>>>> >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>> specification section could use some text and then send the reader >>>>>>>> to the other bug entry :) Jc >>>>>>>> >>>>>>>> From: Yasumasa Suenaga >>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>> >>>>>>>>> tests on submit repo have been passed >>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>> >>>>>>>>> Could you review the CSR? >>>>>>>>> >>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>> I will sponsor you. >>>>>>>>>> >>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>> >>>>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>> >>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>> >>>>>>>>>> ???? http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>> to match other tools. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>> >>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>> --pid `. >>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>> >>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>> >>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>> >>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Osamu >>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jc From serguei.spitsyn at oracle.com Tue May 14 10:12:40 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 May 2019 03:12:40 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> Message-ID: <54317f28-452b-be6b-6593-7b51a5552b84@oracle.com> Hi David, Thank you a lot! Serguei On 5/14/19 00:13, David Holmes wrote: > Hi Serguei, > > For the delay in getting back to this. Everything seems fine to me now. > > Thanks, > David > ----- > > On 10/05/2019 7:16 pm, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> I've noticed a minor problem in the jvmti.html diff below: >> >> 5c5 >> JVM(TM) Tool Interface 11.0.0 >> --- >> ?>???????? JVM(TM) Tool Interface 13.0.0 >> 30c30 >> Version 11.0 >> --- >> ?>????????????

Version 13.0

>> 34931c34931 >> > --- >> ?>???????????????? Version: 13.0.0 >> >> >> There should not be the last difference as this is the version of >> last JVMTI spec update: >> >> *11.0.0* >> 7 February 2018???? Minor update for new class file NestHost and >> NestMembers attributes: - Specify that RedefineClasses and >> RetransformClasses are not allowed to change the class file NestHost >> and NestMembers attributes. - Add new error >> JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED that can >> be returned by RedefineClasses and RetransformClasses. >> >> >> >> I've updated the webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ >> >> The newly updated file is: >> || src/hotspot/share/prims/jvmti.xml >> >> which has this change: >> >> + >> + >> + >> + >> + >> + >> + >> + >> ? >> ?????
>> ?????
>> ?????

Change History

>> ????? Last update:
>> - Version: >> + Version: >> >> >> New jvmti.html diff is: >> 5c5 >> JVM(TM) Tool Interface 11.0.0 >> --- >> ?>???????? JVM(TM) Tool Interface 13.0.0 >> 30c30 >> Version 11.0 >> --- >> ?>????????????

Version 13.0

>> >> >> Thanks, >> Serguei >> >> >> On 5/10/19 01:03, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 5/9/19 18:51, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 10/05/2019 10:32 am, serguei.spitsyn at oracle.com wrote: >>>>> I've updated the webrev v2 in place. >>>> >>>> ?make/hotspot/gensrc/GensrcJvmti.gmk >>>> >>>> You don't need to pass through: -PARAM minorversion $(VERSION_INTERIM) >>> >>> Good catch. >>> How did I missed to remove? >>> >>> >>>> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java >>>> >>>> >>>> ?57???? private static final int minorVersion = >>>> Runtime.version().interim(); >>>> >>>> That should be kept at 0. >>> >>> Okay, fixed. >>> >>> New webrev is: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ >>> >>> >>> >>>> >>>> I'd like to see an actual diff of the generated jvmti.h and >>>> jvmti.html files as well please. Some of the XSL stuff looks odd to >>>> me. >>> >>> The jvmti.h diff: >>> >>> 2c2 >>> >> rights reserved. >>> --- >>> >? * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All >>> rights reserved. >>> 47c47 >>> >> /* version: 11.0.0 */ >>> --- >>> >???? JVMTI_VERSION = 0x30000000 + (13 * 0x10000) + ( 0 * 0x100) + >>> 0? /* version: 13.0.0 */ >>> >>> >>> >>> The jvmti.html diff: >>> >>> 5c5 >>> JVM(TM) Tool Interface 11.0.0 >>> --- >>> >???????? JVM(TM) Tool Interface 13.0.0 >>> 30c30 >>> Version 11.0 >>> --- >>> >????????????

Version 13.0

>>> 34931c34931 >>> >> --- >>> >???????????????? Version: 13.0.0 >>> >>> >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 5/9/19 17:28, serguei.spitsyn at oracle.com wrote: >>>>>> David and Jc, >>>>>> >>>>>> Okay, I'll remove this line now. >>>>>> Thank you for your comments. >>>>>> >>>>>> Let's let Jc to file a separate enhancement on this. >>>>>> Then I'll file a CSR and prepare a fix. >>>>>> >>>>>> I hope, you both are Okay with the rest. >>>>>> >>>>>> Thanks! >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 5/9/19 17:17, Jean Christophe Beyler wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Adding to the difficulties that David is exposing, this won't >>>>>>> work. You need to redo the xls definition because you need the >>>>>>> #define to be the numeric value directly and not the enum; >>>>>>> otherwise it won't work in any usable way at preprocessor time >>>>>>> sadly. >>>>>>> >>>>>>> I think it makes sense to just do what you were planning to do >>>>>>> here without this and I'll file a bug and work out the CSR path >>>>>>> and review path separately and see what is do-able or not then >>>>>>> because I think it's too much work now "just for this now" if >>>>>>> that makes sense :) >>>>>>> Jc >>>>>>> >>>>>>> *From: *David Holmes >>>>>> > >>>>>>> *Date: *Thu, May 9, 2019 at 5:11 PM >>>>>>> *To: *serguei.spitsyn at oracle.com >>>>>>> , Jean Christophe Beyler >>>>>>> *Cc: *serviceability-dev >>>>>>> >>>>>>> ??? On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com >>>>>>> wrote: >>>>>>> ??? > Hi Jc, >>>>>>> ??? > >>>>>>> ??? > Okay, you convinced me - thanks! >>>>>>> ??? > Added new line into the generated jvmti.h: >>>>>>> ??? > >>>>>>> ??? >? ? #define JVMTI_VERSION_LATEST JVMTI_VERSION >>>>>>> >>>>>>> ??? That requires a CSR as you are expanding the exported >>>>>>> interface. >>>>>>> >>>>>>> ??? Also you need >>>>>>> >>>>>>> ??? #define JVMTI_VERSION_LATEST (JVMTI_VERSION) >>>>>>> >>>>>>> ??? as JVMTI_VERSION is itself an expression not a constant. >>>>>>> That might >>>>>>> ??? limit the utility of having such a define as you won't be >>>>>>> able to >>>>>>> ??? use it >>>>>>> ??? in an ifdef guard to test a value AFAICS. >>>>>>> >>>>>>> ??? David >>>>>>> >>>>>>> ??? > I hope, it will help in your case. >>>>>>> ??? > >>>>>>> ??? > >>>>>>> ??? > Updated webrev version is: >>>>>>> ??? > >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ >>>>>>> >>>>>>> ??? > >>>>>>> ??? > >>>>>>> ??? > This version includes suggestions from David. >>>>>>> ??? > >>>>>>> ??? > Thanks, >>>>>>> ??? > Serguei >>>>>>> ??? > >>>>>>> ??? > >>>>>>> ??? > >>>>>>> ??? > On 5/9/19 14:17, Jean Christophe Beyler wrote: >>>>>>> ??? >> Hi Serguei, >>>>>>> ??? >> >>>>>>> ??? >> Of course I can :) >>>>>>> ??? >> >>>>>>> ??? >> Consider, just randomly of course, the heap sampling work >>>>>>> that >>>>>>> ??? got >>>>>>> ??? >> added to JVMTI. Now imagine you'd want to test if it is >>>>>>> ??? supported by a >>>>>>> ??? >> given JVMTI version, you would write something like this: >>>>>>> ??? >> >>>>>>> ??? >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >>>>>>> ??? >> ? jvmtiCapabilities caps; >>>>>>> ??? >> ? memset(&caps, 0, sizeof(caps)); >>>>>>> ??? >> ? if (jvmti->GetPotentialCapabilities(&caps) != >>>>>>> ??? JVMTI_ERROR_NONE) { >>>>>>> ??? >> ? ? LOG(WARNING) << "Failed to get potential capabilities, >>>>>>> ??? disabling >>>>>>> ??? >> the heap " >>>>>>> ??? >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >>>>>>> ??? >> ? ? return false; >>>>>>> ??? >> ? } >>>>>>> ??? >> >>>>>>> ??? >> ? return caps.can_generate_sampled_object_alloc_events >>>>>>> ??? >> ? ? ? && caps.can_generate_garbage_collection_events; >>>>>>> ??? >> } >>>>>>> ??? >> >>>>>>> ??? >> Now, the problem is that this code cannot be used if you >>>>>>> ??? compile with >>>>>>> ??? >> an older JDK such as JDK8 for example >>>>>>> ??? >> because?can_generate_sampled_object_alloc_events does not >>>>>>> ??? exist yet >>>>>>> ??? >> for that jvmti.h file. >>>>>>> ??? >> >>>>>>> ??? >> >>>>>>> ??? >> In a perfect world, we might imagine that we are always >>>>>>> ??? compiling with >>>>>>> ??? >> the latest JVMTI headers but that is not always true and, >>>>>>> ??? therefore, >>>>>>> ??? >> to have the code portable, we now have to do: >>>>>>> ??? >> >>>>>>> ??? >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { >>>>>>> ??? >> #ifdef ENABLE_HEAP_SAMPLING >>>>>>> ??? >> ? jvmtiCapabilities caps; >>>>>>> ??? >> ? memset(&caps, 0, sizeof(caps)); >>>>>>> ??? >> ? if (jvmti->GetPotentialCapabilities(&caps) != >>>>>>> ??? JVMTI_ERROR_NONE) { >>>>>>> ??? >> ? ? LOG(WARNING) << "Failed to get potential capabilities, >>>>>>> ??? disabling >>>>>>> ??? >> the heap " >>>>>>> ??? >> ? ? ? ? ? ? ? ? ?<< "sampling monitor"; >>>>>>> ??? >> ? ? return false; >>>>>>> ??? >> ? } >>>>>>> ??? >> >>>>>>> ??? >> ? return caps.can_generate_sampled_object_alloc_events >>>>>>> ??? >> ? ? ? && caps.can_generate_garbage_collection_events; >>>>>>> ??? >> #else >>>>>>> ??? >> ? return false; >>>>>>> ??? >> #endif >>>>>>> ??? >> } >>>>>>> ??? >> >>>>>>> ??? >> Where ENABLE_HEAP_SAMPLING is defined if we did compile with >>>>>>> ??? JDK11 and >>>>>>> ??? >> not defined if we compiled with JDK8. I can't use >>>>>>> JVMTI_VERSION >>>>>>> ??? >> because I can't use it in an #if because it is not an enum. >>>>>>> ??? Were it to >>>>>>> ??? >> be a #define or were I to have a #define I could use with a >>>>>>> ??? version >>>>>>> ??? >> number being bumped up, I could write something such as: >>>>>>> ??? >> >>>>>>> ??? >> #ifdef JVMTI_VERSION_11 >>>>>>> ??? >> >>>>>>> ??? >> or something that looks in the value of the JVMTI_VERSION >>>>>>> if I >>>>>>> ??? wanted. >>>>>>> ??? >> Right now, I can't even do that! >>>>>>> ??? >> >>>>>>> ??? >> Hopefully this helps understand what I am talking about :-), >>>>>>> ??? >> Jc >>>>>>> ??? >> >>>>>>> ??? >> >>>>>>> ??? >> >>>>>>> ??? >> >>>>>>> ??? >> On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com >>>>>>> >>>>>>> ??? >> >>>>>> > >>>>>> >>>>>>> ??? >> >>>>>> >> wrote: >>>>>>> ??? >> >>>>>>> ??? >>? ? ?Hi Jc, >>>>>>> ??? >> >>>>>>> ??? >>? ? ?Thank you a lot for review! >>>>>>> ??? >>? ? ?Some replies below. >>>>>>> ??? >> >>>>>>> ??? >> >>>>>>> ??? >>? ? ?On 5/9/19 09:10, Jean Christophe Beyler wrote: >>>>>>> ??? >>>? ? ?Hi Serguei, >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?FWIW, the change looks good and I think it's a good >>>>>>> idea >>>>>>> ??? to do. >>>>>>> ??? >>>? ? ?However, there is one thorn in our internal agent >>>>>>> code is >>>>>>> ??? that >>>>>>> ??? >>>? ? ?the JVMTI_VERSION is in an enum. This makes us >>>>>>> unable to >>>>>>> ??? #if it >>>>>>> ??? >>>? ? ?when adding usages of newer features/methods. >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?This probably could/should be a different webrev >>>>>>> (which I >>>>>>> ??? can do >>>>>>> ??? >>>? ? ?if you like) but is there any way while you are >>>>>>> changing this >>>>>>> ??? >>>? ? ?that the enum for JVMTI_VERSION could become a set of >>>>>>> ??? #define? >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?So instead of: >>>>>>> ??? >>>? ? ?enum { >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1? ?= 0x30010000, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_0 = 0x30010000, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_1 = 0x30010100, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_2 = 0x30010200, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_9? ?= 0x30090000, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_11? = 0x300B0000, >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * >>>>>>> ??? 0x100) + >>>>>>> ??? >>>? ? ?0? /* version: 11.0.0 */ >>>>>>> ??? >>>? ? ?}; >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?We would get: >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1 0x30010000 >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_0 0x30010000 >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_1 = 0x30010100 >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_2 = 0x30010200 >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_9? ?= 0x30090000 >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_11? = 0x300B0000 >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + >>>>>>> (0 * >>>>>>> ??? 0x100) >>>>>>> ??? >>>? ? ?+ 0? /* version: 11.0.0 */) >>>>>>> ??? >> >>>>>>> ??? >>? ? ?It is interesting concern and suggestion. >>>>>>> ??? >>? ? ?I'm not sure if it requires a CSR. >>>>>>> ??? >> >>>>>>> ??? >> >>>>>>> ??? >>>? ? ?I actually don't care about any define of these >>>>>>> except for >>>>>>> ??? >>>? ? ?JVMTI_VERSION; basically it would be useful so that in >>>>>>> ??? our agent >>>>>>> ??? >>>? ? ?code we can test the JVMTI_VERSION with #if macros to >>>>>>> ??? protect the >>>>>>> ??? >>>? ? ?code when new elements show up in future versions. >>>>>>> So it also >>>>>>> ??? >>>? ? ?could be: >>>>>>> ??? >>>? ? ?enum { >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1? ?= 0x30010000, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_0 = 0x30010000, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_1 = 0x30010100, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_1_2 = 0x30010200, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_9? ?= 0x30090000, >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION_11? = 0x300B0000, >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?? ? JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * >>>>>>> ??? 0x100) + >>>>>>> ??? >>>? ? ?0? /* version: 11.0.0 */ >>>>>>> ??? >>>? ? ?}; >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?#define JVMTI_LATEST_VERSION (0x30000000 + (11 * >>>>>>> 0x10000) >>>>>>> ??? + (0 * >>>>>>> ??? >>>? ? ?0x100) + 0? /* version: 11.0.0 */) >>>>>>> ??? >> >>>>>>> ??? >>? ? ?I is not a problem to implement this one. >>>>>>> ??? >>? ? ?But I'm not sure how does this really help in your case. >>>>>>> ??? >>? ? ?I do not see a point to test the JVMTI_VERSION with >>>>>>> #if as >>>>>>> ??? it is >>>>>>> ??? >>? ? ?always defined. >>>>>>> ??? >>? ? ?Could you, please, elaborate a little bit more? >>>>>>> ??? >> >>>>>>> ??? >>? ? ?Thanks, >>>>>>> ??? >>? ? ?Serguei >>>>>>> ??? >> >>>>>>> ??? >>>? ? ?Right now, I have to do weird things where I detect the >>>>>>> ??? jvmti.h >>>>>>> ??? >>>? ? ?used at compile time to then do -DUSING_JDK11 for the >>>>>>> ??? agent at >>>>>>> ??? >>>? ? ?compile time. >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?Thanks! >>>>>>> ??? >>>? ? ?Jc >>>>>>> ??? >>> >>>>>>> ??? >>> >>>>>>> ??? >>> >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?On Thu, May 9, 2019 at 8:48 AM >>>>>>> serguei.spitsyn at oracle.com >>>>>>> >>>>>>> ??? >>> ?>>>>>> > >>>>>> >>>>>>> ??? >>> ?>>>>>> >> wrote: >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ? ? ?I'll try to get rid of VERSION_INTERIM. >>>>>>> ??? >>>? ? ? ? ?Always using just VERSION_FEATURE.0.0 should not >>>>>>> ??? create problems >>>>>>> ??? >>>? ? ? ? ?if we do not change JVMTI spec in VERSION_UPDATE. >>>>>>> ??? >>>? ? ? ? ?I do not see why we would change the JVMTI spec >>>>>>> in update >>>>>>> ??? >>>? ? ? ? ?releases. >>>>>>> ??? >>>? ? ? ? ?But if we do then using VERSION_UPDATE as >>>>>>> ??? microversion would >>>>>>> ??? >>>? ? ? ? ?be good enough. >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ? ? ?Thanks! >>>>>>> ??? >>>? ? ? ? ?Serguei >>>>>>> ??? >>> >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ? ? ?On 5/9/19 06:13, David Holmes wrote: >>>>>>> ??? >>>? ? ? ? ?> Hi Serguei, >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com >>>>>>> >>>>>>> ??? >>> ?>>>>>> > wrote: >>>>>>> ??? >>>? ? ? ? ?>> Hi David, >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> Thank you a lot for review! >>>>>>> ??? >>>? ? ? ? ?>> There are some replies below. >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> On 5/8/19 18:42, David Holmes wrote: >>>>>>> ??? >>>? ? ? ? ?>>> Hi Serguei, >>>>>>> ??? >>>? ? ? ? ?>>> >>>>>>> ??? >>>? ? ? ? ?>>> On 9/05/2019 8:57 am, >>>>>>> serguei.spitsyn at oracle.com >>>>>>> >>>>>>> ??? >>> ?>>>>>> ???? > wrote: >>>>>>> ??? >>>? ? ? ? ?>>>> Please, review a fix for the task: >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219023 >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>>? ? ? ? ?>>>> Webrev: >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>> >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ >>>>>>> >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>>? ? ? ? ?>>>> Summary: >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>>? ? ? ? ?>>>> ??By design as we have never bumped the JVMTI >>>>>>> ??? version unless >>>>>>> ??? >>>? ? ? ? ?>>>> ??there were spec changes for that release. >>>>>>> Now >>>>>>> ??? we want >>>>>>> ??? >>>? ? ? ? ?to sync >>>>>>> ??? >>>? ? ? ? ?>>>> ??the JVMTI version with the JDK version >>>>>>> ??? regardless of >>>>>>> ??? >>>? ? ? ? ?whether >>>>>>> ??? >>>? ? ? ? ?>>>> ??or not spec changes have occurred in that >>>>>>> release. >>>>>>> ??? >>>? ? ? ? ?>>>> ??Also, we want it automatically set by the >>>>>>> ??? build system >>>>>>> ??? >>>? ? ? ? ?so that >>>>>>> ??? >>>? ? ? ? ?>>>> ??no manual updates are needed for each >>>>>>> release. >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>>? ? ? ? ?>>>> ??The jvmti.h and jvmti.html (JVMTI spec) are >>>>>>> ??? generated from >>>>>>> ??? >>>? ? ? ? ?>>>> ??the jvmti.xsl with the XSLT scripts now. So, >>>>>>> ??? the fix >>>>>>> ??? >>>? ? ? ? ?removes >>>>>>> ??? >>>? ? ? ? ?>>>> ??hard coded major, minor and micro versions >>>>>>> ??? from the >>>>>>> ??? >>>? ? ? ? ?jvmti.xml >>>>>>> ??? >>>? ? ? ? ?>>>> ??and passes major and minor parameters >>>>>>> with the >>>>>>> ??? -PARAMETER >>>>>>> ??? >>>? ? ? ? ?>>>> ??to the XSL transformation. >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>>? ? ? ? ?>>>> ??Another part of the fix is in the JDI >>>>>>> which starts >>>>>>> ??? >>>? ? ? ? ?using JDK >>>>>>> ??? >>>? ? ? ? ?>>>> ??versions now instead of maintaining its own, >>>>>>> ??? and in >>>>>>> ??? >>>? ? ? ? ?the JDWP >>>>>>> ??? >>>? ? ? ? ?>>>> ??agent which is using the JVMTI versions >>>>>>> ??? instead of its >>>>>>> ??? >>>? ? ? ? ?own. >>>>>>> ??? >>>? ? ? ? ?>>> >>>>>>> ??? >>>? ? ? ? ?>>> This all seems reasonable (though I'm no >>>>>>> expert on >>>>>>> ??? >>>? ? ? ? ?working with XSL >>>>>>> ??? >>>? ? ? ? ?>>> etc). >>>>>>> ??? >>>? ? ? ? ?>>> >>>>>>> ??? >>>? ? ? ? ?>>> One thing I am unclear of is why you bother >>>>>>> with >>>>>>> ??? using >>>>>>> ??? >>>? ? ? ? ?>>> VERSION_INTERIM when the actual version check >>>>>>> ??? will only >>>>>>> ??? >>>? ? ? ? ?consider >>>>>>> ??? >>>? ? ? ? ?>>> VERSION_FEATURE (aka major). Couldn't you just >>>>>>> ??? leave the >>>>>>> ??? >>>? ? ? ? ?"minor" >>>>>>> ??? >>>? ? ? ? ?>>> part 0 the same as the "micro" part? >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> This is right question to ask. >>>>>>> ??? >>>? ? ? ? ?>> I was two-folded on this. >>>>>>> ??? >>>? ? ? ? ?>> But finally decided to maintain minor version >>>>>>> (aka >>>>>>> ??? >>>? ? ? ? ?VERSION_INTERIM). >>>>>>> ??? >>>? ? ? ? ?>> Then the JVMTI and debugger version will >>>>>>> match the >>>>>>> ??? VM and >>>>>>> ??? >>>? ? ? ? ?JDK version >>>>>>> ??? >>>? ? ? ? ?>> for update releases. >>>>>>> ??? >>>? ? ? ? ?>> If understand it correctly, we are still >>>>>>> going to have >>>>>>> ??? >>>? ? ? ? ?major.minor >>>>>>> ??? >>>? ? ? ? ?>> versions. >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> Not really. What we have now are things like >>>>>>> 11.0.3 and >>>>>>> ??? >>>? ? ? ? ?12.0.1 - only >>>>>>> ??? >>>? ? ? ? ?> using the first and third parts. The full 4 part >>>>>>> ??? version >>>>>>> ??? >>>? ? ? ? ?string is: >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>> >>>>>>> ?$VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> and we typically only update version_feature and >>>>>>> ??? >>>? ? ? ? ?version_update. >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> https://openjdk.java.net/jeps/322 >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?>> Also, the JVMTI GetVersionNumberspec still >>>>>>> tells about >>>>>>> ??? >>>? ? ? ? ?both minor and >>>>>>> ??? >>>? ? ? ? ?>> micro versions. >>>>>>> ??? >>>? ? ? ? ?>> It also defines special constants for >>>>>>> ??? corresponding masks >>>>>>> ??? >>>? ? ? ? ?and shifts: >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> ??? Version Masks >>>>>>> ??? >>>? ? ? ? ?>> ??? Constant Value Description >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 >>>>>>> ??? >>>? ? ? ? ?Mask to >>>>>>> ??? >>>? ? ? ? ?>> extract >>>>>>> ??? >>>? ? ? ? ?>> ??? interface type. The value of the version >>>>>>> ??? returned by >>>>>>> ??? >>>? ? ? ? ?this function >>>>>>> ??? >>>? ? ? ? ?>> ??? masked with >>>>>>> ??? |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_INTERFACE_JVMTI| since this is >>>>>>> a JVMTI >>>>>>> ??? >>>? ? ? ? ?function. >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000???? >>>>>>> Mask to >>>>>>> ??? >>>? ? ? ? ?extract major >>>>>>> ??? >>>? ? ? ? ?>> ??? version number. >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00???? >>>>>>> Mask to >>>>>>> ??? >>>? ? ? ? ?extract minor >>>>>>> ??? >>>? ? ? ? ?>> ??? version number. >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MICRO| 0x000000FF???? >>>>>>> Mask to >>>>>>> ??? >>>? ? ? ? ?extract micro >>>>>>> ??? >>>? ? ? ? ?>> ??? version number. >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> ??? Version Shifts >>>>>>> ??? >>>? ? ? ? ?>> ??? Constant Value Description >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MAJOR|???? 16 Shift to >>>>>>> ??? extract major >>>>>>> ??? >>>? ? ? ? ?>> version number. >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MINOR|???? 8 Shift to >>>>>>> extract >>>>>>> ??? minor >>>>>>> ??? >>>? ? ? ? ?>> version number. >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MICRO|???? 0 Shift to >>>>>>> extract >>>>>>> ??? micro >>>>>>> ??? >>>? ? ? ? ?>> version number. >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> This is link to the spec: >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>> >>>>>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber >>>>>>> >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> It seems, changing (and/or deprecating) this >>>>>>> will give >>>>>>> ??? >>>? ? ? ? ?more problems >>>>>>> ??? >>>? ? ? ? ?>> than benefits. >>>>>>> ??? >>>? ? ? ? ?>> It is better to remain compatible with previous >>>>>>> ??? releases. >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> This is a problem that was flagged when the new >>>>>>> ??? versioning >>>>>>> ??? >>>? ? ? ? ?scheme was >>>>>>> ??? >>>? ? ? ? ?> introduced but I'm guessing nothing was actually >>>>>>> ??? done about >>>>>>> ??? >>>? ? ? ? ?it. They >>>>>>> ??? >>>? ? ? ? ?> are not really compatible beyond the >>>>>>> major/feature >>>>>>> ??? part. >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> If we only update the spec version with the >>>>>>> feature >>>>>>> ??? version >>>>>>> ??? >>>? ? ? ? ?then all >>>>>>> ??? >>>? ? ? ? ?> versions will have the form N.0.0. However >>>>>>> your changes >>>>>>> ??? >>>? ? ? ? ?will also >>>>>>> ??? >>>? ? ? ? ?> update if we happen to use a VERSION_INTERIM >>>>>>> for some >>>>>>> ??? >>>? ? ? ? ?reason - though >>>>>>> ??? >>>? ? ? ? ?> the version check will ignore that anyway. I'm >>>>>>> not >>>>>>> ??? really >>>>>>> ??? >>>? ? ? ? ?seeing the >>>>>>> ??? >>>? ? ? ? ?> point in having that happen. >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> Maybe we do need to define a new version API that >>>>>>> ??? maps to >>>>>>> ??? >>>? ? ? ? ?the new >>>>>>> ??? >>>? ? ? ? ?> versioning scheme of OpenJDK ? But if we did >>>>>>> that we'd >>>>>>> ??? >>>? ? ? ? ?still have to >>>>>>> ??? >>>? ? ? ? ?> support the legacy mapping and I'd still advocate >>>>>>> ??? simply using >>>>>>> ??? >>>? ? ? ? ?> VERSION_FEATURE.0.0. >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> It's tricky. >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?> David >>>>>>> ??? >>>? ? ? ? ?> ----- >>>>>>> ??? >>>? ? ? ? ?> >>>>>>> ??? >>>? ? ? ? ?>>> For the record I considered whether this >>>>>>> needs a CSR >>>>>>> ??? >>>? ? ? ? ?request and >>>>>>> ??? >>>? ? ? ? ?>>> concluded it did not as it doesn't involve >>>>>>> ??? changing any >>>>>>> ??? >>>? ? ? ? ?actual >>>>>>> ??? >>>? ? ? ? ?>>> specifications. >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> Okay, thanks. >>>>>>> ??? >>>? ? ? ? ?>> I considered it too, made the same conclusion >>>>>>> but >>>>>>> ??? still >>>>>>> ??? >>>? ? ? ? ?have some >>>>>>> ??? >>>? ? ? ? ?>> doubt. :) >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>> Thanks! >>>>>>> ??? >>>? ? ? ? ?>> Serguei >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>>? ? ? ? ?>>> >>>>>>> ??? >>>? ? ? ? ?>>> Thanks, >>>>>>> ??? >>>? ? ? ? ?>>> David >>>>>>> ??? >>>? ? ? ? ?>>> >>>>>>> ??? >>>? ? ? ? ?>>>> Testing: >>>>>>> ??? >>>? ? ? ? ?>>>> ??Generated docs and jvmti.h and checked the >>>>>>> ??? versions >>>>>>> ??? >>>? ? ? ? ?are correct. >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>>? ? ? ? ?>>>> One could ask if we have to use same or >>>>>>> similar >>>>>>> ??? approach for >>>>>>> ??? >>>? ? ? ? ?>>>> other API's and tools, like JNI, JMX and so >>>>>>> on. >>>>>>> ??? >>>? ? ? ? ?>>>> But these are not areas of my expertise or >>>>>>> ??? responsibility. >>>>>>> ??? >>>? ? ? ? ?>>>> It just feels like there is some room for >>>>>>> ??? unification here. >>>>>>> ??? >>>? ? ? ? ?>>>> >>>>>>> ??? >>>? ? ? ? ?>>>> Thanks, >>>>>>> ??? >>>? ? ? ? ?>>>> Serguei >>>>>>> ??? >>>? ? ? ? ?>> >>>>>>> ??? >>> >>>>>>> ??? >>> >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?-- >>>>>>> ??? >>> >>>>>>> ??? >>>? ? ?Thanks, >>>>>>> ??? >>>? ? ?Jc >>>>>>> ??? >> >>>>>>> ??? >> >>>>>>> ??? >> >>>>>>> ??? >> -- >>>>>>> ??? >> >>>>>>> ??? >> Thanks, >>>>>>> ??? >> Jc >>>>>>> ??? > >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thanks, >>>>>>> Jc >>>>>> >>>>> >>> >> From Alan.Bateman at oracle.com Tue May 14 10:46:52 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2019 11:46:52 +0100 Subject: RFC: 8223740: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: <28fb2148-a8df-9637-aa80-ea5f8c5f4a6d@oracle.com> References: <28fb2148-a8df-9637-aa80-ea5f8c5f4a6d@oracle.com> Message-ID: <76cfedbe-531b-33b5-ba7c-06165aa3e93a@oracle.com> On 14/05/2019 03:36, serguei.spitsyn at oracle.com wrote: > : > > ? Java SE 9 added two abstract module-aware methods to the interface > ? java.lang.instrument.Instrumentation. The assumption at the time was > ? that the Instrumentation implementation is tightly coupled to the VM > ? implementation and it seemed unlikely there would be other > implementations > ? (this follows similar additions of abstract methods in Java SE 6). Right, Instrumentation wants to be a sealed type but doesn't have a way to express this yet. Adding a statement to the javadoc seems okay for now, I'm just wondering if it should use one of the javadoc tags created for documenting API notes [1]. Joe Darcy (cc'ed) may have input into this. It can probably be @apiNote as the statement is it documenting intention. -Alan [1] https://openjdk.java.net/jeps/8068562 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Tue May 14 14:02:36 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 14 May 2019 16:02:36 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Message-ID: Hi Dan, Full: http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html Inc: http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html On 2019-05-08 18:02, Daniel D. Daugherty wrote: > General comment - Please make sure to update all copyright years before > ????????????????? pushing this changeset. Fixed. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java > ??? L46: > ??? L47: ??? private static AddressField????? threadsField; > ??? L48: ??? private static CIntegerField???? lengthField; > ??????? nit - please delete blank line on L46 > ??????? nit - please reduce the space between type and variable names > ????????????? (I have no preference if you still keep them aligned) > > ??? nit - Please delete blank line on L74. Fixed. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java > ??? old L203: ????? Threads threads = VM.getVM().getThreads(); > ??? old L204: ????? for (JavaThread cur = threads.first(); cur != null; cur = > cur.next()) { > ??? new L203: ????? VM.getVM().getThreads().doJavaThreads((cur) -> { > ??????? In this case, you did a lambda conversion... > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java > ??? old L75: ??????????? for (JavaThread cur = threads.first(); cur != null; > cur = cur.next(), i++) { > ??? new L75: ??????????? for (int k = 0; k < threads.getNumberOfThreads(); k++) { > ??? new L76: ??????????????? JavaThread cur = threads.getJavaThreadAt(k); > ??????? In this case, you didn't do a lambda conversion... > > ??????? I'm trying to grok a reason for the different styles... > ??????? Update: Is is maybe a control flow thing? (No, I don't know much > ?????????? about lambdas.) As in: Loops that "break" or early return are > ?????????? not amenable to conversion to a lambda... (just guessing) I converted those where it was easy to see that the loop did not have an early termination. Lambdas removed. > > ??? L74: ??????????? int i = 1; > ??????? Not your bug, but I think that 'i' is not used. > Fixed. > This all looks good to me... so thumbs up! Thanks. > > I have some reservations about using lambdas in a debugging tool. > My personal philosophy about debugging tools is that they should > be built on the simplest/most stable technology to reduce the > chances of the more complicated technology failing during a debug > session. I hate it when my debugger crashes! I removed all lambdas! Thanks for looking at this, Robbin > > That said, SA is pretty much standalone so use of lambdas in this > debugging tool shouldn't affect the JVM or core file being debugged. > > Again, thumbs up! > > Dan > > >> >> /Robbin >> >> On 2019-05-08 11:17, Robbin Ehn wrote: >>> Hi David, >>> >>> I changed to normal for: >>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>> >>> >>> Full: >>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>> Inc: >>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>> >>> Passes t1-2 >>> >>> Thanks, Robbin >>> >>> >>> On 2019-05-07 09:47, David Holmes wrote: >>>> Hi Robbin, >>>> >>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>> Hi David, >>>>> >>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>> Hi Robbin, >>>>>> >>>>>> I have a few concerns here. >>>>>> >>>>>> First I can't see how you are actually integrating the SA with the >>>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate but IIRC >>>>>> that list can be updated when threads are added/removed and I'm not seeing >>>>>> how the SA is left iterating a valid list - we'd normally using a >>>>>> ThreadsListHandle for that ?? (I may need a refresher on how this list is >>>>>> actually maintained.) >>>>> >>>>> The processes must be paused. If the processes would be running the linked >>>>> list is also broken since if we unlink and delete a JavaThread and then >>>>> later SA follows that _next pointer. >>>> >>>> Ah good point. Thanks for clarifying. >>>> >>>>>> >>>>>> The conversion from external iteration of the list (the for loop) to >>>>>> internal iteration (passing a lambda to JavaThreadsDo) is also >>>>>> problematic. First I'd be very wary about introducing lambda expressions >>>>>> into the SA code - lambda drags in a lot of supporting code that could >>>>>> have an impact on the way SA functions. There are places where we have to >>>>>> avoid lambdas due to bootstrapping/initialization issues and I think the >>>>>> SA may be an area where we also want to keep the code extremely simple. >>>>> >>>>> There are already several usages of lambdas in SA code, e.g. >>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an application, >>>>> there is not a bootstrap issue or so. >>>> >>>> Hmm okay. Lambda carries a lot of baggage. But if its already being used ... >>>> >>>>>> Second by using lambda's with internal iteration you've lost the ability >>>>>> to terminate the iteration loop! In the existing code if we have a return >>>>>> in the for-loop then we not only terminate the loop but the enclosing >>>>>> method. With the lambda the "return" just ends the current iteration and >>>>>> JavaThreadsDo will then continue with the next thread - so we don't even >>>>>> terminate the iteration let alone the method performing the iteration. So >>>>>> for places were we want to process one thread, for example, we will >>>>>> continue to iterate all remaining threads and just do nothing with them. >>>>>> That's very inefficient. >>>>> >>>>> That's why I only used the internal iteration where we didn't have early >>>>> returns. >>>> >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java - >>>> original code: >>>> >>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>> 1557???????????? public void doit(Tokens t) { >>>> ... >>>> 1564???????????????????? for (JavaThread thread = threads.first(); thread != >>>> null; thread = thread.next()) { >>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>> ByteArrayOutputStream(); >>>> 1566???????????????????????? thread.printThreadIDOn(new PrintStream(bos)); >>>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>>> 1568???????????????????????????? out.println("Thread " + bos.toString() + " >>>> Address: " + thread.getAddress()); >>>> ... >>>> 1577???????????????????????????? } >>>> 1578???????????????????????????? if (!all) return; >>>> >>>> That looks like an early return to me. >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, Robbin >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>> Hi, please review. >>>>>>> >>>>>>> Old threads linked list remove and updated SA to use ThreadsList array >>>>>>> instead. >>>>>>> >>>>>>> Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>> >>>>>>> Passes t1-3 (which includes SA tests). >>>>>>> >>>>>>> Thanks, Robbin > From robbin.ehn at oracle.com Tue May 14 14:08:59 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 14 May 2019 16:08:59 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Message-ID: <354daa4d-4c50-1f79-1f64-c45310d11dce@oracle.com> Hi David, Full: http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html Inc: http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html On 2019-05-09 06:46, David Holmes wrote: > As Dan also hints at you are a bit inconsistent with keeping loops or replacing > with lambda's. Anything that would do a "break" or "return" in the loop can't be > converted to a lambda; but "continue" becomes "return" in the lambda version. > > Overall I'd just say forget about any internal iteration using lambdas and just > make the simple changes needed for the loop version. It's a less disruptive > change and doesn't add the complexity and overhead of lambda expressions. Lambdas removed! > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java > > Existing: > > 76???????????????? JavaThread cur = threads.getJavaThreadAt(k); > 77???????????????? if (cur.isJavaThread()) { > > How can cur possibly be anything other than a JavaThread? The SA seems to have a slightly different model, so only pure JavaThreads return true. ServiceThread, CompilerThread, etc, returns false. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java > > Same issue: > > ?463???????????? if (t.isJavaThread()) { > > Possibly more of these I didn't go searching - so probably separate cleanup RFE. > > --- > > Up to you whether you want to keep lambda's but at least ensure consistency in > their use - ie use them everywhere you can. But you know my thoughts on it. :) Removed! Thanks, Robbin. > > Thanks, > David > ----- > >> >> http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ >> http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ >> >> /Robbin >> >> On 2019-05-08 11:17, Robbin Ehn wrote: >>> Hi David, >>> >>> I changed to normal for: >>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>> >>> >>> Full: >>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>> Inc: >>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>> >>> Passes t1-2 >>> >>> Thanks, Robbin >>> >>> >>> On 2019-05-07 09:47, David Holmes wrote: >>>> Hi Robbin, >>>> >>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>> Hi David, >>>>> >>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>> Hi Robbin, >>>>>> >>>>>> I have a few concerns here. >>>>>> >>>>>> First I can't see how you are actually integrating the SA with the >>>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate but IIRC >>>>>> that list can be updated when threads are added/removed and I'm not seeing >>>>>> how the SA is left iterating a valid list - we'd normally using a >>>>>> ThreadsListHandle for that ?? (I may need a refresher on how this list is >>>>>> actually maintained.) >>>>> >>>>> The processes must be paused. If the processes would be running the linked >>>>> list is also broken since if we unlink and delete a JavaThread and then >>>>> later SA follows that _next pointer. >>>> >>>> Ah good point. Thanks for clarifying. >>>> >>>>>> >>>>>> The conversion from external iteration of the list (the for loop) to >>>>>> internal iteration (passing a lambda to JavaThreadsDo) is also >>>>>> problematic. First I'd be very wary about introducing lambda expressions >>>>>> into the SA code - lambda drags in a lot of supporting code that could >>>>>> have an impact on the way SA functions. There are places where we have to >>>>>> avoid lambdas due to bootstrapping/initialization issues and I think the >>>>>> SA may be an area where we also want to keep the code extremely simple. >>>>> >>>>> There are already several usages of lambdas in SA code, e.g. >>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an application, >>>>> there is not a bootstrap issue or so. >>>> >>>> Hmm okay. Lambda carries a lot of baggage. But if its already being used ... >>>> >>>>>> Second by using lambda's with internal iteration you've lost the ability >>>>>> to terminate the iteration loop! In the existing code if we have a return >>>>>> in the for-loop then we not only terminate the loop but the enclosing >>>>>> method. With the lambda the "return" just ends the current iteration and >>>>>> JavaThreadsDo will then continue with the next thread - so we don't even >>>>>> terminate the iteration let alone the method performing the iteration. So >>>>>> for places were we want to process one thread, for example, we will >>>>>> continue to iterate all remaining threads and just do nothing with them. >>>>>> That's very inefficient. >>>>> >>>>> That's why I only used the internal iteration where we didn't have early >>>>> returns. >>>> >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java - >>>> original code: >>>> >>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>> 1557???????????? public void doit(Tokens t) { >>>> ... >>>> 1564???????????????????? for (JavaThread thread = threads.first(); thread != >>>> null; thread = thread.next()) { >>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>> ByteArrayOutputStream(); >>>> 1566???????????????????????? thread.printThreadIDOn(new PrintStream(bos)); >>>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>>> 1568???????????????????????????? out.println("Thread " + bos.toString() + " >>>> Address: " + thread.getAddress()); >>>> ... >>>> 1577???????????????????????????? } >>>> 1578???????????????????????????? if (!all) return; >>>> >>>> That looks like an early return to me. >>>> >>>> Cheers, >>>> David >>>> ----- >>>> >>>> >>>>> Thanks, Robbin >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>> Hi, please review. >>>>>>> >>>>>>> Old threads linked list remove and updated SA to use ThreadsList array >>>>>>> instead. >>>>>>> >>>>>>> Issue: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>> >>>>>>> Passes t1-3 (which includes SA tests). >>>>>>> >>>>>>> Thanks, Robbin From jcbeyler at google.com Tue May 14 15:13:10 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 14 May 2019 08:13:10 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: <54317f28-452b-be6b-6593-7b51a5552b84@oracle.com> References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> <54317f28-452b-be6b-6593-7b51a5552b84@oracle.com> Message-ID: Hi Serguei, For what it's worth, I created https://bugs.openjdk.java.net/browse/JDK-8223881 so that we can hopefully work on it once this and 13 goes through :) Jc *From: *serguei.spitsyn at oracle.com *Date: *Tue, May 14, 2019 at 3:12 AM *To: *David Holmes, Jean Christophe Beyler *Cc: *serviceability-dev Hi David, > > Thank you a lot! > Serguei > > > On 5/14/19 00:13, David Holmes wrote: > > Hi Serguei, > > > > For the delay in getting back to this. Everything seems fine to me now. > > > > Thanks, > > David > > ----- > > > > On 10/05/2019 7:16 pm, serguei.spitsyn at oracle.com wrote: > >> Hi David, > >> > >> I've noticed a minor problem in the jvmti.html diff below: > >> > >> 5c5 > >> < JVM(TM) Tool Interface 11.0.0 > >> --- > >> > JVM(TM) Tool Interface 13.0.0 > >> 30c30 > >> <

Version 11.0

> >> --- > >> >

Version 13.0

> >> 34931c34931 > >> < Version: 11.0.0 > >> --- > >> > Version: 13.0.0 > >> > >> > >> There should not be the last difference as this is the version of > >> last JVMTI spec update: > >> > >> *11.0.0* > >> 7 February 2018 Minor update for new class file NestHost and > >> NestMembers attributes: - Specify that RedefineClasses and > >> RetransformClasses are not allowed to change the class file NestHost > >> and NestMembers attributes. - Add new error > >> JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED that can > >> be returned by RedefineClasses and RetransformClasses. > >> > >> > >> > >> I've updated the webrev: > >> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ > >> > >> The newly updated file is: > >> || src/hotspot/share/prims/jvmti.xml > >> > >> which has this change: > >> > >> + > >> + > >> + > >> + > >> + > >> + > >> + > >> + > >> > >>
> >>
> >>

Change History

> >> Last update:
> >> - Version: > >> + Version: > >> > >> > >> New jvmti.html diff is: > >> 5c5 > >> < JVM(TM) Tool Interface 11.0.0 > >> --- > >> > JVM(TM) Tool Interface 13.0.0 > >> 30c30 > >> <

Version 11.0

> >> --- > >> >

Version 13.0

> >> > >> > >> Thanks, > >> Serguei > >> > >> > >> On 5/10/19 01:03, serguei.spitsyn at oracle.com wrote: > >>> Hi David, > >>> > >>> > >>> On 5/9/19 18:51, David Holmes wrote: > >>>> Hi Serguei, > >>>> > >>>> On 10/05/2019 10:32 am, serguei.spitsyn at oracle.com wrote: > >>>>> I've updated the webrev v2 in place. > >>>> > >>>> make/hotspot/gensrc/GensrcJvmti.gmk > >>>> > >>>> You don't need to pass through: -PARAM minorversion $(VERSION_INTERIM) > >>> > >>> Good catch. > >>> How did I missed to remove? > >>> > >>> > >>>> > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java > >>>> > >>>> > >>>> 57 private static final int minorVersion = > >>>> Runtime.version().interim(); > >>>> > >>>> That should be kept at 0. > >>> > >>> Okay, fixed. > >>> > >>> New webrev is: > >>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ > >>> > >>> > >>> > >>>> > >>>> I'd like to see an actual diff of the generated jvmti.h and > >>>> jvmti.html files as well please. Some of the XSL stuff looks odd to > >>>> me. > >>> > >>> The jvmti.h diff: > >>> > >>> 2c2 > >>> < * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All > >>> rights reserved. > >>> --- > >>> > * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All > >>> rights reserved. > >>> 47c47 > >>> < JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * 0x100) + 0 > >>> /* version: 11.0.0 */ > >>> --- > >>> > JVMTI_VERSION = 0x30000000 + (13 * 0x10000) + ( 0 * 0x100) + > >>> 0 /* version: 13.0.0 */ > >>> > >>> > >>> > >>> The jvmti.html diff: > >>> > >>> 5c5 > >>> < JVM(TM) Tool Interface 11.0.0 > >>> --- > >>> > JVM(TM) Tool Interface 13.0.0 > >>> 30c30 > >>> <

Version 11.0

> >>> --- > >>> >

Version 13.0

> >>> 34931c34931 > >>> < Version: 11.0.0 > >>> --- > >>> > Version: 13.0.0 > >>> > >>> > >>> > >>> Thanks, > >>> Serguei > >>> > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> Thanks, > >>>>> Serguei > >>>>> > >>>>> > >>>>> On 5/9/19 17:28, serguei.spitsyn at oracle.com wrote: > >>>>>> David and Jc, > >>>>>> > >>>>>> Okay, I'll remove this line now. > >>>>>> Thank you for your comments. > >>>>>> > >>>>>> Let's let Jc to file a separate enhancement on this. > >>>>>> Then I'll file a CSR and prepare a fix. > >>>>>> > >>>>>> I hope, you both are Okay with the rest. > >>>>>> > >>>>>> Thanks! > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 5/9/19 17:17, Jean Christophe Beyler wrote: > >>>>>>> Hi Serguei, > >>>>>>> > >>>>>>> Adding to the difficulties that David is exposing, this won't > >>>>>>> work. You need to redo the xls definition because you need the > >>>>>>> #define to be the numeric value directly and not the enum; > >>>>>>> otherwise it won't work in any usable way at preprocessor time > >>>>>>> sadly. > >>>>>>> > >>>>>>> I think it makes sense to just do what you were planning to do > >>>>>>> here without this and I'll file a bug and work out the CSR path > >>>>>>> and review path separately and see what is do-able or not then > >>>>>>> because I think it's too much work now "just for this now" if > >>>>>>> that makes sense :) > >>>>>>> Jc > >>>>>>> > >>>>>>> *From: *David Holmes >>>>>>> > > >>>>>>> *Date: *Thu, May 9, 2019 at 5:11 PM > >>>>>>> *To: *serguei.spitsyn at oracle.com > >>>>>>> , Jean Christophe Beyler > >>>>>>> *Cc: *serviceability-dev > >>>>>>> > >>>>>>> On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com > >>>>>>> wrote: > >>>>>>> > Hi Jc, > >>>>>>> > > >>>>>>> > Okay, you convinced me - thanks! > >>>>>>> > Added new line into the generated jvmti.h: > >>>>>>> > > >>>>>>> > #define JVMTI_VERSION_LATEST JVMTI_VERSION > >>>>>>> > >>>>>>> That requires a CSR as you are expanding the exported > >>>>>>> interface. > >>>>>>> > >>>>>>> Also you need > >>>>>>> > >>>>>>> #define JVMTI_VERSION_LATEST (JVMTI_VERSION) > >>>>>>> > >>>>>>> as JVMTI_VERSION is itself an expression not a constant. > >>>>>>> That might > >>>>>>> limit the utility of having such a define as you won't be > >>>>>>> able to > >>>>>>> use it > >>>>>>> in an ifdef guard to test a value AFAICS. > >>>>>>> > >>>>>>> David > >>>>>>> > >>>>>>> > I hope, it will help in your case. > >>>>>>> > > >>>>>>> > > >>>>>>> > Updated webrev version is: > >>>>>>> > > >>>>>>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ > >>>>>>> > >>>>>>> > > >>>>>>> > > >>>>>>> > This version includes suggestions from David. > >>>>>>> > > >>>>>>> > Thanks, > >>>>>>> > Serguei > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > On 5/9/19 14:17, Jean Christophe Beyler wrote: > >>>>>>> >> Hi Serguei, > >>>>>>> >> > >>>>>>> >> Of course I can :) > >>>>>>> >> > >>>>>>> >> Consider, just randomly of course, the heap sampling work > >>>>>>> that > >>>>>>> got > >>>>>>> >> added to JVMTI. Now imagine you'd want to test if it is > >>>>>>> supported by a > >>>>>>> >> given JVMTI version, you would write something like this: > >>>>>>> >> > >>>>>>> >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { > >>>>>>> >> jvmtiCapabilities caps; > >>>>>>> >> memset(&caps, 0, sizeof(caps)); > >>>>>>> >> if (jvmti->GetPotentialCapabilities(&caps) != > >>>>>>> JVMTI_ERROR_NONE) { > >>>>>>> >> LOG(WARNING) << "Failed to get potential capabilities, > >>>>>>> disabling > >>>>>>> >> the heap " > >>>>>>> >> << "sampling monitor"; > >>>>>>> >> return false; > >>>>>>> >> } > >>>>>>> >> > >>>>>>> >> return caps.can_generate_sampled_object_alloc_events > >>>>>>> >> && caps.can_generate_garbage_collection_events; > >>>>>>> >> } > >>>>>>> >> > >>>>>>> >> Now, the problem is that this code cannot be used if you > >>>>>>> compile with > >>>>>>> >> an older JDK such as JDK8 for example > >>>>>>> >> because can_generate_sampled_object_alloc_events does not > >>>>>>> exist yet > >>>>>>> >> for that jvmti.h file. > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> In a perfect world, we might imagine that we are always > >>>>>>> compiling with > >>>>>>> >> the latest JVMTI headers but that is not always true and, > >>>>>>> therefore, > >>>>>>> >> to have the code portable, we now have to do: > >>>>>>> >> > >>>>>>> >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { > >>>>>>> >> #ifdef ENABLE_HEAP_SAMPLING > >>>>>>> >> jvmtiCapabilities caps; > >>>>>>> >> memset(&caps, 0, sizeof(caps)); > >>>>>>> >> if (jvmti->GetPotentialCapabilities(&caps) != > >>>>>>> JVMTI_ERROR_NONE) { > >>>>>>> >> LOG(WARNING) << "Failed to get potential capabilities, > >>>>>>> disabling > >>>>>>> >> the heap " > >>>>>>> >> << "sampling monitor"; > >>>>>>> >> return false; > >>>>>>> >> } > >>>>>>> >> > >>>>>>> >> return caps.can_generate_sampled_object_alloc_events > >>>>>>> >> && caps.can_generate_garbage_collection_events; > >>>>>>> >> #else > >>>>>>> >> return false; > >>>>>>> >> #endif > >>>>>>> >> } > >>>>>>> >> > >>>>>>> >> Where ENABLE_HEAP_SAMPLING is defined if we did compile with > >>>>>>> JDK11 and > >>>>>>> >> not defined if we compiled with JDK8. I can't use > >>>>>>> JVMTI_VERSION > >>>>>>> >> because I can't use it in an #if because it is not an enum. > >>>>>>> Were it to > >>>>>>> >> be a #define or were I to have a #define I could use with a > >>>>>>> version > >>>>>>> >> number being bumped up, I could write something such as: > >>>>>>> >> > >>>>>>> >> #ifdef JVMTI_VERSION_11 > >>>>>>> >> > >>>>>>> >> or something that looks in the value of the JVMTI_VERSION > >>>>>>> if I > >>>>>>> wanted. > >>>>>>> >> Right now, I can't even do that! > >>>>>>> >> > >>>>>>> >> Hopefully this helps understand what I am talking about :-), > >>>>>>> >> Jc > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> On Thu, May 9, 2019 at 2:08 PM serguei.spitsyn at oracle.com > >>>>>>> > >>>>>>> >> >>>>>>> > >>>>>>> > >>>>>>> >> >>>>>>> >> wrote: > >>>>>>> >> > >>>>>>> >> Hi Jc, > >>>>>>> >> > >>>>>>> >> Thank you a lot for review! > >>>>>>> >> Some replies below. > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> On 5/9/19 09:10, Jean Christophe Beyler wrote: > >>>>>>> >>> Hi Serguei, > >>>>>>> >>> > >>>>>>> >>> FWIW, the change looks good and I think it's a good > >>>>>>> idea > >>>>>>> to do. > >>>>>>> >>> However, there is one thorn in our internal agent > >>>>>>> code is > >>>>>>> that > >>>>>>> >>> the JVMTI_VERSION is in an enum. This makes us > >>>>>>> unable to > >>>>>>> #if it > >>>>>>> >>> when adding usages of newer features/methods. > >>>>>>> >>> > >>>>>>> >>> This probably could/should be a different webrev > >>>>>>> (which I > >>>>>>> can do > >>>>>>> >>> if you like) but is there any way while you are > >>>>>>> changing this > >>>>>>> >>> that the enum for JVMTI_VERSION could become a set of > >>>>>>> #define? > >>>>>>> >>> > >>>>>>> >>> So instead of: > >>>>>>> >>> enum { > >>>>>>> >>> JVMTI_VERSION_1 = 0x30010000, > >>>>>>> >>> JVMTI_VERSION_1_0 = 0x30010000, > >>>>>>> >>> JVMTI_VERSION_1_1 = 0x30010100, > >>>>>>> >>> JVMTI_VERSION_1_2 = 0x30010200, > >>>>>>> >>> JVMTI_VERSION_9 = 0x30090000, > >>>>>>> >>> JVMTI_VERSION_11 = 0x300B0000, > >>>>>>> >>> > >>>>>>> >>> JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * > >>>>>>> 0x100) + > >>>>>>> >>> 0 /* version: 11.0.0 */ > >>>>>>> >>> }; > >>>>>>> >>> > >>>>>>> >>> We would get: > >>>>>>> >>> #define JVMTI_VERSION_1 0x30010000 > >>>>>>> >>> #define JVMTI_VERSION_1_0 0x30010000 > >>>>>>> >>> #define JVMTI_VERSION_1_1 = 0x30010100 > >>>>>>> >>> #define JVMTI_VERSION_1_2 = 0x30010200 > >>>>>>> >>> #define JVMTI_VERSION_9 = 0x30090000 > >>>>>>> >>> #define JVMTI_VERSION_11 = 0x300B0000 > >>>>>>> >>> #define JVMTI_VERSION (0x30000000 + (11 * 0x10000) + > >>>>>>> (0 * > >>>>>>> 0x100) > >>>>>>> >>> + 0 /* version: 11.0.0 */) > >>>>>>> >> > >>>>>>> >> It is interesting concern and suggestion. > >>>>>>> >> I'm not sure if it requires a CSR. > >>>>>>> >> > >>>>>>> >> > >>>>>>> >>> I actually don't care about any define of these > >>>>>>> except for > >>>>>>> >>> JVMTI_VERSION; basically it would be useful so that in > >>>>>>> our agent > >>>>>>> >>> code we can test the JVMTI_VERSION with #if macros to > >>>>>>> protect the > >>>>>>> >>> code when new elements show up in future versions. > >>>>>>> So it also > >>>>>>> >>> could be: > >>>>>>> >>> enum { > >>>>>>> >>> JVMTI_VERSION_1 = 0x30010000, > >>>>>>> >>> JVMTI_VERSION_1_0 = 0x30010000, > >>>>>>> >>> JVMTI_VERSION_1_1 = 0x30010100, > >>>>>>> >>> JVMTI_VERSION_1_2 = 0x30010200, > >>>>>>> >>> JVMTI_VERSION_9 = 0x30090000, > >>>>>>> >>> JVMTI_VERSION_11 = 0x300B0000, > >>>>>>> >>> > >>>>>>> >>> JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * > >>>>>>> 0x100) + > >>>>>>> >>> 0 /* version: 11.0.0 */ > >>>>>>> >>> }; > >>>>>>> >>> > >>>>>>> >>> #define JVMTI_LATEST_VERSION (0x30000000 + (11 * > >>>>>>> 0x10000) > >>>>>>> + (0 * > >>>>>>> >>> 0x100) + 0 /* version: 11.0.0 */) > >>>>>>> >> > >>>>>>> >> I is not a problem to implement this one. > >>>>>>> >> But I'm not sure how does this really help in your case. > >>>>>>> >> I do not see a point to test the JVMTI_VERSION with > >>>>>>> #if as > >>>>>>> it is > >>>>>>> >> always defined. > >>>>>>> >> Could you, please, elaborate a little bit more? > >>>>>>> >> > >>>>>>> >> Thanks, > >>>>>>> >> Serguei > >>>>>>> >> > >>>>>>> >>> Right now, I have to do weird things where I detect the > >>>>>>> jvmti.h > >>>>>>> >>> used at compile time to then do -DUSING_JDK11 for the > >>>>>>> agent at > >>>>>>> >>> compile time. > >>>>>>> >>> > >>>>>>> >>> Thanks! > >>>>>>> >>> Jc > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> On Thu, May 9, 2019 at 8:48 AM > >>>>>>> serguei.spitsyn at oracle.com > >>>>>>> > >>>>>>> >>> >>>>>>> > >>>>>>> > >>>>>>> >>> >>>>>>> >> wrote: > >>>>>>> >>> > >>>>>>> >>> I'll try to get rid of VERSION_INTERIM. > >>>>>>> >>> Always using just VERSION_FEATURE.0.0 should not > >>>>>>> create problems > >>>>>>> >>> if we do not change JVMTI spec in VERSION_UPDATE. > >>>>>>> >>> I do not see why we would change the JVMTI spec > >>>>>>> in update > >>>>>>> >>> releases. > >>>>>>> >>> But if we do then using VERSION_UPDATE as > >>>>>>> microversion would > >>>>>>> >>> be good enough. > >>>>>>> >>> > >>>>>>> >>> Thanks! > >>>>>>> >>> Serguei > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> On 5/9/19 06:13, David Holmes wrote: > >>>>>>> >>> > Hi Serguei, > >>>>>>> >>> > > >>>>>>> >>> > On 9/05/2019 7:09 pm, serguei.spitsyn at oracle.com > >>>>>>> > >>>>>>> >>> >>>>>>> > wrote: > >>>>>>> >>> >> Hi David, > >>>>>>> >>> >> > >>>>>>> >>> >> Thank you a lot for review! > >>>>>>> >>> >> There are some replies below. > >>>>>>> >>> >> > >>>>>>> >>> >> > >>>>>>> >>> >> On 5/8/19 18:42, David Holmes wrote: > >>>>>>> >>> >>> Hi Serguei, > >>>>>>> >>> >>> > >>>>>>> >>> >>> On 9/05/2019 8:57 am, > >>>>>>> serguei.spitsyn at oracle.com > >>>>>>> > >>>>>>> >>> >>>>>>> ?? > wrote: > >>>>>>> >>> >>>> Please, review a fix for the task: > >>>>>>> >>> >>>> > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219023 > >>>>>>> >>> >>>> > >>>>>>> >>> >>>> Webrev: > >>>>>>> >>> >>>> > >>>>>>> >>> > >>>>>>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ > >>>>>>> > >>>>>>> >>> > >>>>>>> >>> >>>> > >>>>>>> >>> >>>> > >>>>>>> >>> >>>> Summary: > >>>>>>> >>> >>>> > >>>>>>> >>> >>>> By design as we have never bumped the JVMTI > >>>>>>> version unless > >>>>>>> >>> >>>> there were spec changes for that release. > >>>>>>> Now > >>>>>>> we want > >>>>>>> >>> to sync > >>>>>>> >>> >>>> the JVMTI version with the JDK version > >>>>>>> regardless of > >>>>>>> >>> whether > >>>>>>> >>> >>>> or not spec changes have occurred in that > >>>>>>> release. > >>>>>>> >>> >>>> Also, we want it automatically set by the > >>>>>>> build system > >>>>>>> >>> so that > >>>>>>> >>> >>>> no manual updates are needed for each > >>>>>>> release. > >>>>>>> >>> >>>> > >>>>>>> >>> >>>> The jvmti.h and jvmti.html (JVMTI spec) are > >>>>>>> generated from > >>>>>>> >>> >>>> the jvmti.xsl with the XSLT scripts now. So, > >>>>>>> the fix > >>>>>>> >>> removes > >>>>>>> >>> >>>> hard coded major, minor and micro versions > >>>>>>> from the > >>>>>>> >>> jvmti.xml > >>>>>>> >>> >>>> and passes major and minor parameters > >>>>>>> with the > >>>>>>> -PARAMETER > >>>>>>> >>> >>>> to the XSL transformation. > >>>>>>> >>> >>>> > >>>>>>> >>> >>>> Another part of the fix is in the JDI > >>>>>>> which starts > >>>>>>> >>> using JDK > >>>>>>> >>> >>>> versions now instead of maintaining its own, > >>>>>>> and in > >>>>>>> >>> the JDWP > >>>>>>> >>> >>>> agent which is using the JVMTI versions > >>>>>>> instead of its > >>>>>>> >>> own. > >>>>>>> >>> >>> > >>>>>>> >>> >>> This all seems reasonable (though I'm no > >>>>>>> expert on > >>>>>>> >>> working with XSL > >>>>>>> >>> >>> etc). > >>>>>>> >>> >>> > >>>>>>> >>> >>> One thing I am unclear of is why you bother > >>>>>>> with > >>>>>>> using > >>>>>>> >>> >>> VERSION_INTERIM when the actual version check > >>>>>>> will only > >>>>>>> >>> consider > >>>>>>> >>> >>> VERSION_FEATURE (aka major). Couldn't you just > >>>>>>> leave the > >>>>>>> >>> "minor" > >>>>>>> >>> >>> part 0 the same as the "micro" part? > >>>>>>> >>> >> > >>>>>>> >>> >> This is right question to ask. > >>>>>>> >>> >> I was two-folded on this. > >>>>>>> >>> >> But finally decided to maintain minor version > >>>>>>> (aka > >>>>>>> >>> VERSION_INTERIM). > >>>>>>> >>> >> Then the JVMTI and debugger version will > >>>>>>> match the > >>>>>>> VM and > >>>>>>> >>> JDK version > >>>>>>> >>> >> for update releases. > >>>>>>> >>> >> If understand it correctly, we are still > >>>>>>> going to have > >>>>>>> >>> major.minor > >>>>>>> >>> >> versions. > >>>>>>> >>> > > >>>>>>> >>> > Not really. What we have now are things like > >>>>>>> 11.0.3 and > >>>>>>> >>> 12.0.1 - only > >>>>>>> >>> > using the first and third parts. The full 4 part > >>>>>>> version > >>>>>>> >>> string is: > >>>>>>> >>> > > >>>>>>> >>> > > >>>>>>> >>> > >>>>>>> $VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH > >>>>>>> >>> > > >>>>>>> >>> > and we typically only update version_feature and > >>>>>>> >>> version_update. > >>>>>>> >>> > > >>>>>>> >>> > https://openjdk.java.net/jeps/322 > >>>>>>> >>> > > >>>>>>> >>> >> Also, the JVMTI GetVersionNumberspec still > >>>>>>> tells about > >>>>>>> >>> both minor and > >>>>>>> >>> >> micro versions. > >>>>>>> >>> >> It also defines special constants for > >>>>>>> corresponding masks > >>>>>>> >>> and shifts: > >>>>>>> >>> >> > >>>>>>> >>> >> Version Masks > >>>>>>> >>> >> Constant Value Description > >>>>>>> >>> >> |JVMTI_VERSION_MASK_INTERFACE_TYPE| 0x70000000 > >>>>>>> >>> Mask to > >>>>>>> >>> >> extract > >>>>>>> >>> >> interface type. The value of the version > >>>>>>> returned by > >>>>>>> >>> this function > >>>>>>> >>> >> masked with > >>>>>>> |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always > >>>>>>> >>> >> |JVMTI_VERSION_INTERFACE_JVMTI| since this is > >>>>>>> a JVMTI > >>>>>>> >>> function. > >>>>>>> >>> >> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000 > >>>>>>> Mask to > >>>>>>> >>> extract major > >>>>>>> >>> >> version number. > >>>>>>> >>> >> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00 > >>>>>>> Mask to > >>>>>>> >>> extract minor > >>>>>>> >>> >> version number. > >>>>>>> >>> >> |JVMTI_VERSION_MASK_MICRO| 0x000000FF > >>>>>>> Mask to > >>>>>>> >>> extract micro > >>>>>>> >>> >> version number. > >>>>>>> >>> >> > >>>>>>> >>> >> Version Shifts > >>>>>>> >>> >> Constant Value Description > >>>>>>> >>> >> |JVMTI_VERSION_SHIFT_MAJOR| 16 Shift to > >>>>>>> extract major > >>>>>>> >>> >> version number. > >>>>>>> >>> >> |JVMTI_VERSION_SHIFT_MINOR| 8 Shift to > >>>>>>> extract > >>>>>>> minor > >>>>>>> >>> >> version number. > >>>>>>> >>> >> |JVMTI_VERSION_SHIFT_MICRO| 0 Shift to > >>>>>>> extract > >>>>>>> micro > >>>>>>> >>> >> version number. > >>>>>>> >>> >> > >>>>>>> >>> >> > >>>>>>> >>> >> This is link to the spec: > >>>>>>> >>> >> > >>>>>>> >>> > >>>>>>> > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber > >>>>>>> > >>>>>>> >>> > >>>>>>> >>> >> > >>>>>>> >>> >> > >>>>>>> >>> >> It seems, changing (and/or deprecating) this > >>>>>>> will give > >>>>>>> >>> more problems > >>>>>>> >>> >> than benefits. > >>>>>>> >>> >> It is better to remain compatible with previous > >>>>>>> releases. > >>>>>>> >>> > > >>>>>>> >>> > This is a problem that was flagged when the new > >>>>>>> versioning > >>>>>>> >>> scheme was > >>>>>>> >>> > introduced but I'm guessing nothing was actually > >>>>>>> done about > >>>>>>> >>> it. They > >>>>>>> >>> > are not really compatible beyond the > >>>>>>> major/feature > >>>>>>> part. > >>>>>>> >>> > > >>>>>>> >>> > If we only update the spec version with the > >>>>>>> feature > >>>>>>> version > >>>>>>> >>> then all > >>>>>>> >>> > versions will have the form N.0.0. However > >>>>>>> your changes > >>>>>>> >>> will also > >>>>>>> >>> > update if we happen to use a VERSION_INTERIM > >>>>>>> for some > >>>>>>> >>> reason - though > >>>>>>> >>> > the version check will ignore that anyway. I'm > >>>>>>> not > >>>>>>> really > >>>>>>> >>> seeing the > >>>>>>> >>> > point in having that happen. > >>>>>>> >>> > > >>>>>>> >>> > Maybe we do need to define a new version API that > >>>>>>> maps to > >>>>>>> >>> the new > >>>>>>> >>> > versioning scheme of OpenJDK ? But if we did > >>>>>>> that we'd > >>>>>>> >>> still have to > >>>>>>> >>> > support the legacy mapping and I'd still advocate > >>>>>>> simply using > >>>>>>> >>> > VERSION_FEATURE.0.0. > >>>>>>> >>> > > >>>>>>> >>> > It's tricky. > >>>>>>> >>> > > >>>>>>> >>> > David > >>>>>>> >>> > ----- > >>>>>>> >>> > > >>>>>>> >>> >>> For the record I considered whether this > >>>>>>> needs a CSR > >>>>>>> >>> request and > >>>>>>> >>> >>> concluded it did not as it doesn't involve > >>>>>>> changing any > >>>>>>> >>> actual > >>>>>>> >>> >>> specifications. > >>>>>>> >>> >> > >>>>>>> >>> >> Okay, thanks. > >>>>>>> >>> >> I considered it too, made the same conclusion > >>>>>>> but > >>>>>>> still > >>>>>>> >>> have some > >>>>>>> >>> >> doubt. :) > >>>>>>> >>> >> > >>>>>>> >>> >> Thanks! > >>>>>>> >>> >> Serguei > >>>>>>> >>> >> > >>>>>>> >>> >>> > >>>>>>> >>> >>> Thanks, > >>>>>>> >>> >>> David > >>>>>>> >>> >>> > >>>>>>> >>> >>>> Testing: > >>>>>>> >>> >>>> Generated docs and jvmti.h and checked the > >>>>>>> versions > >>>>>>> >>> are correct. > >>>>>>> >>> >>>> > >>>>>>> >>> >>>> One could ask if we have to use same or > >>>>>>> similar > >>>>>>> approach for > >>>>>>> >>> >>>> other API's and tools, like JNI, JMX and so > >>>>>>> on. > >>>>>>> >>> >>>> But these are not areas of my expertise or > >>>>>>> responsibility. > >>>>>>> >>> >>>> It just feels like there is some room for > >>>>>>> unification here. > >>>>>>> >>> >>>> > >>>>>>> >>> >>>> Thanks, > >>>>>>> >>> >>>> Serguei > >>>>>>> >>> >> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> > >>>>>>> >>> -- > >>>>>>> >>> > >>>>>>> >>> Thanks, > >>>>>>> >>> Jc > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> -- > >>>>>>> >> > >>>>>>> >> Thanks, > >>>>>>> >> Jc > >>>>>>> > > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Jc > >>>>>> > >>>>> > >>> > >> > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 14 16:00:38 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 May 2019 09:00:38 -0700 Subject: RFC: 8223740: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: <76cfedbe-531b-33b5-ba7c-06165aa3e93a@oracle.com> References: <28fb2148-a8df-9637-aa80-ea5f8c5f4a6d@oracle.com> <76cfedbe-531b-33b5-ba7c-06165aa3e93a@oracle.com> Message-ID: <20a1734b-85aa-3033-66b7-627d986fd909@oracle.com> Hi Alan, Thank you for looking at it! Okay, I'll check for a javadoc tag than can be used for this. Thanks, Serguei On 5/14/19 03:46, Alan Bateman wrote: > On 14/05/2019 03:36, serguei.spitsyn at oracle.com wrote: >> : >> >> ? Java SE 9 added two abstract module-aware methods to the interface >> ? java.lang.instrument.Instrumentation. The assumption at the time was >> ? that the Instrumentation implementation is tightly coupled to the VM >> ? implementation and it seemed unlikely there would be other >> implementations >> ? (this follows similar additions of abstract methods in Java SE 6). > Right, Instrumentation wants to be a sealed type but doesn't have a > way to express this yet. Adding a statement to the javadoc seems okay > for now, I'm just wondering if it should use one of the javadoc tags > created for documenting API notes [1]. Joe Darcy (cc'ed) may have > input into this. It can probably be @apiNote as the statement is it > documenting intention. > > -Alan > > [1] https://openjdk.java.net/jeps/8068562 From serguei.spitsyn at oracle.com Tue May 14 16:11:56 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 May 2019 09:11:56 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> <54317f28-452b-be6b-6593-7b51a5552b84@oracle.com> Message-ID: <3c52c9f2-5a5b-15dc-112d-e7fc59a1806b@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 14 16:25:40 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 May 2019 09:25:40 -0700 Subject: RFC: 8223740: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: <76cfedbe-531b-33b5-ba7c-06165aa3e93a@oracle.com> References: <28fb2148-a8df-9637-aa80-ea5f8c5f4a6d@oracle.com> <76cfedbe-531b-33b5-ba7c-06165aa3e93a@oracle.com> Message-ID: <70f8da85-cffe-4edc-2b34-d7ece446ba3c@oracle.com> Alan, I've updated the CSR with the @apiNote tag: https://bugs.openjdk.java.net/browse/JDK-8223740 Thanks, Serguei On 5/14/19 03:46, Alan Bateman wrote: > On 14/05/2019 03:36, serguei.spitsyn at oracle.com wrote: >> : >> >> ? Java SE 9 added two abstract module-aware methods to the interface >> ? java.lang.instrument.Instrumentation. The assumption at the time was >> ? that the Instrumentation implementation is tightly coupled to the VM >> ? implementation and it seemed unlikely there would be other >> implementations >> ? (this follows similar additions of abstract methods in Java SE 6). > Right, Instrumentation wants to be a sealed type but doesn't have a > way to express this yet. Adding a statement to the javadoc seems okay > for now, I'm just wondering if it should use one of the javadoc tags > created for documenting API notes [1]. Joe Darcy (cc'ed) may have > input into this. It can probably be @apiNote as the statement is it > documenting intention. > > -Alan > > [1] https://openjdk.java.net/jeps/8068562 From serguei.spitsyn at oracle.com Tue May 14 16:30:31 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 May 2019 09:30:31 -0700 Subject: RFC: 8223740: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: <76cfedbe-531b-33b5-ba7c-06165aa3e93a@oracle.com> References: <28fb2148-a8df-9637-aa80-ea5f8c5f4a6d@oracle.com> <76cfedbe-531b-33b5-ba7c-06165aa3e93a@oracle.com> Message-ID: Alan, I've updated the CSR with @apiNote tag. Could you, please, add yourself as a reviewer? Thanks, Serguei On 5/14/19 03:46, Alan Bateman wrote: > On 14/05/2019 03:36, serguei.spitsyn at oracle.com wrote: >> : >> >> ? Java SE 9 added two abstract module-aware methods to the interface >> ? java.lang.instrument.Instrumentation. The assumption at the time was >> ? that the Instrumentation implementation is tightly coupled to the VM >> ? implementation and it seemed unlikely there would be other >> implementations >> ? (this follows similar additions of abstract methods in Java SE 6). > Right, Instrumentation wants to be a sealed type but doesn't have a > way to express this yet. Adding a statement to the javadoc seems okay > for now, I'm just wondering if it should use one of the javadoc tags > created for documenting API notes [1]. Joe Darcy (cc'ed) may have > input into this. It can probably be @apiNote as the statement is it > documenting intention. > > -Alan > > [1] https://openjdk.java.net/jeps/8068562 From Alan.Bateman at oracle.com Tue May 14 17:09:04 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 14 May 2019 18:09:04 +0100 Subject: RFC: 8223740: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: References: <28fb2148-a8df-9637-aa80-ea5f8c5f4a6d@oracle.com> <76cfedbe-531b-33b5-ba7c-06165aa3e93a@oracle.com> Message-ID: On 14/05/2019 17:30, serguei.spitsyn at oracle.com wrote: > Alan, > > I've updated the CSR with @apiNote tag. > Could you, please, add yourself as a reviewer? Done. From just.mychris at googlemail.com Tue May 14 18:52:38 2019 From: just.mychris at googlemail.com (Chris) Date: Tue, 14 May 2019 20:52:38 +0200 Subject: JVMTI ExceptionCatch event clarification In-Reply-To: <8829b41e-e5e8-574f-dade-9a30bccf10ac@oracle.com> References: <96510b52-76ea-5ece-d87d-b090abb8e6a1@googlemail.com> <8829b41e-e5e8-574f-dade-9a30bccf10ac@oracle.com> Message-ID: <5d763859-5d9a-1127-9649-37364b81d6e6@googlemail.com> Thanks a lot for the fast response and clarification. On 5/14/19 7:34 AM, David Holmes wrote: > So yes I would say this is a bug. I filed: > > https://bugs.openjdk.java.net/browse/JDK-8223812 > > "JVM TI ExceptionCatch event is not posted when an exception is caught > by a native method" > > Fix seems simple enough. Thank you for submitting the bug report. Will the fix also be ported to OpenJDK 8? The affected versions list does not include "8". -- Chris From serguei.spitsyn at oracle.com Tue May 14 19:14:05 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 May 2019 12:14:05 -0700 Subject: RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version In-Reply-To: References: <534285a8-c278-36d5-9d3f-720beebcdc4a@oracle.com> <61269b1f-cb70-9152-8328-f04652298feb@oracle.com> <6bd2d518-1196-a95d-d8f0-47a360960112@oracle.com> <68506762-e088-1dc4-b0bf-498549f4f070@oracle.com> <077ed681-11af-5bb8-128d-3a608dccaa2e@oracle.com> <2a722c88-1e2d-368f-abc2-0dc6f7f98216@oracle.com> <6db0478c-8650-c2a4-cb54-f37caae59cc3@oracle.com> <9ae18f40-7b86-da87-6257-d24c182f2908@oracle.com> <1cbc30af-4880-a0d3-8d15-136003873376@oracle.com> <0237c60d-26e5-e473-5f4a-47fb3fb066dd@oracle.com> <54317f28-452b-be6b-6593-7b51a5552b84@oracle.com> Message-ID: Hi Jc, Thank you for filing this issue! It should not be hard to fix but will need a CSR as David noted. Thanks, Serguei On 5/14/19 08:13, Jean Christophe Beyler wrote: > Hi Serguei, > > For what it's worth, I created > https://bugs.openjdk.java.net/browse/JDK-8223881?so that we can > hopefully work on it once this and 13 goes through :) > Jc > > *From: *serguei.spitsyn at oracle.com > > > *Date: *Tue, May 14, 2019 at 3:12 AM > *To: *David Holmes, Jean Christophe Beyler > *Cc: *serviceability-dev > > Hi David, > > Thank you a lot! > Serguei > > > On 5/14/19 00:13, David Holmes wrote: > > Hi Serguei, > > > > For the delay in getting back to this. Everything seems fine to > me now. > > > > Thanks, > > David > > ----- > > > > On 10/05/2019 7:16 pm, serguei.spitsyn at oracle.com > wrote: > >> Hi David, > >> > >> I've noticed a minor problem in the jvmti.html diff below: > >> > >> 5c5 > >> JVM(TM) Tool Interface 11.0.0 > >> --- > >> ?>???????? JVM(TM) Tool Interface 13.0.0 > >> 30c30 > >> Version 11.0 > >> --- > >> ?>????????????

Version 13.0

> >> 34931c34931 > >> >> --- > >> ?>???????????????? Version: 13.0.0 > >> > >> > >> There should not be the last difference as this is the version of > >> last JVMTI spec update: > >> > >> *11.0.0* > >> 7 February 2018???? Minor update for new class file NestHost and > >> NestMembers attributes: - Specify that RedefineClasses and > >> RetransformClasses are not allowed to change the class file > NestHost > >> and NestMembers attributes. - Add new error > >> JVMTI_ERROR_UNSUPPORTED_REDEFINITION_CLASS_ATTRIBUTE_CHANGED > that can > >> be returned by RedefineClasses and RetransformClasses. > >> > >> > >> > >> I've updated the webrev: > >> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ > > >> > >> The newly updated file is: > >> || src/hotspot/share/prims/jvmti.xml > >> > >> which has this change: > >> > >> + > >> + > >> + > >> + > >> + > >> + > >> + > >> + > >> ? > >> ?????
> >> ?????
> >> ?????

Change History

> >> ????? Last update:
> >> - Version: > >> + Version: > >> > >> > >> New jvmti.html diff is: > >> 5c5 > >> JVM(TM) Tool Interface 11.0.0 > >> --- > >> ?>???????? JVM(TM) Tool Interface 13.0.0 > >> 30c30 > >> Version 11.0 > >> --- > >> ?>????????????

Version 13.0

> >> > >> > >> Thanks, > >> Serguei > >> > >> > >> On 5/10/19 01:03, serguei.spitsyn at oracle.com > wrote: > >>> Hi David, > >>> > >>> > >>> On 5/9/19 18:51, David Holmes wrote: > >>>> Hi Serguei, > >>>> > >>>> On 10/05/2019 10:32 am, serguei.spitsyn at oracle.com > wrote: > >>>>> I've updated the webrev v2 in place. > >>>> > >>>> ?make/hotspot/gensrc/GensrcJvmti.gmk > >>>> > >>>> You don't need to pass through: -PARAM minorversion > $(VERSION_INTERIM) > >>> > >>> Good catch. > >>> How did I missed to remove? > >>> > >>> > >>>> > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java > > >>>> > >>>> > >>>> ?57???? private static final int minorVersion = > >>>> Runtime.version().interim(); > >>>> > >>>> That should be kept at 0. > >>> > >>> Okay, fixed. > >>> > >>> New webrev is: > >>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.3/ > > > >>> > >>> > >>> > >>>> > >>>> I'd like to see an actual diff of the generated jvmti.h and > >>>> jvmti.html files as well please. Some of the XSL stuff looks > odd to > >>>> me. > >>> > >>> The jvmti.h diff: > >>> > >>> 2c2 > >>> >>> rights reserved. > >>> --- > >>> >? * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All > >>> rights reserved. > >>> 47c47 > >>> 0x100) + 0 > >>> /* version: 11.0.0 */ > >>> --- > >>> >???? JVMTI_VERSION = 0x30000000 + (13 * 0x10000) + ( 0 * > 0x100) + > >>> 0? /* version: 13.0.0 */ > >>> > >>> > >>> > >>> The jvmti.html diff: > >>> > >>> 5c5 > >>> JVM(TM) Tool Interface 11.0.0 > >>> --- > >>> >???????? JVM(TM) Tool Interface 13.0.0 > >>> 30c30 > >>> Version 11.0 > >>> --- > >>> >????????????

Version 13.0

> >>> 34931c34931 > >>> >>> --- > >>> >???????????????? Version: 13.0.0 > >>> > >>> > >>> > >>> Thanks, > >>> Serguei > >>> > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> Thanks, > >>>>> Serguei > >>>>> > >>>>> > >>>>> On 5/9/19 17:28, serguei.spitsyn at oracle.com > wrote: > >>>>>> David and Jc, > >>>>>> > >>>>>> Okay, I'll remove this line now. > >>>>>> Thank you for your comments. > >>>>>> > >>>>>> Let's let Jc to file a separate enhancement on this. > >>>>>> Then I'll file a CSR and prepare a fix. > >>>>>> > >>>>>> I hope, you both are Okay with the rest. > >>>>>> > >>>>>> Thanks! > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> On 5/9/19 17:17, Jean Christophe Beyler wrote: > >>>>>>> Hi Serguei, > >>>>>>> > >>>>>>> Adding to the difficulties that David is exposing, this won't > >>>>>>> work. You need to redo the xls definition because you need > the > >>>>>>> #define to be the numeric value directly and not the enum; > >>>>>>> otherwise it won't work in any usable way at preprocessor > time > >>>>>>> sadly. > >>>>>>> > >>>>>>> I think it makes sense to just do what you were planning > to do > >>>>>>> here without this and I'll file a bug and work out the CSR > path > >>>>>>> and review path separately and see what is do-able or not > then > >>>>>>> because I think it's too much work now "just for this now" if > >>>>>>> that makes sense :) > >>>>>>> Jc > >>>>>>> > >>>>>>> *From: *David Holmes > >>>>>>> >> > >>>>>>> *Date: *Thu, May 9, 2019 at 5:11 PM > >>>>>>> *To: *serguei.spitsyn at oracle.com > > >>>>>>> >, Jean Christophe Beyler > >>>>>>> *Cc: *serviceability-dev > >>>>>>> > >>>>>>> ??? On 10/05/2019 9:45 am, serguei.spitsyn at oracle.com > > >>>>>>> > wrote: > >>>>>>> ??? > Hi Jc, > >>>>>>> ??? > > >>>>>>> ??? > Okay, you convinced me - thanks! > >>>>>>> ??? > Added new line into the generated jvmti.h: > >>>>>>> ??? > > >>>>>>> ??? >? ? #define JVMTI_VERSION_LATEST JVMTI_VERSION > >>>>>>> > >>>>>>> ??? That requires a CSR as you are expanding the exported > >>>>>>> interface. > >>>>>>> > >>>>>>> ??? Also you need > >>>>>>> > >>>>>>> ??? #define JVMTI_VERSION_LATEST (JVMTI_VERSION) > >>>>>>> > >>>>>>> ??? as JVMTI_VERSION is itself an expression not a constant. > >>>>>>> That might > >>>>>>> ??? limit the utility of having such a define as you won't be > >>>>>>> able to > >>>>>>> ??? use it > >>>>>>> ??? in an ifdef guard to test a value AFAICS. > >>>>>>> > >>>>>>> ??? David > >>>>>>> > >>>>>>> ??? > I hope, it will help in your case. > >>>>>>> ??? > > >>>>>>> ??? > > >>>>>>> ??? > Updated webrev version is: > >>>>>>> ??? > > >>>>>>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.2/ > > > >>>>>>> > >>>>>>> ??? > > >>>>>>> ??? > > >>>>>>> ??? > This version includes suggestions from David. > >>>>>>> ??? > > >>>>>>> ??? > Thanks, > >>>>>>> ??? > Serguei > >>>>>>> ??? > > >>>>>>> ??? > > >>>>>>> ??? > > >>>>>>> ??? > On 5/9/19 14:17, Jean Christophe Beyler wrote: > >>>>>>> ??? >> Hi Serguei, > >>>>>>> ??? >> > >>>>>>> ??? >> Of course I can :) > >>>>>>> ??? >> > >>>>>>> ??? >> Consider, just randomly of course, the heap > sampling work > >>>>>>> that > >>>>>>> ??? got > >>>>>>> ??? >> added to JVMTI. Now imagine you'd want to test if it is > >>>>>>> ??? supported by a > >>>>>>> ??? >> given JVMTI version, you would write something like > this: > >>>>>>> ??? >> > >>>>>>> ??? >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { > >>>>>>> ??? >> ? jvmtiCapabilities caps; > >>>>>>> ??? >> ? memset(&caps, 0, sizeof(caps)); > >>>>>>> ??? >> ? if (jvmti->GetPotentialCapabilities(&caps) != > >>>>>>> ??? JVMTI_ERROR_NONE) { > >>>>>>> ??? >> ? ? LOG(WARNING) << "Failed to get potential > capabilities, > >>>>>>> ??? disabling > >>>>>>> ??? >> the heap " > >>>>>>> ??? >> ?<< "sampling monitor"; > >>>>>>> ??? >> ? ? return false; > >>>>>>> ??? >> ? } > >>>>>>> ??? >> > >>>>>>> ??? >> ? return caps.can_generate_sampled_object_alloc_events > >>>>>>> ??? >> ? ? ? && caps.can_generate_garbage_collection_events; > >>>>>>> ??? >> } > >>>>>>> ??? >> > >>>>>>> ??? >> Now, the problem is that this code cannot be used > if you > >>>>>>> ??? compile with > >>>>>>> ??? >> an older JDK such as JDK8 for example > >>>>>>> ??? >> because?can_generate_sampled_object_alloc_events > does not > >>>>>>> ??? exist yet > >>>>>>> ??? >> for that jvmti.h file. > >>>>>>> ??? >> > >>>>>>> ??? >> > >>>>>>> ??? >> In a perfect world, we might imagine that we are always > >>>>>>> ??? compiling with > >>>>>>> ??? >> the latest JVMTI headers but that is not always > true and, > >>>>>>> ??? therefore, > >>>>>>> ??? >> to have the code portable, we now have to do: > >>>>>>> ??? >> > >>>>>>> ??? >> bool HeapMonitor::Supported(jvmtiEnv *jvmti) { > >>>>>>> ??? >> #ifdef ENABLE_HEAP_SAMPLING > >>>>>>> ??? >> ? jvmtiCapabilities caps; > >>>>>>> ??? >> ? memset(&caps, 0, sizeof(caps)); > >>>>>>> ??? >> ? if (jvmti->GetPotentialCapabilities(&caps) != > >>>>>>> ??? JVMTI_ERROR_NONE) { > >>>>>>> ??? >> ? ? LOG(WARNING) << "Failed to get potential > capabilities, > >>>>>>> ??? disabling > >>>>>>> ??? >> the heap " > >>>>>>> ??? >> ?<< "sampling monitor"; > >>>>>>> ??? >> ? ? return false; > >>>>>>> ??? >> ? } > >>>>>>> ??? >> > >>>>>>> ??? >> ? return caps.can_generate_sampled_object_alloc_events > >>>>>>> ??? >> ? ? ? && caps.can_generate_garbage_collection_events; > >>>>>>> ??? >> #else > >>>>>>> ??? >> ? return false; > >>>>>>> ??? >> #endif > >>>>>>> ??? >> } > >>>>>>> ??? >> > >>>>>>> ??? >> Where ENABLE_HEAP_SAMPLING is defined if we did > compile with > >>>>>>> ??? JDK11 and > >>>>>>> ??? >> not defined if we compiled with JDK8. I can't use > >>>>>>> JVMTI_VERSION > >>>>>>> ??? >> because I can't use it in an #if because it is not > an enum. > >>>>>>> ??? Were it to > >>>>>>> ??? >> be a #define or were I to have a #define I could > use with a > >>>>>>> ??? version > >>>>>>> ??? >> number being bumped up, I could write something > such as: > >>>>>>> ??? >> > >>>>>>> ??? >> #ifdef JVMTI_VERSION_11 > >>>>>>> ??? >> > >>>>>>> ??? >> or something that looks in the value of the > JVMTI_VERSION > >>>>>>> if I > >>>>>>> ??? wanted. > >>>>>>> ??? >> Right now, I can't even do that! > >>>>>>> ??? >> > >>>>>>> ??? >> Hopefully this helps understand what I am talking > about :-), > >>>>>>> ??? >> Jc > >>>>>>> ??? >> > >>>>>>> ??? >> > >>>>>>> ??? >> > >>>>>>> ??? >> > >>>>>>> ??? >> On Thu, May 9, 2019 at 2:08 PM > serguei.spitsyn at oracle.com > >>>>>>> > > >>>>>>> ??? >> > >>>>>>> >> > >>>>>>> > > >>>>>>> ??? >> > >>>>>>> >>> wrote: > >>>>>>> ??? >> > >>>>>>> ??? >>? ? ?Hi Jc, > >>>>>>> ??? >> > >>>>>>> ??? >>? ? ?Thank you a lot for review! > >>>>>>> ??? >>? ? ?Some replies below. > >>>>>>> ??? >> > >>>>>>> ??? >> > >>>>>>> ??? >>? ? ?On 5/9/19 09:10, Jean Christophe Beyler wrote: > >>>>>>> ??? >>>? ? ?Hi Serguei, > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?FWIW, the change looks good and I think it's a > good > >>>>>>> idea > >>>>>>> ??? to do. > >>>>>>> ??? >>>? ? ?However, there is one thorn in our internal agent > >>>>>>> code is > >>>>>>> ??? that > >>>>>>> ??? >>>? ? ?the JVMTI_VERSION is in an enum. This makes us > >>>>>>> unable to > >>>>>>> ??? #if it > >>>>>>> ??? >>>? ? ?when adding usages of newer features/methods. > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?This probably could/should be a different webrev > >>>>>>> (which I > >>>>>>> ??? can do > >>>>>>> ??? >>>? ? ?if you like) but is there any way while you are > >>>>>>> changing this > >>>>>>> ??? >>>? ? ?that the enum for JVMTI_VERSION could become a > set of > >>>>>>> ??? #define? > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?So instead of: > >>>>>>> ??? >>>? ? ?enum { > >>>>>>> ??? >>> JVMTI_VERSION_1? ?= 0x30010000, > >>>>>>> ??? >>> JVMTI_VERSION_1_0 = 0x30010000, > >>>>>>> ??? >>> JVMTI_VERSION_1_1 = 0x30010100, > >>>>>>> ??? >>> JVMTI_VERSION_1_2 = 0x30010200, > >>>>>>> ??? >>> JVMTI_VERSION_9? ?= 0x30090000, > >>>>>>> ??? >>> JVMTI_VERSION_11? = 0x300B0000, > >>>>>>> ??? >>> > >>>>>>> ??? >>> JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * > >>>>>>> ??? 0x100) + > >>>>>>> ??? >>>? ? ?0? /* version: 11.0.0 */ > >>>>>>> ??? >>>? ? ?}; > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?We would get: > >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1 0x30010000 > >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_0 0x30010000 > >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_1 = 0x30010100 > >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_1_2 = 0x30010200 > >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_9? ?= 0x30090000 > >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION_11? = 0x300B0000 > >>>>>>> ??? >>>? ? ?#define JVMTI_VERSION (0x30000000 + (11 * > 0x10000) + > >>>>>>> (0 * > >>>>>>> ??? 0x100) > >>>>>>> ??? >>>? ? ?+ 0? /* version: 11.0.0 */) > >>>>>>> ??? >> > >>>>>>> ??? >>? ? ?It is interesting concern and suggestion. > >>>>>>> ??? >>? ? ?I'm not sure if it requires a CSR. > >>>>>>> ??? >> > >>>>>>> ??? >> > >>>>>>> ??? >>>? ? ?I actually don't care about any define of these > >>>>>>> except for > >>>>>>> ??? >>> ?JVMTI_VERSION; basically it would be useful so > that in > >>>>>>> ??? our agent > >>>>>>> ??? >>>? ? ?code we can test the JVMTI_VERSION with #if > macros to > >>>>>>> ??? protect the > >>>>>>> ??? >>>? ? ?code when new elements show up in future > versions. > >>>>>>> So it also > >>>>>>> ??? >>>? ? ?could be: > >>>>>>> ??? >>>? ? ?enum { > >>>>>>> ??? >>> JVMTI_VERSION_1? ?= 0x30010000, > >>>>>>> ??? >>> JVMTI_VERSION_1_0 = 0x30010000, > >>>>>>> ??? >>> JVMTI_VERSION_1_1 = 0x30010100, > >>>>>>> ??? >>> JVMTI_VERSION_1_2 = 0x30010200, > >>>>>>> ??? >>> JVMTI_VERSION_9? ?= 0x30090000, > >>>>>>> ??? >>> JVMTI_VERSION_11? = 0x300B0000, > >>>>>>> ??? >>> > >>>>>>> ??? >>> JVMTI_VERSION = 0x30000000 + (11 * 0x10000) + (0 * > >>>>>>> ??? 0x100) + > >>>>>>> ??? >>>? ? ?0? /* version: 11.0.0 */ > >>>>>>> ??? >>>? ? ?}; > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?#define JVMTI_LATEST_VERSION (0x30000000 + (11 * > >>>>>>> 0x10000) > >>>>>>> ??? + (0 * > >>>>>>> ??? >>>? ? ?0x100) + 0 /* version: 11.0.0 */) > >>>>>>> ??? >> > >>>>>>> ??? >>? ? ?I is not a problem to implement this one. > >>>>>>> ??? >>? ? ?But I'm not sure how does this really help in > your case. > >>>>>>> ??? >>? ? ?I do not see a point to test the JVMTI_VERSION > with > >>>>>>> #if as > >>>>>>> ??? it is > >>>>>>> ??? >>? ? ?always defined. > >>>>>>> ??? >>? ? ?Could you, please, elaborate a little bit more? > >>>>>>> ??? >> > >>>>>>> ??? >>? ? ?Thanks, > >>>>>>> ??? >>? ? ?Serguei > >>>>>>> ??? >> > >>>>>>> ??? >>>? ? ?Right now, I have to do weird things where I > detect the > >>>>>>> ??? jvmti.h > >>>>>>> ??? >>>? ? ?used at compile time to then do -DUSING_JDK11 > for the > >>>>>>> ??? agent at > >>>>>>> ??? >>>? ? ?compile time. > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?Thanks! > >>>>>>> ??? >>>? ? ?Jc > >>>>>>> ??? >>> > >>>>>>> ??? >>> > >>>>>>> ??? >>> > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?On Thu, May 9, 2019 at 8:48 AM > >>>>>>> serguei.spitsyn at oracle.com > >>>>>>> > > >>>>>>> ??? >>> ? > >>>>>>> >> > >>>>>>> > > >>>>>>> ??? >>> ? > >>>>>>> >>> wrote: > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ? ? ?I'll try to get rid of VERSION_INTERIM. > >>>>>>> ??? >>>? ? ? ? ?Always using just VERSION_FEATURE.0.0 > should not > >>>>>>> ??? create problems > >>>>>>> ??? >>>? ? ? ? ?if we do not change JVMTI spec in > VERSION_UPDATE. > >>>>>>> ??? >>>? ? ? ? ?I do not see why we would change the JVMTI > spec > >>>>>>> in update > >>>>>>> ??? >>> ?releases. > >>>>>>> ??? >>>? ? ? ? ?But if we do then using VERSION_UPDATE as > >>>>>>> ??? microversion would > >>>>>>> ??? >>>? ? ? ? ?be good enough. > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ? ? ?Thanks! > >>>>>>> ??? >>>? ? ? ? ?Serguei > >>>>>>> ??? >>> > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ? ? ?On 5/9/19 06:13, David Holmes wrote: > >>>>>>> ??? >>>? ? ? ? ?> Hi Serguei, > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> On 9/05/2019 7:09 pm, > serguei.spitsyn at oracle.com > >>>>>>> > > >>>>>>> ??? >>> ? > >>>>>>> >> wrote: > >>>>>>> ??? >>>? ? ? ? ?>> Hi David, > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> Thank you a lot for review! > >>>>>>> ??? >>>? ? ? ? ?>> There are some replies below. > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> On 5/8/19 18:42, David Holmes wrote: > >>>>>>> ??? >>> ?>>> Hi Serguei, > >>>>>>> ??? >>> ?>>> > >>>>>>> ??? >>> ?>>> On 9/05/2019 8:57 am, > >>>>>>> serguei.spitsyn at oracle.com > >>>>>>> > > >>>>>>> ??? >>> ? > >>>>>>> ???? >> wrote: > >>>>>>> ??? >>> ?>>>> Please, review a fix for the task: > >>>>>>> ??? >>> ?>>>> > >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8219023 > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> ?>>>> Webrev: > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> > >>>>>>> > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/ > > > >>>>>>> > >>>>>>> ??? >>> > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> ?>>>> Summary: > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> ?>>>> ??By design as we have never bumped the JVMTI > >>>>>>> ??? version unless > >>>>>>> ??? >>> ?>>>> ??there were spec changes for that release. > >>>>>>> Now > >>>>>>> ??? we want > >>>>>>> ??? >>>? ? ? ? ?to sync > >>>>>>> ??? >>> ?>>>> ??the JVMTI version with the JDK version > >>>>>>> ??? regardless of > >>>>>>> ??? >>>? ? ? ? ?whether > >>>>>>> ??? >>> ?>>>> ??or not spec changes have occurred in that > >>>>>>> release. > >>>>>>> ??? >>> ?>>>> ??Also, we want it automatically set by the > >>>>>>> ??? build system > >>>>>>> ??? >>>? ? ? ? ?so that > >>>>>>> ??? >>> ?>>>> ??no manual updates are needed for each > >>>>>>> release. > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> ?>>>> ??The jvmti.h and jvmti.html (JVMTI spec) are > >>>>>>> ??? generated from > >>>>>>> ??? >>> ?>>>> ??the jvmti.xsl with the XSLT scripts now. So, > >>>>>>> ??? the fix > >>>>>>> ??? >>>? ? ? ? ?removes > >>>>>>> ??? >>> ?>>>> ??hard coded major, minor and micro versions > >>>>>>> ??? from the > >>>>>>> ??? >>> ?jvmti.xml > >>>>>>> ??? >>> ?>>>> ??and passes major and minor parameters > >>>>>>> with the > >>>>>>> ??? -PARAMETER > >>>>>>> ??? >>> ?>>>> ??to the XSL transformation. > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> ?>>>> ??Another part of the fix is in the JDI > >>>>>>> which starts > >>>>>>> ??? >>>? ? ? ? ?using JDK > >>>>>>> ??? >>> ?>>>> ??versions now instead of maintaining its own, > >>>>>>> ??? and in > >>>>>>> ??? >>>? ? ? ? ?the JDWP > >>>>>>> ??? >>> ?>>>> ??agent which is using the JVMTI versions > >>>>>>> ??? instead of its > >>>>>>> ??? >>>? ? ? ? ?own. > >>>>>>> ??? >>> ?>>> > >>>>>>> ??? >>> ?>>> This all seems reasonable (though I'm no > >>>>>>> expert on > >>>>>>> ??? >>>? ? ? ? ?working with XSL > >>>>>>> ??? >>> ?>>> etc). > >>>>>>> ??? >>> ?>>> > >>>>>>> ??? >>> ?>>> One thing I am unclear of is why you bother > >>>>>>> with > >>>>>>> ??? using > >>>>>>> ??? >>> ?>>> VERSION_INTERIM when the actual version check > >>>>>>> ??? will only > >>>>>>> ??? >>>? ? ? ? ?consider > >>>>>>> ??? >>> ?>>> VERSION_FEATURE (aka major). Couldn't you just > >>>>>>> ??? leave the > >>>>>>> ??? >>>? ? ? ? ?"minor" > >>>>>>> ??? >>> ?>>> part 0 the same as the "micro" part? > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> This is right question to ask. > >>>>>>> ??? >>>? ? ? ? ?>> I was two-folded on this. > >>>>>>> ??? >>>? ? ? ? ?>> But finally decided to maintain minor > version > >>>>>>> (aka > >>>>>>> ??? >>> ?VERSION_INTERIM). > >>>>>>> ??? >>>? ? ? ? ?>> Then the JVMTI and debugger version will > >>>>>>> match the > >>>>>>> ??? VM and > >>>>>>> ??? >>>? ? ? ? ?JDK version > >>>>>>> ??? >>>? ? ? ? ?>> for update releases. > >>>>>>> ??? >>>? ? ? ? ?>> If understand it correctly, we are still > >>>>>>> going to have > >>>>>>> ??? >>> ?major.minor > >>>>>>> ??? >>>? ? ? ? ?>> versions. > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> Not really. What we have now are things > like > >>>>>>> 11.0.3 and > >>>>>>> ??? >>>? ? ? ? ?12.0.1 - only > >>>>>>> ??? >>>? ? ? ? ?> using the first and third parts. The > full 4 part > >>>>>>> ??? version > >>>>>>> ??? >>>? ? ? ? ?string is: > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>> > >>>>>>> > ?$VERSION_FEATURE.$VERSION_INTERIM.$VERSION_UPDATE.$VERSION_PATCH > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> and we typically only update > version_feature and > >>>>>>> ??? >>> ?version_update. > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> https://openjdk.java.net/jeps/322 > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?>> Also, the JVMTI GetVersionNumberspec still > >>>>>>> tells about > >>>>>>> ??? >>>? ? ? ? ?both minor and > >>>>>>> ??? >>>? ? ? ? ?>> micro versions. > >>>>>>> ??? >>>? ? ? ? ?>> It also defines special constants for > >>>>>>> ??? corresponding masks > >>>>>>> ??? >>>? ? ? ? ?and shifts: > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> ??? Version Masks > >>>>>>> ??? >>>? ? ? ? ?>> ??? Constant Value Description > >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_INTERFACE_TYPE| > 0x70000000 > >>>>>>> ??? >>>? ? ? ? ?Mask to > >>>>>>> ??? >>>? ? ? ? ?>> extract > >>>>>>> ??? >>>? ? ? ? ?>> ??? interface type. The value of the > version > >>>>>>> ??? returned by > >>>>>>> ??? >>>? ? ? ? ?this function > >>>>>>> ??? >>>? ? ? ? ?>> ??? masked with > >>>>>>> |JVMTI_VERSION_MASK_INTERFACE_TYPE| is always > >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_INTERFACE_JVMTI| since > this is > >>>>>>> a JVMTI > >>>>>>> ??? >>> ?function. > >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MAJOR| 0x0FFF0000 > >>>>>>> Mask to > >>>>>>> ??? >>>? ? ? ? ?extract major > >>>>>>> ??? >>>? ? ? ? ?>> ??? version number. > >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MINOR| 0x0000FF00 > >>>>>>> Mask to > >>>>>>> ??? >>>? ? ? ? ?extract minor > >>>>>>> ??? >>>? ? ? ? ?>> ??? version number. > >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_MASK_MICRO| 0x000000FF > >>>>>>> Mask to > >>>>>>> ??? >>>? ? ? ? ?extract micro > >>>>>>> ??? >>>? ? ? ? ?>> ??? version number. > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> ??? Version Shifts > >>>>>>> ??? >>>? ? ? ? ?>> ??? Constant Value Description > >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MAJOR|???? 16 Shift to > >>>>>>> ??? extract major > >>>>>>> ??? >>>? ? ? ? ?>> version number. > >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MINOR|???? 8 Shift to > >>>>>>> extract > >>>>>>> ??? minor > >>>>>>> ??? >>>? ? ? ? ?>> version number. > >>>>>>> ??? >>>? ? ? ? ?>> |JVMTI_VERSION_SHIFT_MICRO|???? 0 Shift to > >>>>>>> extract > >>>>>>> ??? micro > >>>>>>> ??? >>>? ? ? ? ?>> version number. > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> This is link to the spec: > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>> > >>>>>>> > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#GetVersionNumber > > >>>>>>> > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> It seems, changing (and/or deprecating) > this > >>>>>>> will give > >>>>>>> ??? >>>? ? ? ? ?more problems > >>>>>>> ??? >>>? ? ? ? ?>> than benefits. > >>>>>>> ??? >>>? ? ? ? ?>> It is better to remain compatible with > previous > >>>>>>> ??? releases. > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> This is a problem that was flagged when > the new > >>>>>>> ??? versioning > >>>>>>> ??? >>>? ? ? ? ?scheme was > >>>>>>> ??? >>>? ? ? ? ?> introduced but I'm guessing nothing was > actually > >>>>>>> ??? done about > >>>>>>> ??? >>>? ? ? ? ?it. They > >>>>>>> ??? >>>? ? ? ? ?> are not really compatible beyond the > >>>>>>> major/feature > >>>>>>> ??? part. > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> If we only update the spec version with the > >>>>>>> feature > >>>>>>> ??? version > >>>>>>> ??? >>>? ? ? ? ?then all > >>>>>>> ??? >>>? ? ? ? ?> versions will have the form N.0.0. However > >>>>>>> your changes > >>>>>>> ??? >>>? ? ? ? ?will also > >>>>>>> ??? >>>? ? ? ? ?> update if we happen to use a > VERSION_INTERIM > >>>>>>> for some > >>>>>>> ??? >>>? ? ? ? ?reason - though > >>>>>>> ??? >>>? ? ? ? ?> the version check will ignore that > anyway. I'm > >>>>>>> not > >>>>>>> ??? really > >>>>>>> ??? >>>? ? ? ? ?seeing the > >>>>>>> ??? >>>? ? ? ? ?> point in having that happen. > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> Maybe we do need to define a new version > API that > >>>>>>> ??? maps to > >>>>>>> ??? >>>? ? ? ? ?the new > >>>>>>> ??? >>>? ? ? ? ?> versioning scheme of OpenJDK ? But if we > did > >>>>>>> that we'd > >>>>>>> ??? >>>? ? ? ? ?still have to > >>>>>>> ??? >>>? ? ? ? ?> support the legacy mapping and I'd still > advocate > >>>>>>> ??? simply using > >>>>>>> ??? >>>? ? ? ? ?> VERSION_FEATURE.0.0. > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> It's tricky. > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>>? ? ? ? ?> David > >>>>>>> ??? >>>? ? ? ? ?> ----- > >>>>>>> ??? >>>? ? ? ? ?> > >>>>>>> ??? >>> ?>>> For the record I considered whether this > >>>>>>> needs a CSR > >>>>>>> ??? >>>? ? ? ? ?request and > >>>>>>> ??? >>> ?>>> concluded it did not as it doesn't involve > >>>>>>> ??? changing any > >>>>>>> ??? >>>? ? ? ? ?actual > >>>>>>> ??? >>> ?>>> specifications. > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> Okay, thanks. > >>>>>>> ??? >>>? ? ? ? ?>> I considered it too, made the same > conclusion > >>>>>>> but > >>>>>>> ??? still > >>>>>>> ??? >>>? ? ? ? ?have some > >>>>>>> ??? >>>? ? ? ? ?>> doubt. :) > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>>? ? ? ? ?>> Thanks! > >>>>>>> ??? >>>? ? ? ? ?>> Serguei > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>> ?>>> > >>>>>>> ??? >>> ?>>> Thanks, > >>>>>>> ??? >>> ?>>> David > >>>>>>> ??? >>> ?>>> > >>>>>>> ??? >>> ?>>>> Testing: > >>>>>>> ??? >>> ?>>>> ??Generated docs and jvmti.h and checked the > >>>>>>> ??? versions > >>>>>>> ??? >>>? ? ? ? ?are correct. > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> ?>>>> One could ask if we have to use same or > >>>>>>> similar > >>>>>>> ??? approach for > >>>>>>> ??? >>> ?>>>> other API's and tools, like JNI, JMX and so > >>>>>>> on. > >>>>>>> ??? >>> ?>>>> But these are not areas of my expertise or > >>>>>>> ??? responsibility. > >>>>>>> ??? >>> ?>>>> It just feels like there is some room for > >>>>>>> ??? unification here. > >>>>>>> ??? >>> ?>>>> > >>>>>>> ??? >>> ?>>>> Thanks, > >>>>>>> ??? >>> ?>>>> Serguei > >>>>>>> ??? >>>? ? ? ? ?>> > >>>>>>> ??? >>> > >>>>>>> ??? >>> > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?-- > >>>>>>> ??? >>> > >>>>>>> ??? >>>? ? ?Thanks, > >>>>>>> ??? >>>? ? ?Jc > >>>>>>> ??? >> > >>>>>>> ??? >> > >>>>>>> ??? >> > >>>>>>> ??? >> -- > >>>>>>> ??? >> > >>>>>>> ??? >> Thanks, > >>>>>>> ??? >> Jc > >>>>>>> ??? > > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Jc > >>>>>> > >>>>> > >>> > >> > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 14 20:20:30 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 14 May 2019 13:20:30 -0700 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent Message-ID: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> Please, review CSR: ? https://bugs.openjdk.java.net/browse/JDK-8223915 for enhancement: ? https://bugs.openjdk.java.net/browse/JDK-8046018 Summary: ?The spec of the "can_redefine_any_class" needs to be more clear and consistent. ?The suggestion is to change the "can_redefine_any_class" capability spec| ? from:|| ??? "Can modify (retransform or redefine) any modifiable class. See IsModifiableClass." ||| |to: "Can redefine any modifiable class. See IsModifiableClass. (can_redefine_classes must also be set)" |The RetransformClasses can cause class redefinitions. But I'm not sure, it is worth to me mentioned, as it is confusing. || Thanks, Serguei -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue May 14 21:52:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2019 07:52:04 +1000 Subject: JVMTI ExceptionCatch event clarification In-Reply-To: <5d763859-5d9a-1127-9649-37364b81d6e6@googlemail.com> References: <96510b52-76ea-5ece-d87d-b090abb8e6a1@googlemail.com> <8829b41e-e5e8-574f-dade-9a30bccf10ac@oracle.com> <5d763859-5d9a-1127-9649-37364b81d6e6@googlemail.com> Message-ID: <8ad970fc-5841-df88-6cae-b652656556dc@oracle.com> On 15/05/2019 4:52 am, Chris wrote: > Thanks a lot for the fast response and clarification. > > On 5/14/19 7:34 AM, David Holmes wrote: >> So yes I would say this is a bug. I filed: >> >> https://bugs.openjdk.java.net/browse/JDK-8223812 >> >> "JVM TI ExceptionCatch event is not posted when an exception is caught >> by a native method" >> >> Fix seems simple enough. > > Thank you for submitting the bug report. Will the fix also be ported to > OpenJDK 8? The affected versions list does not include "8". I added 8 to the affected version list. Whether this gets backported to 8u will be up to the folks maintaining the 8u project. You'd have to ask/lobby them on jdk8u-dev at openjdk.java.net once the fix is in the mainline (though I don't know when that will be). Cheers, David > -- Chris From Alan.Bateman at oracle.com Wed May 15 07:27:46 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 15 May 2019 08:27:46 +0100 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> Message-ID: On 14/05/2019 21:20, serguei.spitsyn at oracle.com wrote: > : > > Summary: > > ?The spec of the "can_redefine_any_class" needs to be more clear and > consistent. > ?The suggestion is to change the "can_redefine_any_class" capability spec| > ? from:|| > ??? "Can modify (retransform or redefine) any modifiable class. See > IsModifiableClass." ||| > |to: "Can redefine any modifiable class. See IsModifiableClass. > (can_redefine_classes must also be set)" | Can you summarize how this capability is used? At some point we may have modules that cannot be redefined so IsModifableClass has to return false (via its parameter) for classes in that module. The wording for the capability in that function seems to conflict. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed May 15 10:24:13 2019 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 15 May 2019 11:24:13 +0100 Subject: PING: Re: RFR: JDK-8184770: JDWP support for IPv6 In-Reply-To: <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com> References: <114d0c7e-9f88-7fab-d535-0fce9ef57945@oracle.com> <5C9CDDE6.90608@oracle.com> <29f35cad-3bcc-813c-dd41-b501b9440fba@oracle.com> <7a180db1-b1c0-c924-7f3b-725e51311f76@oracle.com> <1a836ba1-f8b9-7c0e-a8fb-1e6da25b5046@oracle.com> <6dedcf93-6afe-8ea9-f0dd-f8da8825910a@oracle.com> <6d6a4b53-7841-197e-96b3-7770ca8bdff2@oracle.com> <0d9682b2-3e67-1e88-05b6-204e4775373c@oracle.com> <9A966E51-F5D2-4B13-8F33-430F015637AA@oracle.com> <8c77acda-142d-54b7-1739-75a0f79f2385@oracle.com> Message-ID: <62488d96-be11-c64b-c154-a2c54052176a@oracle.com> Alex, On 13/05/2019 22:06, Alex Menkov wrote: > Hi Chris, Serguei, > > Updated webrev: > http://cr.openjdk.java.net/~amenkov/IPv6/webrev.05/ I'm ok with this version. > CSR (approved): > https://bugs.openjdk.java.net/browse/JDK-8223104 > > Changes (vs. webrev.04): > > - setsockopt(IPV6_V6ONLY) was moved from Win-specific code to shared > setOptionsCommon function (in socketTransport.c) > ? the value by default is "true" on Windows and is "false" on Unix, but > it can be overridden, so lets set it explicitly; > - a comment why the result of setsockopt(IPV6_V6ONLY) is ignored is added; > - added some comments as per Serguei request. > > About scopes support - I thought that the functionality is not important > for debugger, but I can implement it (I'd prefer to do it by separate RFE). Ok. -Chris. > --alex > > On 05/11/2019 03:39, Chris Hegarty wrote: >> >> >>> On 7 May 2019, at 19:40, serguei.spitsyn at oracle.com wrote: >>> >>> Hi guys, >>> >>> We need a couple of partial reviews for this enhancement: >>> >>> ? - From the net-dev to check IPv6-addresses related part. >>> ??? It does not need to be a thorough review. >>> ??? We need another pair of eyes to check for obvious typos or misses. >>> ??? Included Chris H. to mailing list in hope for some assistance. >>> ??? (Chris, we need some help to find one of the IPv6 experts.) >>> >>> ? - From the serviceability-dev to check if compatibility >>> ??? is not broken and nothing is missed. >>> ??? This includes part of code that is not directly involved >>> ??? into manipulations with the IPv4/IPv6 addresses. >>> ??? The related spec update is tracked by a sub-task: >>> ????? https://bugs.openjdk.java.net/browse/JDK-8221707 >>> >>> >>> Related CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8223104 >>> >>> The latest webrev: >>> http://cr.openjdk.java.net/~amenkov/IPv6/webrev.04/ >> >> >> src/jdk.jdwp.agent/windows/native/libdt_socket/socket_md.c >> >> ??? 223???? if (domain == AF_INET6) { >> ??? 224???????? int off = 0; >> ??? 225???????? // make the socket a dual mode socket >> ??? 226???????? setsockopt(fd, IPPROTO_IPV6, IPV6_V6ONLY, (char >> *)&off, sizeof(off)); >> ??? 227???? } >> ??? 228?? } >> >> ?? This code is fine, but maybe you want to expand the comment to >> ?? mention that the setsockopt may fail if IPv4 is not supported. And >> ?? that?s OK. >> >> ?? I cannot find a similar setting of IPV6_V6ONLY for the unix >> ?? equivalent. Why not, or where can it be found? >> >> src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c >> >> ?? There is a lot of native code here, I skimmed over it, seems >> ?? reasonable. There is an obvious lack of any reference to IPv6 >> ?? scopes. Can the address given to bind be an IPv6 link-local? >> ?? If so, then the scope will need to be parsed / set appropriately. >> ?? ( seems that the new test skips all scoped addresses? ) >> >> -Chris. >> From david.holmes at oracle.com Wed May 15 12:59:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 May 2019 22:59:00 +1000 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <354daa4d-4c50-1f79-1f64-c45310d11dce@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> <354daa4d-4c50-1f79-1f64-c45310d11dce@oracle.com> Message-ID: <7c79092f-5069-b4f1-da46-44d10411e0b3@oracle.com> Hi Robbin, On 15/05/2019 12:08 am, Robbin Ehn wrote: > Hi David, > > Full: > http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html > Inc: > http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html > > On 2019-05-09 06:46, David Holmes wrote: >> As Dan also hints at you are a bit inconsistent with keeping loops or >> replacing with lambda's. Anything that would do a "break" or "return" >> in the loop can't be converted to a lambda; but "continue" becomes >> "return" in the lambda version. >> >> Overall I'd just say forget about any internal iteration using lambdas >> and just make the simple changes needed for the loop version. It's a >> less disruptive change and doesn't add the complexity and overhead of >> lambda expressions. > > Lambdas removed! I got caught out by the cumulative patch file again :( Changes look good! >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java >> >> Existing: >> >> 76???????????????? JavaThread cur = threads.getJavaThreadAt(k); >> 77???????????????? if (cur.isJavaThread()) { >> >> How can cur possibly be anything other than a JavaThread? > > The SA seems to have a slightly different model, so only pure > JavaThreads return true. > ServiceThread, CompilerThread, etc, returns false. Ah - a poorly named method that emulates ThreadService::is_hidden_thread. Thanks, David > >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java >> >> >> Same issue: >> >> ??463???????????? if (t.isJavaThread()) { >> >> Possibly more of these I didn't go searching - so probably separate >> cleanup RFE. >> >> --- >> >> Up to you whether you want to keep lambda's but at least ensure >> consistency in their use - ie use them everywhere you can. But you >> know my thoughts on it. :) > > Removed! > > Thanks, Robbin. > >> >> Thanks, >> David >> ----- >> >>> >>> http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ >>> http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ >>> >>> /Robbin >>> >>> On 2019-05-08 11:17, Robbin Ehn wrote: >>>> Hi David, >>>> >>>> I changed to normal for: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>>> >>>> >>>> Full: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>>> Inc: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>>> >>>> Passes t1-2 >>>> >>>> Thanks, Robbin >>>> >>>> >>>> On 2019-05-07 09:47, David Holmes wrote: >>>>> Hi Robbin, >>>>> >>>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>>> Hi David, >>>>>> >>>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>>> Hi Robbin, >>>>>>> >>>>>>> I have a few concerns here. >>>>>>> >>>>>>> First I can't see how you are actually integrating the SA with >>>>>>> the ThreadSMR. You've exposed the _java_thread_list for it to >>>>>>> iterate but IIRC that list can be updated when threads are >>>>>>> added/removed and I'm not seeing how the SA is left iterating a >>>>>>> valid list - we'd normally using a ThreadsListHandle for that ?? >>>>>>> (I may need a refresher on how this list is actually maintained.) >>>>>> >>>>>> The processes must be paused. If the processes would be running >>>>>> the linked list is also broken since if we unlink and delete a >>>>>> JavaThread and then later SA follows that _next pointer. >>>>> >>>>> Ah good point. Thanks for clarifying. >>>>> >>>>>>> >>>>>>> The conversion from external iteration of the list (the for loop) >>>>>>> to internal iteration (passing a lambda to JavaThreadsDo) is also >>>>>>> problematic. First I'd be very wary about introducing lambda >>>>>>> expressions into the SA code - lambda drags in a lot of >>>>>>> supporting code that could have an impact on the way SA >>>>>>> functions. There are places where we have to avoid lambdas due to >>>>>>> bootstrapping/initialization issues and I think the SA may be an >>>>>>> area where we also want to keep the code extremely simple. >>>>>> >>>>>> There are already several usages of lambdas in SA code, e.g. >>>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an >>>>>> application, there is not a bootstrap issue or so. >>>>> >>>>> Hmm okay. Lambda carries a lot of baggage. But if its already being >>>>> used ... >>>>> >>>>>>> Second by using lambda's with internal iteration you've lost the >>>>>>> ability to terminate the iteration loop! In the existing code if >>>>>>> we have a return in the for-loop then we not only terminate the >>>>>>> loop but the enclosing method. With the lambda the "return" just >>>>>>> ends the current iteration and JavaThreadsDo will then continue >>>>>>> with the next thread - so we don't even terminate the iteration >>>>>>> let alone the method performing the iteration. So for places were >>>>>>> we want to process one thread, for example, we will continue to >>>>>>> iterate all remaining threads and just do nothing with them. >>>>>>> That's very inefficient. >>>>>> >>>>>> That's why I only used the internal iteration where we didn't have >>>>>> early returns. >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>>> - original code: >>>>> >>>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>>> 1557???????????? public void doit(Tokens t) { >>>>> ... >>>>> 1564???????????????????? for (JavaThread thread = threads.first(); >>>>> thread != null; thread = thread.next()) { >>>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>>> ByteArrayOutputStream(); >>>>> 1566???????????????????????? thread.printThreadIDOn(new >>>>> PrintStream(bos)); >>>>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>>>> 1568???????????????????????????? out.println("Thread " + >>>>> bos.toString() + " Address: " + thread.getAddress()); >>>>> ... >>>>> 1577???????????????????????????? } >>>>> 1578???????????????????????????? if (!all) return; >>>>> >>>>> That looks like an early return to me. >>>>> >>>>> Cheers, >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Thanks, Robbin >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>>> Hi, please review. >>>>>>>> >>>>>>>> Old threads linked list remove and updated SA to use ThreadsList >>>>>>>> array instead. >>>>>>>> >>>>>>>> Issue: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>>> >>>>>>>> Passes t1-3 (which includes SA tests). >>>>>>>> >>>>>>>> Thanks, Robbin From robbin.ehn at oracle.com Wed May 15 13:20:07 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 15 May 2019 15:20:07 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <7c79092f-5069-b4f1-da46-44d10411e0b3@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> <354daa4d-4c50-1f79-1f64-c45310d11dce@oracle.com> <7c79092f-5069-b4f1-da46-44d10411e0b3@oracle.com> Message-ID: On 2019-05-15 14:59, David Holmes wrote: >> Lambdas removed! > > I got caught out by the cumulative patch file again :( > > Changes look good! Thanks David! /Robbin > >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java >>> >>> Existing: >>> >>> 76???????????????? JavaThread cur = threads.getJavaThreadAt(k); >>> 77???????????????? if (cur.isJavaThread()) { >>> >>> How can cur possibly be anything other than a JavaThread? >> >> The SA seems to have a slightly different model, so only pure JavaThreads >> return true. >> ServiceThread, CompilerThread, etc, returns false. > > Ah - a poorly named method that emulates ThreadService::is_hidden_thread. > > Thanks, > David > >> >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java >>> >>> Same issue: >>> >>> ??463???????????? if (t.isJavaThread()) { >>> >>> Possibly more of these I didn't go searching - so probably separate cleanup RFE. >>> >>> --- >>> >>> Up to you whether you want to keep lambda's but at least ensure consistency >>> in their use - ie use them everywhere you can. But you know my thoughts on >>> it. :) >> >> Removed! >> >> Thanks, Robbin. >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ >>>> http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ >>>> >>>> /Robbin >>>> >>>> On 2019-05-08 11:17, Robbin Ehn wrote: >>>>> Hi David, >>>>> >>>>> I changed to normal for: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>>>> >>>>> >>>>> Full: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>>>> Inc: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>>>> >>>>> Passes t1-2 >>>>> >>>>> Thanks, Robbin >>>>> >>>>> >>>>> On 2019-05-07 09:47, David Holmes wrote: >>>>>> Hi Robbin, >>>>>> >>>>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>>>> Hi Robbin, >>>>>>>> >>>>>>>> I have a few concerns here. >>>>>>>> >>>>>>>> First I can't see how you are actually integrating the SA with the >>>>>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate but >>>>>>>> IIRC that list can be updated when threads are added/removed and I'm not >>>>>>>> seeing how the SA is left iterating a valid list - we'd normally using a >>>>>>>> ThreadsListHandle for that ?? (I may need a refresher on how this list >>>>>>>> is actually maintained.) >>>>>>> >>>>>>> The processes must be paused. If the processes would be running the >>>>>>> linked list is also broken since if we unlink and delete a JavaThread and >>>>>>> then later SA follows that _next pointer. >>>>>> >>>>>> Ah good point. Thanks for clarifying. >>>>>> >>>>>>>> >>>>>>>> The conversion from external iteration of the list (the for loop) to >>>>>>>> internal iteration (passing a lambda to JavaThreadsDo) is also >>>>>>>> problematic. First I'd be very wary about introducing lambda expressions >>>>>>>> into the SA code - lambda drags in a lot of supporting code that could >>>>>>>> have an impact on the way SA functions. There are places where we have >>>>>>>> to avoid lambdas due to bootstrapping/initialization issues and I think >>>>>>>> the SA may be an area where we also want to keep the code extremely simple. >>>>>>> >>>>>>> There are already several usages of lambdas in SA code, e.g. >>>>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an application, >>>>>>> there is not a bootstrap issue or so. >>>>>> >>>>>> Hmm okay. Lambda carries a lot of baggage. But if its already being used ... >>>>>> >>>>>>>> Second by using lambda's with internal iteration you've lost the ability >>>>>>>> to terminate the iteration loop! In the existing code if we have a >>>>>>>> return in the for-loop then we not only terminate the loop but the >>>>>>>> enclosing method. With the lambda the "return" just ends the current >>>>>>>> iteration and JavaThreadsDo will then continue with the next thread - so >>>>>>>> we don't even terminate the iteration let alone the method performing >>>>>>>> the iteration. So for places were we want to process one thread, for >>>>>>>> example, we will continue to iterate all remaining threads and just do >>>>>>>> nothing with them. That's very inefficient. >>>>>>> >>>>>>> That's why I only used the internal iteration where we didn't have early >>>>>>> returns. >>>>>> >>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>>>> - original code: >>>>>> >>>>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>>>> 1557???????????? public void doit(Tokens t) { >>>>>> ... >>>>>> 1564???????????????????? for (JavaThread thread = threads.first(); thread >>>>>> != null; thread = thread.next()) { >>>>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>>>> ByteArrayOutputStream(); >>>>>> 1566???????????????????????? thread.printThreadIDOn(new PrintStream(bos)); >>>>>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>>>>> 1568???????????????????????????? out.println("Thread " + bos.toString() + >>>>>> " Address: " + thread.getAddress()); >>>>>> ... >>>>>> 1577???????????????????????????? } >>>>>> 1578???????????????????????????? if (!all) return; >>>>>> >>>>>> That looks like an early return to me. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> Thanks, Robbin >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>>>> Hi, please review. >>>>>>>>> >>>>>>>>> Old threads linked list remove and updated SA to use ThreadsList array >>>>>>>>> instead. >>>>>>>>> >>>>>>>>> Issue: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>>>> >>>>>>>>> Passes t1-3 (which includes SA tests). >>>>>>>>> >>>>>>>>> Thanks, Robbin From coleen.phillimore at oracle.com Wed May 15 13:46:43 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 May 2019 09:46:43 -0400 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 Message-ID: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> Summary: adjust old method table by only one thread. Entries were removed from the redefinition old method table by G1 by multiple threads at a safepoint, so didn't take the CodeCache_lock. Moved the removal to nmethod->flush().? The bug is confidential because there's a confidential comment not marked confidential but we'll open it up once that's fixed. Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp -XX:TieredStopAtLevel=1", including the PCL tests that in the oracle closed repo. Also ran hs-tier1-3. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8223585 Thanks, Coleen From coleen.phillimore at oracle.com Wed May 15 15:52:34 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 May 2019 11:52:34 -0400 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> <354daa4d-4c50-1f79-1f64-c45310d11dce@oracle.com> <7c79092f-5069-b4f1-da46-44d10411e0b3@oracle.com> Message-ID: <31e42fd7-5459-4050-eaa8-3db8db3a1716@oracle.com> Still looks good.? I guess we'll not have any lambdas to cut and paste in the SA now. Do you no longer need this? 191 public interface JavaThreadsDo { 192 void doJavaThread(JavaThread thread); 193 } 194 195 public void doJavaThreads(JavaThreadsDo jtDo) { 196 for (int i = 0; i < _list.length(); i++) { 197 jtDo.doJavaThread(getJavaThreadAt(i)); 198 } 199 } 200 If you remove it, or not, I don't need to see this webrev again. Coleen On 5/15/19 9:20 AM, Robbin Ehn wrote: > On 2019-05-15 14:59, David Holmes wrote: >>> Lambdas removed! >> >> I got caught out by the cumulative patch file again :( >> >> Changes look good! > > Thanks David! > > /Robbin > >> >>>> >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java >>>> >>>> >>>> Existing: >>>> >>>> 76???????????????? JavaThread cur = threads.getJavaThreadAt(k); >>>> 77???????????????? if (cur.isJavaThread()) { >>>> >>>> How can cur possibly be anything other than a JavaThread? >>> >>> The SA seems to have a slightly different model, so only pure >>> JavaThreads return true. >>> ServiceThread, CompilerThread, etc, returns false. >> >> Ah - a poorly named method that emulates >> ThreadService::is_hidden_thread. >> >> Thanks, >> David >> >>> >>>> >>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java >>>> >>>> >>>> Same issue: >>>> >>>> ??463???????????? if (t.isJavaThread()) { >>>> >>>> Possibly more of these I didn't go searching - so probably separate >>>> cleanup RFE. >>>> >>>> --- >>>> >>>> Up to you whether you want to keep lambda's but at least ensure >>>> consistency in their use - ie use them everywhere you can. But you >>>> know my thoughts on it. :) >>> >>> Removed! >>> >>> Thanks, Robbin. >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ >>>>> http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ >>>>> >>>>> /Robbin >>>>> >>>>> On 2019-05-08 11:17, Robbin Ehn wrote: >>>>>> Hi David, >>>>>> >>>>>> I changed to normal for: >>>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>>>>> >>>>>> >>>>>> Full: >>>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>>>>> Inc: >>>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>>>>> >>>>>> Passes t1-2 >>>>>> >>>>>> Thanks, Robbin >>>>>> >>>>>> >>>>>> On 2019-05-07 09:47, David Holmes wrote: >>>>>>> Hi Robbin, >>>>>>> >>>>>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>>>>> Hi Robbin, >>>>>>>>> >>>>>>>>> I have a few concerns here. >>>>>>>>> >>>>>>>>> First I can't see how you are actually integrating the SA with >>>>>>>>> the ThreadSMR. You've exposed the _java_thread_list for it to >>>>>>>>> iterate but IIRC that list can be updated when threads are >>>>>>>>> added/removed and I'm not seeing how the SA is left iterating >>>>>>>>> a valid list - we'd normally using a ThreadsListHandle for >>>>>>>>> that ?? (I may need a refresher on how this list is actually >>>>>>>>> maintained.) >>>>>>>> >>>>>>>> The processes must be paused. If the processes would be running >>>>>>>> the linked list is also broken since if we unlink and delete a >>>>>>>> JavaThread and then later SA follows that _next pointer. >>>>>>> >>>>>>> Ah good point. Thanks for clarifying. >>>>>>> >>>>>>>>> >>>>>>>>> The conversion from external iteration of the list (the for >>>>>>>>> loop) to internal iteration (passing a lambda to >>>>>>>>> JavaThreadsDo) is also problematic. First I'd be very wary >>>>>>>>> about introducing lambda expressions into the SA code - lambda >>>>>>>>> drags in a lot of supporting code that could have an impact on >>>>>>>>> the way SA functions. There are places where we have to avoid >>>>>>>>> lambdas due to bootstrapping/initialization issues and I think >>>>>>>>> the SA may be an area where we also want to keep the code >>>>>>>>> extremely simple. >>>>>>>> >>>>>>>> There are already several usages of lambdas in SA code, e.g. >>>>>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an >>>>>>>> application, there is not a bootstrap issue or so. >>>>>>> >>>>>>> Hmm okay. Lambda carries a lot of baggage. But if its already >>>>>>> being used ... >>>>>>> >>>>>>>>> Second by using lambda's with internal iteration you've lost >>>>>>>>> the ability to terminate the iteration loop! In the existing >>>>>>>>> code if we have a return in the for-loop then we not only >>>>>>>>> terminate the loop but the enclosing method. With the lambda >>>>>>>>> the "return" just ends the current iteration and JavaThreadsDo >>>>>>>>> will then continue with the next thread - so we don't even >>>>>>>>> terminate the iteration let alone the method performing the >>>>>>>>> iteration. So for places were we want to process one thread, >>>>>>>>> for example, we will continue to iterate all remaining threads >>>>>>>>> and just do nothing with them. That's very inefficient. >>>>>>>> >>>>>>>> That's why I only used the internal iteration where we didn't >>>>>>>> have early returns. >>>>>>> >>>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>>>>> - original code: >>>>>>> >>>>>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>>>>> 1557???????????? public void doit(Tokens t) { >>>>>>> ... >>>>>>> 1564???????????????????? for (JavaThread thread = >>>>>>> threads.first(); thread != null; thread = thread.next()) { >>>>>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>>>>> ByteArrayOutputStream(); >>>>>>> 1566 thread.printThreadIDOn(new PrintStream(bos)); >>>>>>> 1567???????????????????????? if (all || >>>>>>> bos.toString().equals(name)) { >>>>>>> 1568???????????????????????????? out.println("Thread " + >>>>>>> bos.toString() + " Address: " + thread.getAddress()); >>>>>>> ... >>>>>>> 1577???????????????????????????? } >>>>>>> 1578???????????????????????????? if (!all) return; >>>>>>> >>>>>>> That looks like an early return to me. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> Thanks, Robbin >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>>>>> Hi, please review. >>>>>>>>>> >>>>>>>>>> Old threads linked list remove and updated SA to use >>>>>>>>>> ThreadsList array instead. >>>>>>>>>> >>>>>>>>>> Issue: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>>>>> >>>>>>>>>> Passes t1-3 (which includes SA tests). >>>>>>>>>> >>>>>>>>>> Thanks, Robbin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed May 15 16:34:13 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 15 May 2019 09:34:13 -0700 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> Message-ID: <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Looks good. Thanks, Vladimir On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: > Summary: adjust old method table by only one thread. > > Entries were removed from the redefinition old method table by G1 by multiple threads at a safepoint, so didn't take the > CodeCache_lock. Moved the removal to nmethod->flush().? The bug is confidential because there's a confidential comment > not marked confidential but we'll open it up once that's fixed. > > Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp -XX:TieredStopAtLevel=1", including the PCL tests that > in the oracle closed repo. > > Also ran hs-tier1-3. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8223585 > > Thanks, > Coleen From jcbeyler at google.com Wed May 15 17:04:05 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 15 May 2019 10:04:05 -0700 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Message-ID: Hi Coleen, Looks good to me (not an official reviewer), Jc *From: *Vladimir Kozlov *Date: *Wed, May 15, 2019 at 9:34 AM *To: * , hotspot-dev developers, serviceability-dev at openjdk.java.net Looks good. > > Thanks, > Vladimir > > On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: > > Summary: adjust old method table by only one thread. > > > > Entries were removed from the redefinition old method table by G1 by > multiple threads at a safepoint, so didn't take the > > CodeCache_lock. Moved the removal to nmethod->flush(). The bug is > confidential because there's a confidential comment > > not marked confidential but we'll open it up once that's fixed. > > > > Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp > -XX:TieredStopAtLevel=1", including the PCL tests that > > in the oracle closed repo. > > > > Also ran hs-tier1-3. > > > > open webrev at > http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev > > bug link https://bugs.openjdk.java.net/browse/JDK-8223585 > > > > Thanks, > > Coleen > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed May 15 18:51:55 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 May 2019 14:51:55 -0400 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Message-ID: <841fe30a-4aa7-2f2c-5ca3-3354dd907a09@oracle.com> Thanks JC! Coleen On 5/15/19 1:04 PM, Jean Christophe Beyler wrote: > Hi Coleen, > > Looks good to me (not an official reviewer), > Jc > > *From: *Vladimir Kozlov > > *Date: *Wed, May 15, 2019 at 9:34 AM > *To: * >, hotspot-dev developers, > serviceability-dev at openjdk.java.net > > > Looks good. > > Thanks, > Vladimir > > On 5/15/19 6:46 AM, coleen.phillimore at oracle.com > wrote: > > Summary: adjust old method table by only one thread. > > > > Entries were removed from the redefinition old method table by > G1 by multiple threads at a safepoint, so didn't take the > > CodeCache_lock. Moved the removal to nmethod->flush().? The bug > is confidential because there's a confidential comment > > not marked confidential but we'll open it up once that's fixed. > > > > Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp > -XX:TieredStopAtLevel=1", including the PCL tests that > > in the oracle closed repo. > > > > Also ran hs-tier1-3. > > > > open webrev at > http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev > > bug link https://bugs.openjdk.java.net/browse/JDK-8223585 > > > > Thanks, > > Coleen > > > > -- > > Thanks, > Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleen.phillimore at oracle.com Wed May 15 18:51:41 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 May 2019 14:51:41 -0400 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Message-ID: <191f9a4d-2503-ecae-fab9-50b1515cdf74@oracle.com> Thanks Vladimir! Coleen On 5/15/19 12:34 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: >> Summary: adjust old method table by only one thread. >> >> Entries were removed from the redefinition old method table by G1 by >> multiple threads at a safepoint, so didn't take the CodeCache_lock. >> Moved the removal to nmethod->flush().? The bug is confidential >> because there's a confidential comment not marked confidential but >> we'll open it up once that's fixed. >> >> Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp >> -XX:TieredStopAtLevel=1", including the PCL tests that in the oracle >> closed repo. >> >> Also ran hs-tier1-3. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8223585 >> >> Thanks, >> Coleen From daniil.x.titov at oracle.com Wed May 15 19:15:21 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Wed, 15 May 2019 12:15:21 -0700 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: <8386d219-7680-63e7-cd0b-4e671938cac6@oracle.com> References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> <5D669D64-3296-4F34-BDA0-17E467F2F94A@oracle.com> <8386d219-7680-63e7-cd0b-4e671938cac6@oracle.com> Message-ID: Hi David, Chris, and JC, Please review a new version of the change that also fixes the similar problems in ClassTypeImpl.subclasses(), InterfaceTypeImpl.subinterfaces(), and InterfaceTypeImpl.implementors() methods. The fix moves the common code that iterates over all loaded types while ignoring ObjectCollectedException in a new method VirtualMachineImpl.forEachClass(Consumer). Method ReferenceTypeImpl.nestedTypes() doesn't have this problem (since the only method it calls on a reference type is name() that cannot throw ObjectCollectedException()). However, to avoid potential pitfalls in the future if someone decides to change this code, I modified this method to use the same pattern as in the cases listed above. All vmTestbase/nsk/jdi tests as well as tier1, tier2, and tier3 tests succeeded. Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.02 Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 Thanks, Daniil ?On 5/13/19, 2:59 PM, "David Holmes" wrote: Hi Daniil, On 14/05/2019 5:56 am, Daniil Titov wrote: > Hi David, > > It seems as the chances that class unloading happens during the life-time of these tests are extremely low and switching Graal on increases these chances. At least without Graal I could not locate any test result that showed that ClassUnload event was posted. With Graal on 1 of 500 tests fails (at least on Windows platform, on other platforms it must be more rare if not zero) and I could not find any successful test showing that ClassUnload event was ever posted for any class. Interesting that only Graal exposes this ... though it may be that the reflection accessor actually relates to Graal code, hence the reason the unloading only shows up with Graal. It may mean there is a hole in our test coverage with JDI - may need some tests that involve executing reflection code with accessors eagerly generated so that we do see class-unload events. Though timing would be problematic. > You are right, the similar problem exists for ClassTypeImpl. subclasses() method and there is a separate issue for that: JDK-8223492. And while I was not able to reproduce it so far the logs provided in JDK-8223492 show that the problem here is the same. Initially I planned to keep these issues separated and proceed with JDK-8223492 after the current review is completed. But if you think it makes sense I could update the current webrev to include changes for ClassTypeImpl. subclasses() and then close JDK-8223492 as a duplicate. Entirely up to you. But I would be suspicious of all of the code that iterates vm.allClasses(). > I am also curious whether lambda forms, e.g. org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388, are supposed to be visible in JDI but I could not locate any discussion about this. I'm trying to find that out too - but we can deal with that as a separate issue. Thanks, David > Thanks! > --Daniil > > > Per tests data and additional tracing it seems as with Graal on the chances that class unloading happens during the test run are about 1/200 and only on Windows platform. Without Graal there were no single occurrence of the test when any ClassUnload event was posted. > > ?On 5/12/19, 3:19 PM, "David Holmes" wrote: > > Hi Daniil, > > On 12/05/2019 3:14 am, Daniil Titov wrote: > > Hi David, > > > > There are two ways how these reference types (for the classes that become unloaded later) could appear in the collection com.sun.tools.jdi.VirtualMachineImpl maintains and stores in VirtualMachineImpl.typesBySignature instance variable: > > 1) Initial load when all classes are requested from the debuggee > > 2) Or added later when ClassPrepare event for a specific class is posted and handled > > > > The reference types are removed from VirtualMachineImpl.typesBySignature when ClassUnload event is processed. However, additional tracing showed ( pleases see below the sample output) that in some cases these ClassUnload events are received after we entered definedClasses() method and started iterating over the copy of the collection of the classes returned by vm.allClasses() method. > > Thanks for clarifying that for me. I was thinking in this case that > definedClasses() was directly querying the target VM, but it isn't it's > iterating the existing set of known classes cached in the client > (vm.allClasses()). > > Though it seems that whether or not we will hit this > ObjectCollectedException depends on what we have already done with a > particular ReferenceType. In this case we hit the exception when > invoking classLoader() but that will only throw the exception if we do > not already have the classLoader cached and have to go and seek it from > the target VM. > > I do wonder why this issue should suddenly appear now? Encountering an > unloaded class, like a generated reflection accessor, should always have > been possible and so we should have seen this before. Something must > have changed recently. ?? > > I'm also concerned about other code that iterates through > vm.allClasses() and which does not seem to be aware of the possibility > of CollectedObjectException. For example in ClassTypeImpl.java we have: > > public List subclasses() { > List subs = new ArrayList<>(); > for (ReferenceType refType : vm.allClasses()) { > if (refType instanceof ClassType) { > ClassType clazz = (ClassType)refType; > ClassType superclass = clazz.superclass(); > if ((superclass != null) && superclass.equals(this)) { > subs.add((ClassType)refType); > } > } > } > > return subs; > } > > If the superclass is already cached then this will work, but if it has > to call to the target VM over JDWP then we will have the same bug I > think. Which again raises the question for me as to why we are not > seeing tests fail here? > > > Based on the output below it seems as all unloaded classes are the generated ones or lambda forms. > > > > --> debugger: ......getting: List definedClasses = clRef.definedClasses(); > > > > Received Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > Handled Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > This is fine - generated reflection accessor are loaded in a custom > classloader specifically so they can be unloaded promptly. But ... > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > ... these are I believe definitions of VM anonymous classes (they have > names of the form foo/ which are not legal class names). Should > these even be visible to JDI? > > Thanks, > David > ----- > > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > > Exception while getting classloader for type jdk.internal.reflect.GeneratedConstructorAccessor1 > > # ERROR: ##> debugger: ERROR: Exception : com.sun.jdi.ObjectCollectedException > > > > > > Thanks! > > --Daniil > > > > > > > > ?On 5/11/19, 3:39 AM, "David Holmes" wrote: > > > > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > > > Isn't that the point? The list returned could have unloaded classes and > > > we can catch it via this exception (from the comment above > > > the ReferenceType interface): > > > > > > * Any method on ReferenceType or which directly or > > > indirectly takes > > > * ReferenceType as parameter may throw > > > * {@link ObjectCollectedException} if the mirrored type has been unloaded. > > > > > > Turns out that even in the definedClasses, we can get that exception so > > > we should check for it while walking the reference types as well? > > > > I understand that the list returned to the "debugger" process may > > contain ReferenceTypes for types that have actually been unloaded by the > > time it queries them (unless the debuggee is suspended of course). But I > > don't see how we can encounter those types while compiling the list in > > the debuggee in the first place. > > > > Something seems amiss here ... possibly just my understanding ... > > > > David > > > > > Jc > > > > > > *From: *Chris Plummer > > > > > > *Date: *Fri, May 10, 2019 at 9:09 PM > > > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > > > > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > > > On 5/10/19 8:59 PM, David Holmes wrote: > > > >> Hi Daniil, > > > >> > > > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > > > >>> Please review the change that fixes an intermittent failure of the > > > >>> test. > > > >>> > > > >>> The tests checks the implementation of the > > > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > > > >>> that while > > > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > > > iterates > > > >>> over all loaded classes to retrieve a classloader and compares > > > it to > > > >>> the current one, some of the classes might become unloaded and > > > >>> garbage collected (e.g. > > > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > > > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > > > >>> happens then the attempt to retrieve a classloader for the > > > collected > > > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > > > >> > > > >> That seems odd to me. If you have a reference to the Class then it > > > >> can't be unloaded. I would not expect allClasses() to have > > > >> weak-references, so a class should not be unloadable while you are > > > >> examining it. Unless it is finding VM anonymous classes (which it > > > >> should not!). > > > >> > > > > I was just typing up something similar. Shouldn't the test do a > > > > vm.suspend() and then call disableCollection() on each class > > > returned > > > > by vm.allClasses()? > > > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > > > the user of ClassLoaderReference.definedClasses() to do the suspend. In > > > fact I'm not sure there's much purpose in calling > > > ClassLoaderReference.definedClasses() without suspending first. Even > > > with your changes, the list returned can end up with references to > > > unloaded classes. > > > > > > Chris > > > > > > > > Chris > > > >> David > > > >> ----- > > > >> > > > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > > > >>> continues iterating over the rest of the classes. > > > >>> > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > > > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > > >>> > > > >>> Thanks! > > > >>> --Daniil > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Thanks, > > > Jc > > > > > > > > > From alexey.menkov at oracle.com Wed May 15 21:07:19 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Wed, 15 May 2019 14:07:19 -0700 Subject: RFR: 8221707: JDWP support for IPv6 - spec update Message-ID: <0f99fe01-a6c7-ab6f-8414-97b8791924a1@oracle.com> Hi all, Please review the fix for "Connection and Invocation Details" page related to JDWP IPv6 support implementation. JBS: https://bugs.openjdk.java.net/browse/JDK-8221707 webrev: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/webrev/ resulting docs: old: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/0/conninv.html new: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/1/conninv.html specdiff: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/conninv.specdiff/diff.html --alex From serguei.spitsyn at oracle.com Wed May 15 21:55:22 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 14:55:22 -0700 Subject: RFR: 8221707: JDWP support for IPv6 - spec update In-Reply-To: <0f99fe01-a6c7-ab6f-8414-97b8791924a1@oracle.com> References: <0f99fe01-a6c7-ab6f-8414-97b8791924a1@oracle.com> Message-ID: Hi Alex, The fix looks good to me. Thanks, Serguei On 5/15/19 14:07, Alex Menkov wrote: > Hi all, > > Please review the fix for "Connection and Invocation Details" page > related to JDWP IPv6 support implementation. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8221707 > webrev: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/webrev/ > > resulting docs: > old: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/0/conninv.html > new: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/1/conninv.html > > specdiff: > http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/conninv.specdiff/diff.html > > > --alex From jcbeyler at google.com Wed May 15 22:40:17 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 15 May 2019 15:40:17 -0700 Subject: RFR: 8221707: JDWP support for IPv6 - spec update In-Reply-To: References: <0f99fe01-a6c7-ab6f-8414-97b8791924a1@oracle.com> Message-ID: Hi Alex, Looks good to me too. Only nit would be: " local loopback " -> " the local loopback". No need for a new webrev evidently, Jc *From: *serguei.spitsyn at oracle.com *Date: *Wed, May 15, 2019 at 2:56 PM *To: *Alex Menkov, OpenJDK Serviceability Hi Alex, > > The fix looks good to me. > > Thanks, > Serguei > > > On 5/15/19 14:07, Alex Menkov wrote: > > Hi all, > > > > Please review the fix for "Connection and Invocation Details" page > > related to JDWP IPv6 support implementation. > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8221707 > > webrev: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/webrev/ > > > > resulting docs: > > old: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/0/conninv.html > > new: http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/1/conninv.html > > > > specdiff: > > > http://cr.openjdk.java.net/~amenkov/IPv6/docs.01/conninv.specdiff/diff.html > > > > > > --alex > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 16 00:10:20 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 17:10:20 -0700 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Message-ID: <0d0062e5-5913-42a1-9d24-f19ac0b0da96@oracle.com> Hi Robbin, Looks good to me. Thanks, Serguei On 5/14/19 07:02, Robbin Ehn wrote: > Hi Dan, > > Full: > http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html > Inc: > http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html > > On 2019-05-08 18:02, Daniel D. Daugherty wrote: >> General comment - Please make sure to update all copyright years before >> ?????????????????? pushing this changeset. > > Fixed. > >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java >> ???? L46: >> ???? L47: ??? private static AddressField????? threadsField; >> ???? L48: ??? private static CIntegerField???? lengthField; >> ???????? nit - please delete blank line on L46 >> ???????? nit - please reduce the space between type and variable names >> ?????????????? (I have no preference if you still keep them aligned) >> >> ???? nit - Please delete blank line on L74. > > Fixed. > > >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java >> ???? old L203: ????? Threads threads = VM.getVM().getThreads(); >> ???? old L204: ????? for (JavaThread cur = threads.first(); cur != >> null; cur = cur.next()) { >> ???? new L203: ????? VM.getVM().getThreads().doJavaThreads((cur) -> { >> ???????? In this case, you did a lambda conversion... >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java >> >> ???? old L75: ??????????? for (JavaThread cur = threads.first(); cur >> != null; cur = cur.next(), i++) { >> ???? new L75: ??????????? for (int k = 0; k < >> threads.getNumberOfThreads(); k++) { >> ???? new L76: ??????????????? JavaThread cur = >> threads.getJavaThreadAt(k); >> ???????? In this case, you didn't do a lambda conversion... >> >> ???????? I'm trying to grok a reason for the different styles... >> ???????? Update: Is is maybe a control flow thing? (No, I don't know >> much >> ??????????? about lambdas.) As in: Loops that "break" or early return >> are >> ??????????? not amenable to conversion to a lambda... (just guessing) > > I converted those where it was easy to see that the loop did not have > an early termination. Lambdas removed. > >> >> ???? L74: ??????????? int i = 1; >> ???????? Not your bug, but I think that 'i' is not used. >> > > Fixed. > >> This all looks good to me... so thumbs up! > > Thanks. > >> >> I have some reservations about using lambdas in a debugging tool. >> My personal philosophy about debugging tools is that they should >> be built on the simplest/most stable technology to reduce the >> chances of the more complicated technology failing during a debug >> session. I hate it when my debugger crashes! > > I removed all lambdas! > > Thanks for looking at this, Robbin > >> >> That said, SA is pretty much standalone so use of lambdas in this >> debugging tool shouldn't affect the JVM or core file being debugged. >> >> Again, thumbs up! >> >> Dan >> >> >>> >>> /Robbin >>> >>> On 2019-05-08 11:17, Robbin Ehn wrote: >>>> Hi David, >>>> >>>> I changed to normal for: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>>> >>>> >>>> Full: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>>> Inc: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>>> >>>> Passes t1-2 >>>> >>>> Thanks, Robbin >>>> >>>> >>>> On 2019-05-07 09:47, David Holmes wrote: >>>>> Hi Robbin, >>>>> >>>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>>> Hi David, >>>>>> >>>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>>> Hi Robbin, >>>>>>> >>>>>>> I have a few concerns here. >>>>>>> >>>>>>> First I can't see how you are actually integrating the SA with >>>>>>> the ThreadSMR. You've exposed the _java_thread_list for it to >>>>>>> iterate but IIRC that list can be updated when threads are >>>>>>> added/removed and I'm not seeing how the SA is left iterating a >>>>>>> valid list - we'd normally using a ThreadsListHandle for that ?? >>>>>>> (I may need a refresher on how this list is actually maintained.) >>>>>> >>>>>> The processes must be paused. If the processes would be running >>>>>> the linked list is also broken since if we unlink and delete a >>>>>> JavaThread and then later SA follows that _next pointer. >>>>> >>>>> Ah good point. Thanks for clarifying. >>>>> >>>>>>> >>>>>>> The conversion from external iteration of the list (the for >>>>>>> loop) to internal iteration (passing a lambda to JavaThreadsDo) >>>>>>> is also problematic. First I'd be very wary about introducing >>>>>>> lambda expressions into the SA code - lambda drags in a lot of >>>>>>> supporting code that could have an impact on the way SA >>>>>>> functions. There are places where we have to avoid lambdas due >>>>>>> to bootstrapping/initialization issues and I think the SA may be >>>>>>> an area where we also want to keep the code extremely simple. >>>>>> >>>>>> There are already several usages of lambdas in SA code, e.g. >>>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an >>>>>> application, there is not a bootstrap issue or so. >>>>> >>>>> Hmm okay. Lambda carries a lot of baggage. But if its already >>>>> being used ... >>>>> >>>>>>> Second by using lambda's with internal iteration you've lost the >>>>>>> ability to terminate the iteration loop! In the existing code if >>>>>>> we have a return in the for-loop then we not only terminate the >>>>>>> loop but the enclosing method. With the lambda the "return" just >>>>>>> ends the current iteration and JavaThreadsDo will then continue >>>>>>> with the next thread - so we don't even terminate the iteration >>>>>>> let alone the method performing the iteration. So for places >>>>>>> were we want to process one thread, for example, we will >>>>>>> continue to iterate all remaining threads and just do nothing >>>>>>> with them. That's very inefficient. >>>>>> >>>>>> That's why I only used the internal iteration where we didn't >>>>>> have early returns. >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>>> - original code: >>>>> >>>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>>> 1557???????????? public void doit(Tokens t) { >>>>> ... >>>>> 1564???????????????????? for (JavaThread thread = threads.first(); >>>>> thread != null; thread = thread.next()) { >>>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>>> ByteArrayOutputStream(); >>>>> 1566???????????????????????? thread.printThreadIDOn(new >>>>> PrintStream(bos)); >>>>> 1567???????????????????????? if (all || >>>>> bos.toString().equals(name)) { >>>>> 1568???????????????????????????? out.println("Thread " + >>>>> bos.toString() + " Address: " + thread.getAddress()); >>>>> ... >>>>> 1577???????????????????????????? } >>>>> 1578???????????????????????????? if (!all) return; >>>>> >>>>> That looks like an early return to me. >>>>> >>>>> Cheers, >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Thanks, Robbin >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>>> Hi, please review. >>>>>>>> >>>>>>>> Old threads linked list remove and updated SA to use >>>>>>>> ThreadsList array instead. >>>>>>>> >>>>>>>> Issue: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>>> >>>>>>>> Passes t1-3 (which includes SA tests). >>>>>>>> >>>>>>>> Thanks, Robbin >> From sakamoto.osamu at nttcom.co.jp Thu May 16 00:57:17 2019 From: sakamoto.osamu at nttcom.co.jp (=?utf-8?B?5Z2C5pysIOe1sQ==?=) Date: Thu, 16 May 2019 00:57:17 +0000 Subject: debugd options should regard to jhsdb style In-Reply-To: <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> Message-ID: <04649AF8E13EB949B7D27EFDD2A37DFEE2B2725C@WMBOX4.soad.nttcom.co.jp> Hi Serguei, Do you think which is better, to add angle bracket or not to? > By the way, you've added angle brackets to jhsdb debugd --help in the CSR. > But current other commands --help don't have it. > I think this modification should be also added to other commands --help if it is added to debugd --help. > This CSR relates on only debugd, so I think this modification should be included to the RFE which David filed.(JDK-8223814) The webrev which is added angle bracket to debugd --help is here. Thanks, Osamu -- NTT ????????? ???????SE??OSS??? ???? TEL: 03-6713-3034 MAIL: -----Original Message----- From: Osamu Sakamoto Sent: Tuesday, May 14, 2019 4:22 PM To: serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net Cc: ?? ?? Subject: Re: debugd options should regard to jhsdb style Hi Serguei, Thank you for reviewing the CSR. I answer your questions. Q1 & Q2: and can accept both full path and relative path. Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently have the same format, and need not to be updated. By the way, you've added angle brackets to jhsdb debugd --help in the CSR. But current other commands --help don't have it. I think this modification should be also added to other commands --help if it is added to debugd --help. This CSR relates on only debugd, so I think this modification should be included to the RFE which David filed.(JDK-8223814) What do you think about this? Yasumasa has uploaded webrev.00.1 that angle bracket is added to debugd --help. I will request him to push the better one when this is clear Thanks, Osamu On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: > Hi Osamu, > > Sorry for reacting on this so late. > This work on cmd-line options unification is very welcome! > > I looked at the CSR and it looks pretty good in general. > > I've added angle brackets to the jhsdb debugd --help: > > |$ jhsdb debugd --help --serverid > --exe --core --pid process to attach> But this needs to be unified with other commands |||(clhsdb, hsdb, jstack, etc|), of course. | > > Also, added a comment with the questions: > > |Q1: Should the be always a full path name or it > can be a relative path? Q2: Should the be always a > full path name or it can be a relative path? Q3: Do all other commans > (clhsdb, hsdb, jstack, jmap, etc.) currently have the same format or > they also need to be updated?| > > > I can update the CSR description if you answer these questions. > They'll file an RFE for this. > > Thanks, > Serguei > > > > On 5/13/19 01:06, Osamu Sakamoto wrote: >> Hi David, >> >> Thank you for updating the CSR. >> I agree with filing a RFE to improve the general jhsdb help output. >> >> Could you file the RFE? (I can't access JBS.) >> I would like to contribute it if the RFE will be filed. >> >> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >> So I will request Yasumasa to push it to jdk/jdk when the status of >> CSR changes to Approved, and RFE for jhsdb help is filed. >> >> Thanks, >> Osamu >> >> >> On 5/13/19 16:00, David Holmes wrote: >>> >>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>> Hi, David >>>> >>>> I saw your comment in this CSR. >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>> >>>> I understand that the problem is that the help description of debugd >>>> I proposed and current other modes is not helpful for users. >>>> >>>> What should we do to go through this CSR? >>>> IMHO we should update help description of all jhsdb modes more helpful. >>>> Do you have any ideas about this? >>> >>> I think a RFE should be filed to improve the general jhsdb help >>> output, so that it explains that --pid and --exe are mutually >>> exclusive options. That way this CSR, and thus the associated RFE can >>> proceed. I'll add the same info the CSR. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/10/19 17:46, ?? ? wrote: >>>>> Hi, >>>>> >>>>> I agree with Yasumasa's opinion in CSR. >>>>> >>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>> jmap and so on) in jhdsb. >>>>> Certainly, usage of debugd which I proposed does not explain that >>>>> and cannot be used together, but it is not limited to >>>>> debugd - other modes have similar issue. >>>>> >>>>> I think it is helpful to detail help description in each jhsdb >>>>> modes, but I'd like to separate as another issue because this is >>>>> not limited to debugd. >>>>> >>>>> -----Original Message----- >>>>> From: Yasumasa Suenaga >>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>> To: David Holmes >>>>> Cc: Jean Christophe Beyler ; >>>>> serviceability-dev at openjdk.java.net >>>>> serviceability-dev at openjdk.java.net >>>>> ; ?? ? >>>>> >>>>> Subject: Re: debugd options should regard to jhsdb style >>>>> >>>>> Hi David, >>>>> >>>>> Thank you for checking in CSR, and sorry for my incorrect description. >>>>> I added my opinion to CSR. >>>>> >>>>> Osamu, do you have any opinion? >>>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>> >>>>>> Hi Yasumasa, >>>>>> >>>>>> I've made some updates to the CSR request and raised a couple of >>>>>> issues. >>>>>> >>>>>> FYI the specification section only needs to contain the actual >>>>>> specification for what has changed ie the new command-line options; >>>>>> not the implementation that will bring about those changes. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>> Thanks JC! >>>>>>> >>>>>>> I added key point of this change to specification section in CSR. >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>> : >>>>>>>> >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>> specification section could use some text and then send the reader >>>>>>>> to the other bug entry :) Jc >>>>>>>> >>>>>>>> From: Yasumasa Suenaga >>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>> >>>>>>>>> tests on submit repo have been passed >>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>> >>>>>>>>> Could you review the CSR? >>>>>>>>> >>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>> I will sponsor you. >>>>>>>>>> >>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>> >>>>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>> >>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>> to match other tools. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>> >>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>> --pid `. >>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>> >>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>> >>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>> >>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Osamu >>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jc > From jcbeyler at google.com Thu May 16 01:01:48 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 15 May 2019 18:01:48 -0700 Subject: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 Message-ID: Hi all, Could I get a review that restricts the test to not run on PPC64/IA64 please? Bug: https://bugs.openjdk.java.net/browse/JDK-8224020 Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.00/ I also moved NULL -> RTLD_DEFAULT as the man page on linux does not specify the behavior of passing NULL. Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 16 01:20:03 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 18:20:03 -0700 Subject: debugd options should regard to jhsdb style In-Reply-To: <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> Message-ID: Hi Osamu, On 5/14/19 00:21, Osamu Sakamoto wrote: > Hi Serguei, > > Thank you for reviewing the CSR. > > I answer your questions. > > Q1 & Q2: and can accept > both full path and relative path. It has to be clear in the help. I've updated the CSR with this. > Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently > have the same format, and need not to be updated. Thank you for the confirmation. > By the way, you've added angle brackets to jhsdb debugd --help in the > CSR. > But current other commands --help don't have it. > I think this modification should be also added to other commands > --help if it is added to debugd --help. > This CSR relates on only debugd, so I think this modification should > be included to the RFE which David filed.(JDK-8223814) > What do you think about this? I've added a comment about this to the RFE JDK-8223814. > > Yasumasa has uploaded webrev.00.1 that angle bracket is added to > debugd --help. > I will request him to push the better one when this is clear > Okay, thanks! I'll review it now. Thanks, Serguei > > Thanks, > Osamu > > > On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: >> Hi Osamu, >> >> Sorry for reacting on this so late. >> This work on cmd-line options unification is very welcome! >> >> I looked at the CSR and it looks pretty good in general. >> >> I've added angle brackets to the jhsdb debugd --help: >> >> |$ jhsdb debugd --help --serverid >> --exe --core --pid > process to attach> But this needs to be unified with other commands >> |||(clhsdb, hsdb, jstack, etc|), of course. | >> >> Also, added a comment with the questions: >> >> |Q1: Should the be always a full path name or >> it can be a relative path? Q2: Should the be >> always a full path name or it can be a relative path? Q3: Do all >> other commans (clhsdb, hsdb, jstack, jmap, etc.) currently have the >> same format or they also need to be updated?| >> >> >> I can update the CSR description if you answer these questions. >> They'll file an RFE for this. >> >> Thanks, >> Serguei >> >> >> >> On 5/13/19 01:06, Osamu Sakamoto wrote: >>> Hi David, >>> >>> Thank you for updating the CSR. >>> I agree with filing a RFE to improve the general jhsdb help output. >>> >>> Could you file the RFE? (I can't access JBS.) >>> I would like to contribute it if the RFE will be filed. >>> >>> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >>> So I will request Yasumasa to push it to jdk/jdk when the status of >>> CSR changes to Approved, and RFE for jhsdb help is filed. >>> >>> Thanks, >>> Osamu >>> >>> >>> On 5/13/19 16:00, David Holmes wrote: >>>> >>>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>>> Hi, David >>>>> >>>>> I saw your comment in this CSR. >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>> >>>>> I understand that the problem is that the help description of >>>>> debugd I proposed and current other modes is not helpful for users. >>>>> >>>>> What should we do to go through this CSR? >>>>> IMHO we should update help description of all jhsdb modes more >>>>> helpful. >>>>> Do you have any ideas about this? >>>> >>>> I think a RFE should be filed to improve the general jhsdb help >>>> output, so that it explains that --pid and --exe are mutually >>>> exclusive options. That way this CSR, and thus the associated RFE >>>> can proceed. I'll add the same info the CSR. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Osamu >>>>> >>>>> >>>>> On 5/10/19 17:46, ?? ? wrote: >>>>>> Hi, >>>>>> >>>>>> I agree with Yasumasa's opinion in CSR. >>>>>> >>>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>>> jmap and so on) in jhdsb. >>>>>> Certainly, usage of debugd which I proposed does not explain that >>>>>> and cannot be used together, but it is not limited to >>>>>> debugd - other modes have similar issue. >>>>>> >>>>>> I think it is helpful to detail help description in each jhsdb >>>>>> modes, but I'd like to separate as another issue because this is >>>>>> not limited to debugd. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Yasumasa Suenaga >>>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>>> To: David Holmes >>>>>> Cc: Jean Christophe Beyler ; >>>>>> serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> ; ?? ? >>>>>> >>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thank you for checking in CSR, and sorry for my incorrect >>>>>> description. >>>>>> I added my opinion to CSR. >>>>>> >>>>>> Osamu, do you have any opinion? >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>>> >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> I've made some updates to the CSR request and raised a couple of >>>>>>> issues. >>>>>>> >>>>>>> FYI the specification section only needs to contain the actual >>>>>>> specification for what has changed ie the new command-line options; >>>>>>> not the implementation that will bring about those changes. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>>> Thanks JC! >>>>>>>> >>>>>>>> I added key point of this change to specification section in CSR. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>>> : >>>>>>>>> >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>>> specification section could use some text and then send the >>>>>>>>> reader >>>>>>>>> to the other bug entry :) Jc >>>>>>>>> >>>>>>>>> From: Yasumasa Suenaga >>>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>>> tests on submit repo have been passed >>>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>>> >>>>>>>>>> Could you review the CSR? >>>>>>>>>> >>>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>>> I will sponsor you. >>>>>>>>>>> >>>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>>> >>>>>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>> >>>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>>> to match other tools. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>>> >>>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>>> --pid `. >>>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>>> >>>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>>> >>>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Osamu >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jc >> From chris.plummer at oracle.com Thu May 16 01:49:18 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 May 2019 18:49:18 -0700 Subject: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 In-Reply-To: References: Message-ID: <9bd1e3aa-fc0d-a1cf-ff50-c5fc134c6d12@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu May 16 01:55:47 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 May 2019 18:55:47 -0700 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> <5D669D64-3296-4F34-BDA0-17E467F2F94A@oracle.com> <8386d219-7680-63e7-cd0b-4e671938cac6@oracle.com> Message-ID: <9b2376a7-fd8e-f998-955f-317f94815a65@oracle.com> LGTM Chris On 5/15/19 12:15 PM, Daniil Titov wrote: > Hi David, Chris, and JC, > > Please review a new version of the change that also fixes the similar problems in ClassTypeImpl.subclasses(), InterfaceTypeImpl.subinterfaces(), and InterfaceTypeImpl.implementors() methods. The fix moves the common code that iterates over all loaded types while ignoring ObjectCollectedException in a new method VirtualMachineImpl.forEachClass(Consumer). > > Method ReferenceTypeImpl.nestedTypes() doesn't have this problem (since the only method it calls on a reference type is name() that cannot throw ObjectCollectedException()). However, to avoid potential pitfalls in the future if someone decides to change this code, I modified this method to use the same pattern as in the cases listed above. > > All vmTestbase/nsk/jdi tests as well as tier1, tier2, and tier3 tests succeeded. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > Thanks, > Daniil > > ?On 5/13/19, 2:59 PM, "David Holmes" wrote: > > Hi Daniil, > > On 14/05/2019 5:56 am, Daniil Titov wrote: > > Hi David, > > > > It seems as the chances that class unloading happens during the life-time of these tests are extremely low and switching Graal on increases these chances. At least without Graal I could not locate any test result that showed that ClassUnload event was posted. With Graal on 1 of 500 tests fails (at least on Windows platform, on other platforms it must be more rare if not zero) and I could not find any successful test showing that ClassUnload event was ever posted for any class. > > Interesting that only Graal exposes this ... though it may be that the > reflection accessor actually relates to Graal code, hence the reason the > unloading only shows up with Graal. It may mean there is a hole in our > test coverage with JDI - may need some tests that involve executing > reflection code with accessors eagerly generated so that we do see > class-unload events. Though timing would be problematic. > > > You are right, the similar problem exists for ClassTypeImpl. subclasses() method and there is a separate issue for that: JDK-8223492. And while I was not able to reproduce it so far the logs provided in JDK-8223492 show that the problem here is the same. Initially I planned to keep these issues separated and proceed with JDK-8223492 after the current review is completed. But if you think it makes sense I could update the current webrev to include changes for ClassTypeImpl. subclasses() and then close JDK-8223492 as a duplicate. > > Entirely up to you. But I would be suspicious of all of the code that > iterates vm.allClasses(). > > > I am also curious whether lambda forms, e.g. org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388, are supposed to be visible in JDI but I could not locate any discussion about this. > > I'm trying to find that out too - but we can deal with that as a > separate issue. > > Thanks, > David > > > Thanks! > > --Daniil > > > > > > Per tests data and additional tracing it seems as with Graal on the chances that class unloading happens during the test run are about 1/200 and only on Windows platform. Without Graal there were no single occurrence of the test when any ClassUnload event was posted. > > > > ?On 5/12/19, 3:19 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > On 12/05/2019 3:14 am, Daniil Titov wrote: > > > Hi David, > > > > > > There are two ways how these reference types (for the classes that become unloaded later) could appear in the collection com.sun.tools.jdi.VirtualMachineImpl maintains and stores in VirtualMachineImpl.typesBySignature instance variable: > > > 1) Initial load when all classes are requested from the debuggee > > > 2) Or added later when ClassPrepare event for a specific class is posted and handled > > > > > > The reference types are removed from VirtualMachineImpl.typesBySignature when ClassUnload event is processed. However, additional tracing showed ( pleases see below the sample output) that in some cases these ClassUnload events are received after we entered definedClasses() method and started iterating over the copy of the collection of the classes returned by vm.allClasses() method. > > > > Thanks for clarifying that for me. I was thinking in this case that > > definedClasses() was directly querying the target VM, but it isn't it's > > iterating the existing set of known classes cached in the client > > (vm.allClasses()). > > > > Though it seems that whether or not we will hit this > > ObjectCollectedException depends on what we have already done with a > > particular ReferenceType. In this case we hit the exception when > > invoking classLoader() but that will only throw the exception if we do > > not already have the classLoader cached and have to go and seek it from > > the target VM. > > > > I do wonder why this issue should suddenly appear now? Encountering an > > unloaded class, like a generated reflection accessor, should always have > > been possible and so we should have seen this before. Something must > > have changed recently. ?? > > > > I'm also concerned about other code that iterates through > > vm.allClasses() and which does not seem to be aware of the possibility > > of CollectedObjectException. For example in ClassTypeImpl.java we have: > > > > public List subclasses() { > > List subs = new ArrayList<>(); > > for (ReferenceType refType : vm.allClasses()) { > > if (refType instanceof ClassType) { > > ClassType clazz = (ClassType)refType; > > ClassType superclass = clazz.superclass(); > > if ((superclass != null) && superclass.equals(this)) { > > subs.add((ClassType)refType); > > } > > } > > } > > > > return subs; > > } > > > > If the superclass is already cached then this will work, but if it has > > to call to the target VM over JDWP then we will have the same bug I > > think. Which again raises the question for me as to why we are not > > seeing tests fail here? > > > > > Based on the output below it seems as all unloaded classes are the generated ones or lambda forms. > > > > > > --> debugger: ......getting: List definedClasses = clRef.definedClasses(); > > > > > > Received Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > > Handled Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > > > This is fine - generated reflection accessor are loaded in a custom > > classloader specifically so they can be unloaded promptly. But ... > > > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > > > ... these are I believe definitions of VM anonymous classes (they have > > names of the form foo/ which are not legal class names). Should > > these even be visible to JDI? > > > > Thanks, > > David > > ----- > > > > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > > > > Exception while getting classloader for type jdk.internal.reflect.GeneratedConstructorAccessor1 > > > # ERROR: ##> debugger: ERROR: Exception : com.sun.jdi.ObjectCollectedException > > > > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > ?On 5/11/19, 3:39 AM, "David Holmes" wrote: > > > > > > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > > > > Isn't that the point? The list returned could have unloaded classes and > > > > we can catch it via this exception (from the comment above > > > > the ReferenceType interface): > > > > > > > > * Any method on ReferenceType or which directly or > > > > indirectly takes > > > > * ReferenceType as parameter may throw > > > > * {@link ObjectCollectedException} if the mirrored type has been unloaded. > > > > > > > > Turns out that even in the definedClasses, we can get that exception so > > > > we should check for it while walking the reference types as well? > > > > > > I understand that the list returned to the "debugger" process may > > > contain ReferenceTypes for types that have actually been unloaded by the > > > time it queries them (unless the debuggee is suspended of course). But I > > > don't see how we can encounter those types while compiling the list in > > > the debuggee in the first place. > > > > > > Something seems amiss here ... possibly just my understanding ... > > > > > > David > > > > > > > Jc > > > > > > > > *From: *Chris Plummer > > > > > > > > *Date: *Fri, May 10, 2019 at 9:09 PM > > > > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > > > > > > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > > > > On 5/10/19 8:59 PM, David Holmes wrote: > > > > >> Hi Daniil, > > > > >> > > > > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > > > > >>> Please review the change that fixes an intermittent failure of the > > > > >>> test. > > > > >>> > > > > >>> The tests checks the implementation of the > > > > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > > > > >>> that while > > > > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > > > > iterates > > > > >>> over all loaded classes to retrieve a classloader and compares > > > > it to > > > > >>> the current one, some of the classes might become unloaded and > > > > >>> garbage collected (e.g. > > > > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > > > > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > > > > >>> happens then the attempt to retrieve a classloader for the > > > > collected > > > > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > > > > >> > > > > >> That seems odd to me. If you have a reference to the Class then it > > > > >> can't be unloaded. I would not expect allClasses() to have > > > > >> weak-references, so a class should not be unloadable while you are > > > > >> examining it. Unless it is finding VM anonymous classes (which it > > > > >> should not!). > > > > >> > > > > > I was just typing up something similar. Shouldn't the test do a > > > > > vm.suspend() and then call disableCollection() on each class > > > > returned > > > > > by vm.allClasses()? > > > > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > > > > the user of ClassLoaderReference.definedClasses() to do the suspend. In > > > > fact I'm not sure there's much purpose in calling > > > > ClassLoaderReference.definedClasses() without suspending first. Even > > > > with your changes, the list returned can end up with references to > > > > unloaded classes. > > > > > > > > Chris > > > > > > > > > > Chris > > > > >> David > > > > >> ----- > > > > >> > > > > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > > > > >>> continues iterating over the rest of the classes. > > > > >>> > > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > > > > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > > > >>> > > > > >>> Thanks! > > > > >>> --Daniil > > > > >>> > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > > > > > > > From jcbeyler at google.com Thu May 16 02:14:08 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 15 May 2019 19:14:08 -0700 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: <9b2376a7-fd8e-f998-955f-317f94815a65@oracle.com> References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> <5D669D64-3296-4F34-BDA0-17E467F2F94A@oracle.com> <8386d219-7680-63e7-cd0b-4e671938cac6@oracle.com> <9b2376a7-fd8e-f998-955f-317f94815a65@oracle.com> Message-ID: LGTM too :) *From: *Chris Plummer *Date: *Wed, May 15, 2019 at 6:55 PM *To: *Daniil Titov, David Holmes, Jean Christophe Beyler *Cc: *OpenJDK Serviceability LGTM > > Chris > > On 5/15/19 12:15 PM, Daniil Titov wrote: > > Hi David, Chris, and JC, > > > > Please review a new version of the change that also fixes the similar > problems in ClassTypeImpl.subclasses(), InterfaceTypeImpl.subinterfaces(), > and InterfaceTypeImpl.implementors() methods. The fix moves the common code > that iterates over all loaded types while ignoring ObjectCollectedException > in a new method VirtualMachineImpl.forEachClass(Consumer). > > > > Method ReferenceTypeImpl.nestedTypes() doesn't have this problem (since > the only method it calls on a reference type is name() that cannot throw > ObjectCollectedException()). However, to avoid potential pitfalls in the > future if someone decides to change this code, I modified this method to > use the same pattern as in the cases listed above. > > > > All vmTestbase/nsk/jdi tests as well as tier1, tier2, and tier3 tests > succeeded. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.02 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > > > Thanks, > > Daniil > > > > ?On 5/13/19, 2:59 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > On 14/05/2019 5:56 am, Daniil Titov wrote: > > > Hi David, > > > > > > It seems as the chances that class unloading happens during the > life-time of these tests are extremely low and switching Graal on increases > these chances. At least without Graal I could not locate any test result > that showed that ClassUnload event was posted. With Graal on 1 of 500 > tests fails (at least on Windows platform, on other platforms it must be > more rare if not zero) and I could not find any successful test showing > that ClassUnload event was ever posted for any class. > > > > Interesting that only Graal exposes this ... though it may be that > the > > reflection accessor actually relates to Graal code, hence the > reason the > > unloading only shows up with Graal. It may mean there is a hole in > our > > test coverage with JDI - may need some tests that involve executing > > reflection code with accessors eagerly generated so that we do see > > class-unload events. Though timing would be problematic. > > > > > You are right, the similar problem exists for ClassTypeImpl. > subclasses() method and there is a separate issue for that: JDK-8223492. > And while I was not able to reproduce it so far the logs provided in > JDK-8223492 show that the problem here is the same. Initially I planned to > keep these issues separated and proceed with JDK-8223492 after the current > review is completed. But if you think it makes sense I could update the > current webrev to include changes for ClassTypeImpl. subclasses() and then > close JDK-8223492 as a duplicate. > > > > Entirely up to you. But I would be suspicious of all of the code > that > > iterates vm.allClasses(). > > > > > I am also curious whether lambda forms, e.g. > org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388, > are supposed to be visible in JDI but I could not locate any discussion > about this. > > > > I'm trying to find that out too - but we can deal with that as a > > separate issue. > > > > Thanks, > > David > > > > > Thanks! > > > --Daniil > > > > > > > > > Per tests data and additional tracing it seems as with Graal on > the chances that class unloading happens during the test run are about > 1/200 and only on Windows platform. Without Graal there were no single > occurrence of the test when any ClassUnload event was posted. > > > > > > ?On 5/12/19, 3:19 PM, "David Holmes" > wrote: > > > > > > Hi Daniil, > > > > > > On 12/05/2019 3:14 am, Daniil Titov wrote: > > > > Hi David, > > > > > > > > There are two ways how these reference types (for the > classes that become unloaded later) could appear in the collection > com.sun.tools.jdi.VirtualMachineImpl maintains and stores in > VirtualMachineImpl.typesBySignature instance variable: > > > > 1) Initial load when all classes are requested from the > debuggee > > > > 2) Or added later when ClassPrepare event for a specific > class is posted and handled > > > > > > > > The reference types are removed from > VirtualMachineImpl.typesBySignature when ClassUnload event is processed. > However, additional tracing showed ( pleases see below the sample output) > that in some cases these ClassUnload events are received after we entered > definedClasses() method and started iterating over the copy of the > collection of the classes returned by vm.allClasses() method. > > > > > > Thanks for clarifying that for me. I was thinking in this > case that > > > definedClasses() was directly querying the target VM, but it > isn't it's > > > iterating the existing set of known classes cached in the > client > > > (vm.allClasses()). > > > > > > Though it seems that whether or not we will hit this > > > ObjectCollectedException depends on what we have already > done with a > > > particular ReferenceType. In this case we hit the exception > when > > > invoking classLoader() but that will only throw the > exception if we do > > > not already have the classLoader cached and have to go and > seek it from > > > the target VM. > > > > > > I do wonder why this issue should suddenly appear now? > Encountering an > > > unloaded class, like a generated reflection accessor, should > always have > > > been possible and so we should have seen this before. > Something must > > > have changed recently. ?? > > > > > > I'm also concerned about other code that iterates through > > > vm.allClasses() and which does not seem to be aware of the > possibility > > > of CollectedObjectException. For example in > ClassTypeImpl.java we have: > > > > > > public List subclasses() { > > > List subs = new ArrayList<>(); > > > for (ReferenceType refType : vm.allClasses()) { > > > if (refType instanceof ClassType) { > > > ClassType clazz = (ClassType)refType; > > > ClassType superclass = clazz.superclass(); > > > if ((superclass != null) && > superclass.equals(this)) { > > > subs.add((ClassType)refType); > > > } > > > } > > > } > > > > > > return subs; > > > } > > > > > > If the superclass is already cached then this will work, but > if it has > > > to call to the target VM over JDWP then we will have the > same bug I > > > think. Which again raises the question for me as to why we > are not > > > seeing tests fail here? > > > > > > > Based on the output below it seems as all unloaded classes > are the generated ones or lambda forms. > > > > > > > > --> debugger: ......getting: List definedClasses = > clRef.definedClasses(); > > > > > > > > Received Unload Event for > Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > > > Handled Unload Event for > Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > > > > > This is fine - generated reflection accessor are loaded in a > custom > > > classloader specifically so they can be unloaded promptly. > But ... > > > > > > > Received Unload Event for > Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > > > Handled Unload Event for > Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > > > > > ... these are I believe definitions of VM anonymous classes > (they have > > > names of the form foo/ which are not legal class > names). Should > > > these even be visible to JDI? > > > > > > Thanks, > > > David > > > ----- > > > > > > > Received Unload Event for > Ljava/lang/invoke/LambdaForm$DMH/733189374; > > > > Handled Unload Event for > Ljava/lang/invoke/LambdaForm$DMH/733189374; > > > > Received Unload Event for > Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > > > Handled Unload Event for > Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > > > Received Unload Event for > Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > > > Handled Unload Event for > Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > > > Received Unload Event for > Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > > Handled Unload Event for > Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > > > > > > Exception while getting classloader for type > jdk.internal.reflect.GeneratedConstructorAccessor1 > > > > # ERROR: ##> debugger: ERROR: Exception : > com.sun.jdi.ObjectCollectedException > > > > > > > > > > > > Thanks! > > > > --Daniil > > > > > > > > > > > > > > > > ?On 5/11/19, 3:39 AM, "David Holmes" < > david.holmes at oracle.com> wrote: > > > > > > > > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > > > > > Isn't that the point? The list returned could have > unloaded classes and > > > > > we can catch it via this exception (from the > comment above > > > > > the ReferenceType interface): > > > > > > > > > > * Any method on ReferenceType or > which directly or > > > > > indirectly takes > > > > > * ReferenceType as parameter may > throw > > > > > * {@link ObjectCollectedException} if the > mirrored type has been unloaded. > > > > > > > > > > Turns out that even in the definedClasses, we can > get that exception so > > > > > we should check for it while walking the reference > types as well? > > > > > > > > I understand that the list returned to the "debugger" > process may > > > > contain ReferenceTypes for types that have actually > been unloaded by the > > > > time it queries them (unless the debuggee is > suspended of course). But I > > > > don't see how we can encounter those types while > compiling the list in > > > > the debuggee in the first place. > > > > > > > > Something seems amiss here ... possibly just my > understanding ... > > > > > > > > David > > > > > > > > > Jc > > > > > > > > > > *From: *Chris Plummer > > > > > > > > > > *Date: *Fri, May 10, 2019 at 9:09 PM > > > > > *To: *David Holmes, Daniil Titov, OpenJDK > Serviceability > > > > > > > > > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > > > > > On 5/10/19 8:59 PM, David Holmes wrote: > > > > > >> Hi Daniil, > > > > > >> > > > > > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > > > > > >>> Please review the change that fixes an > intermittent failure of the > > > > > >>> test. > > > > > >>> > > > > > >>> The tests checks the implementation of the > > > > > >>> com.sun.tools.jdi.ClassLoaderReference > class. The problem here is > > > > > >>> that while > > > > > >>> > com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > > > > > iterates > > > > > >>> over all loaded classes to retrieve a > classloader and compares > > > > > it to > > > > > >>> the current one, some of the classes might > become unloaded and > > > > > >>> garbage collected (e.g. > > > > > >>> > org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > > > > > >>> > jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > > > > > >>> happens then the attempt to retrieve a > classloader for the > > > > > collected > > > > > >>> class results in > com.sun.jdi.ObjectCollectedException being thrown. > > > > > >> > > > > > >> That seems odd to me. If you have a > reference to the Class then it > > > > > >> can't be unloaded. I would not expect > allClasses() to have > > > > > >> weak-references, so a class should not be > unloadable while you are > > > > > >> examining it. Unless it is finding VM > anonymous classes (which it > > > > > >> should not!). > > > > > >> > > > > > > I was just typing up something similar. > Shouldn't the test do a > > > > > > vm.suspend() and then call > disableCollection() on each class > > > > > returned > > > > > > by vm.allClasses()? > > > > > Oh wait, this isn't a test. It's part of JDI. I > guess it would be up to > > > > > the user of > ClassLoaderReference.definedClasses() to do the suspend. In > > > > > fact I'm not sure there's much purpose in > calling > > > > > ClassLoaderReference.definedClasses() without > suspending first. Even > > > > > with your changes, the list returned can end up > with references to > > > > > unloaded classes. > > > > > > > > > > Chris > > > > > > > > > > > > Chris > > > > > >> David > > > > > >> ----- > > > > > >> > > > > > >>> The fix catches this > com.sun.jdi.ObjectCollectedException and > > > > > >>> continues iterating over the rest of the > classes. > > > > > >>> > > > > > >>> Webrev: > http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > > > > > >>> Bug: > https://bugs.openjdk.java.net/browse/JDK-8222422 > > > > > >>> > > > > > >>> Thanks! > > > > > >>> --Daniil > > > > > >>> > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Thanks, > > > > > Jc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 16 02:23:52 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 19:23:52 -0700 Subject: debugd options should regard to jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> Message-ID: <6f5af5e1-5ce4-7d67-3939-b3b77dd42403@oracle.com> On 5/15/19 18:20, serguei.spitsyn at oracle.com wrote: > Hi Osamu, > > > On 5/14/19 00:21, Osamu Sakamoto wrote: >> Hi Serguei, >> >> Thank you for reviewing the CSR. >> >> I answer your questions. >> >> Q1 & Q2: and can accept >> both full path and relative path. > > It has to be clear in the help. > I've updated the CSR with this. Removed my CSR update. This is better to be handled by the RFE JDK-8223814 ad David suggested. Thanks, Serguei >> Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently >> have the same format, and need not to be updated. > > Thank you for the confirmation. > >> By the way, you've added angle brackets to jhsdb debugd --help in the >> CSR. >> But current other commands --help don't have it. >> I think this modification should be also added to other commands >> --help if it is added to debugd --help. >> This CSR relates on only debugd, so I think this modification should >> be included to the RFE which David filed.(JDK-8223814) >> What do you think about this? > > I've added a comment about this to the RFE JDK-8223814. > >> >> Yasumasa has uploaded webrev.00.1 that angle bracket is added to >> debugd --help. >> I will request him to push the better one when this is clear >> > > Okay, thanks! > I'll review it now. > > Thanks, > Serguei > >> >> Thanks, >> Osamu >> >> >> On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: >>> Hi Osamu, >>> >>> Sorry for reacting on this so late. >>> This work on cmd-line options unification is very welcome! >>> >>> I looked at the CSR and it looks pretty good in general. >>> >>> I've added angle brackets to the jhsdb debugd --help: >>> >>> |$ jhsdb debugd --help --serverid >>> --exe --core --pid >> of process to attach> But this needs to be unified with other >>> commands |||(clhsdb, hsdb, jstack, etc|), of course. | >>> >>> Also, added a comment with the questions: >>> >>> |Q1: Should the be always a full path name >>> or it can be a relative path? Q2: Should the be >>> always a full path name or it can be a relative path? Q3: Do all >>> other commans (clhsdb, hsdb, jstack, jmap, etc.) currently have the >>> same format or they also need to be updated?| >>> >>> >>> I can update the CSR description if you answer these questions. >>> They'll file an RFE for this. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 5/13/19 01:06, Osamu Sakamoto wrote: >>>> Hi David, >>>> >>>> Thank you for updating the CSR. >>>> I agree with filing a RFE to improve the general jhsdb help output. >>>> >>>> Could you file the RFE? (I can't access JBS.) >>>> I would like to contribute it if the RFE will be filed. >>>> >>>> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >>>> So I will request Yasumasa to push it to jdk/jdk when the status of >>>> CSR changes to Approved, and RFE for jhsdb help is filed. >>>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/13/19 16:00, David Holmes wrote: >>>>> >>>>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>>>> Hi, David >>>>>> >>>>>> I saw your comment in this CSR. >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>> >>>>>> I understand that the problem is that the help description of >>>>>> debugd I proposed and current other modes is not helpful for users. >>>>>> >>>>>> What should we do to go through this CSR? >>>>>> IMHO we should update help description of all jhsdb modes more >>>>>> helpful. >>>>>> Do you have any ideas about this? >>>>> >>>>> I think a RFE should be filed to improve the general jhsdb help >>>>> output, so that it explains that --pid and --exe are mutually >>>>> exclusive options. That way this CSR, and thus the associated RFE >>>>> can proceed. I'll add the same info the CSR. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Osamu >>>>>> >>>>>> >>>>>> On 5/10/19 17:46, ?? ? wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I agree with Yasumasa's opinion in CSR. >>>>>>> >>>>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>>>> jmap and so on) in jhdsb. >>>>>>> Certainly, usage of debugd which I proposed does not explain >>>>>>> that and cannot be used together, but it is not >>>>>>> limited to debugd - other modes have similar issue. >>>>>>> >>>>>>> I think it is helpful to detail help description in each jhsdb >>>>>>> modes, but I'd like to separate as another issue because this is >>>>>>> not limited to debugd. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Yasumasa Suenaga >>>>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>>>> To: David Holmes >>>>>>> Cc: Jean Christophe Beyler ; >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> ; ?? ? >>>>>>> >>>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for checking in CSR, and sorry for my incorrect >>>>>>> description. >>>>>>> I added my opinion to CSR. >>>>>>> >>>>>>> Osamu, do you have any opinion? >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>>>> >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> I've made some updates to the CSR request and raised a couple >>>>>>>> of issues. >>>>>>>> >>>>>>>> FYI the specification section only needs to contain the actual >>>>>>>> specification for what has changed ie the new command-line >>>>>>>> options; >>>>>>>> not the implementation that will bring about those changes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>>>> Thanks JC! >>>>>>>>> >>>>>>>>> I added key point of this change to specification section in CSR. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>>>> : >>>>>>>>>> >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>>>> specification section could use some text and then send the >>>>>>>>>> reader >>>>>>>>>> to the other bug entry :) Jc >>>>>>>>>> >>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>>> tests on submit repo have been passed >>>>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>>>> >>>>>>>>>>> Could you review the CSR? >>>>>>>>>>> >>>>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>>>> I will sponsor you. >>>>>>>>>>>> >>>>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>>>> >>>>>>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>> >>>>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>>>>>> suspect that historically the form of this command was >>>>>>>>>>>>> done to match other tools. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>>>> --pid `. >>>>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Osamu >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jc >>> > From serguei.spitsyn at oracle.com Thu May 16 02:30:28 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 19:30:28 -0700 Subject: debugd options should regard to jhsdb style In-Reply-To: <04649AF8E13EB949B7D27EFDD2A37DFEE2B2725C@WMBOX4.soad.nttcom.co.jp> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> <04649AF8E13EB949B7D27EFDD2A37DFEE2B2725C@WMBOX4.soad.nttcom.co.jp> Message-ID: Hi Osamu, I'm Okay with the fix. But we have to use correct subject line which includes bug number and the exact bug title. Otherwise, these emails are not searchable by the bug number. Thanks, Serguei On 5/15/19 17:57, ?? ? wrote: > Hi Serguei, > > Do you think which is better, to add angle bracket or not to? >> By the way, you've added angle brackets to jhsdb debugd --help in the CSR. >> But current other commands --help don't have it. >> I think this modification should be also added to other commands --help if it is added to debugd --help. >> This CSR relates on only debugd, so I think this modification should be included to the RFE which David filed.(JDK-8223814) > The webrev which is added angle bracket to debugd --help is here. > > > Thanks, > Osamu > > -- > NTT ????????? > ???????SE??OSS??? > ???? > TEL: 03-6713-3034 > MAIL: > > -----Original Message----- > From: Osamu Sakamoto > Sent: Tuesday, May 14, 2019 4:22 PM > To: serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net > Cc: ?? ?? > Subject: Re: debugd options should regard to jhsdb style > > Hi Serguei, > > Thank you for reviewing the CSR. > > I answer your questions. > > Q1 & Q2: and can accept both full path and relative path. > Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently have the same format, and need not to be updated. > > > By the way, you've added angle brackets to jhsdb debugd --help in the CSR. > But current other commands --help don't have it. > I think this modification should be also added to other commands --help if it is added to debugd --help. > This CSR relates on only debugd, so I think this modification should be included to the RFE which David filed.(JDK-8223814) What do you think about this? > > Yasumasa has uploaded webrev.00.1 that angle bracket is added to debugd --help. > I will request him to push the better one when this is clear > > > Thanks, > Osamu > > > On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: >> Hi Osamu, >> >> Sorry for reacting on this so late. >> This work on cmd-line options unification is very welcome! >> >> I looked at the CSR and it looks pretty good in general. >> >> I've added angle brackets to the jhsdb debugd --help: >> >> |$ jhsdb debugd --help --serverid >> --exe --core --pid > process to attach> But this needs to be unified with other commands |||(clhsdb, hsdb, jstack, etc|), of course. | >> >> Also, added a comment with the questions: >> >> |Q1: Should the be always a full path name or it >> can be a relative path? Q2: Should the be always a >> full path name or it can be a relative path? Q3: Do all other commans >> (clhsdb, hsdb, jstack, jmap, etc.) currently have the same format or >> they also need to be updated?| >> >> >> I can update the CSR description if you answer these questions. >> They'll file an RFE for this. >> >> Thanks, >> Serguei >> >> >> >> On 5/13/19 01:06, Osamu Sakamoto wrote: >>> Hi David, >>> >>> Thank you for updating the CSR. >>> I agree with filing a RFE to improve the general jhsdb help output. >>> >>> Could you file the RFE? (I can't access JBS.) >>> I would like to contribute it if the RFE will be filed. >>> >>> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >>> So I will request Yasumasa to push it to jdk/jdk when the status of >>> CSR changes to Approved, and RFE for jhsdb help is filed. >>> >>> Thanks, >>> Osamu >>> >>> >>> On 5/13/19 16:00, David Holmes wrote: >>>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>>> Hi, David >>>>> >>>>> I saw your comment in this CSR. >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>> >>>>> I understand that the problem is that the help description of debugd >>>>> I proposed and current other modes is not helpful for users. >>>>> >>>>> What should we do to go through this CSR? >>>>> IMHO we should update help description of all jhsdb modes more helpful. >>>>> Do you have any ideas about this? >>>> I think a RFE should be filed to improve the general jhsdb help >>>> output, so that it explains that --pid and --exe are mutually >>>> exclusive options. That way this CSR, and thus the associated RFE can >>>> proceed. I'll add the same info the CSR. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Osamu >>>>> >>>>> >>>>> On 5/10/19 17:46, ?? ? wrote: >>>>>> Hi, >>>>>> >>>>>> I agree with Yasumasa's opinion in CSR. >>>>>> >>>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>>> jmap and so on) in jhdsb. >>>>>> Certainly, usage of debugd which I proposed does not explain that >>>>>> and cannot be used together, but it is not limited to >>>>>> debugd - other modes have similar issue. >>>>>> >>>>>> I think it is helpful to detail help description in each jhsdb >>>>>> modes, but I'd like to separate as another issue because this is >>>>>> not limited to debugd. >>>>>> >>>>>> -----Original Message----- >>>>>> From: Yasumasa Suenaga >>>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>>> To: David Holmes >>>>>> Cc: Jean Christophe Beyler ; >>>>>> serviceability-dev at openjdk.java.net >>>>>> serviceability-dev at openjdk.java.net >>>>>> ; ?? ? >>>>>> >>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>> >>>>>> Hi David, >>>>>> >>>>>> Thank you for checking in CSR, and sorry for my incorrect description. >>>>>> I added my opinion to CSR. >>>>>> >>>>>> Osamu, do you have any opinion? >>>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> I've made some updates to the CSR request and raised a couple of >>>>>>> issues. >>>>>>> >>>>>>> FYI the specification section only needs to contain the actual >>>>>>> specification for what has changed ie the new command-line options; >>>>>>> not the implementation that will bring about those changes. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>>> Thanks JC! >>>>>>>> >>>>>>>> I added key point of this change to specification section in CSR. >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>>> : >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>>> specification section could use some text and then send the reader >>>>>>>>> to the other bug entry :) Jc >>>>>>>>> >>>>>>>>> From: Yasumasa Suenaga >>>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> >>>>>>>>>> tests on submit repo have been passed >>>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>>> >>>>>>>>>> Could you review the CSR? >>>>>>>>>> >>>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>>> I will sponsor you. >>>>>>>>>>> >>>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>>> >>>>>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>>> ???? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>> >>>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>>> to match other tools. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>>> >>>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>>> --pid `. >>>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>>> >>>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>>> >>>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>>> >>>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Osamu >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jc From serguei.spitsyn at oracle.com Thu May 16 02:42:31 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 19:42:31 -0700 Subject: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 In-Reply-To: <9bd1e3aa-fc0d-a1cf-ff50-c5fc134c6d12@oracle.com> References: <9bd1e3aa-fc0d-a1cf-ff50-c5fc134c6d12@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From sakamoto.osamu at nttcom.co.jp Thu May 16 02:45:55 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Thu, 16 May 2019 11:45:55 +0900 Subject: RFR: 8223666: SA: debugd options should follow jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> <04649AF8E13EB949B7D27EFDD2A37DFEE2B2725C@WMBOX4.soad.nttcom.co.jp> Message-ID: <8313fb86-eee4-08bd-4113-3fa3eb8463bc@nttcom.co.jp> Hi Serguei, > I'm Okay with the fix. Thank you for reviewing. I will request Yasumasa to push webrev.00.1 to jdk/jdk when the status of CSR changes to Approved > But we have to use correct subject line which includes bug number and > the exact bug title. > Otherwise, these emails are not searchable by the bug number. I added bug number and exact bug title to email subject. Thanks, Osamu On 5/16/19 11:30, serguei.spitsyn at oracle.com wrote: > Hi Osamu, > > I'm Okay with the fix. > But we have to use correct subject line which includes bug number and > the exact bug title. > Otherwise, these emails are not searchable by the bug number. > > Thanks, > Serguei > > > On 5/15/19 17:57, ?? ? wrote: >> Hi Serguei, >> >> Do you think which is better, to add angle bracket or not to? >>> By the way, you've added angle brackets to jhsdb debugd --help in the >>> CSR. >>> But current other commands --help don't have it. >>> I think this modification should be also added to other commands >>> --help if it is added to debugd --help. >>> This CSR relates on only debugd, so I think this modification should >>> be included to the RFE which David filed.(JDK-8223814) >> The webrev which is added angle bracket to debugd --help is here. >> >> >> Thanks, >> Osamu >> >> -- >> NTT ????????? >> ???????SE??OSS??? >> ???? >> TEL: 03-6713-3034 >> MAIL: >> >> -----Original Message----- >> From: Osamu Sakamoto >> Sent: Tuesday, May 14, 2019 4:22 PM >> To: serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net >> Cc: ?? ?? >> Subject: Re: debugd options should regard to jhsdb style >> >> Hi Serguei, >> >> Thank you for reviewing the CSR. >> >> I answer your questions. >> >> Q1 & Q2: and can accept >> both full path and relative path. >> Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently >> have the same format, and need not to be updated. >> >> >> By the way, you've added angle brackets to jhsdb debugd --help in the >> CSR. >> But current other commands --help don't have it. >> I think this modification should be also added to other commands >> --help if it is added to debugd --help. >> This CSR relates on only debugd, so I think this modification should >> be included to the RFE which David filed.(JDK-8223814) What do you >> think about this? >> >> Yasumasa has uploaded webrev.00.1 that angle bracket is added to >> debugd --help. >> I will request him to push the better one when this is clear >> >> >> >> Thanks, >> Osamu >> >> >> On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: >>> Hi Osamu, >>> >>> Sorry for reacting on this so late. >>> This work on cmd-line options unification is very welcome! >>> >>> I looked at the CSR and it looks pretty good in general. >>> >>> I've added angle brackets to the jhsdb debugd --help: >>> >>> |$ jhsdb debugd --help --serverid >>> --exe --core --pid >> process to attach> But this needs to be unified with other commands >>> |||(clhsdb, hsdb, jstack, etc|), of course. | >>> >>> Also, added a comment with the questions: >>> >>> |Q1: Should the be always a full path name or it >>> can be a relative path? Q2: Should the be always a >>> full path name or it can be a relative path? Q3: Do all other commans >>> (clhsdb, hsdb, jstack, jmap, etc.) currently have the same format or >>> they also need to be updated?| >>> >>> >>> I can update the CSR description if you answer these questions. >>> They'll file an RFE for this. >>> >>> Thanks, >>> Serguei >>> >>> >>> >>> On 5/13/19 01:06, Osamu Sakamoto wrote: >>>> Hi David, >>>> >>>> Thank you for updating the CSR. >>>> I agree with filing a RFE to improve the general jhsdb help output. >>>> >>>> Could you file the RFE? (I can't access JBS.) >>>> I would like to contribute it if the RFE will be filed. >>>> >>>> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >>>> So I will request Yasumasa to push it to jdk/jdk when the status of >>>> CSR changes to Approved, and RFE for jhsdb help is filed. >>>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/13/19 16:00, David Holmes wrote: >>>>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>>>> Hi, David >>>>>> >>>>>> I saw your comment in this CSR. >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>> >>>>>> I understand that the problem is that the help description of debugd >>>>>> I proposed and current other modes is not helpful for users. >>>>>> >>>>>> What should we do to go through this CSR? >>>>>> IMHO we should update help description of all jhsdb modes more >>>>>> helpful. >>>>>> Do you have any ideas about this? >>>>> I think a RFE should be filed to improve the general jhsdb help >>>>> output, so that it explains that --pid and --exe are mutually >>>>> exclusive options. That way this CSR, and thus the associated RFE can >>>>> proceed. I'll add the same info the CSR. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Osamu >>>>>> >>>>>> >>>>>> On 5/10/19 17:46, ?? ? wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I agree with Yasumasa's opinion in CSR. >>>>>>> >>>>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>>>> jmap and so on) in jhdsb. >>>>>>> Certainly, usage of debugd which I proposed does not explain that >>>>>>> and cannot be used together, but it is not limited to >>>>>>> debugd - other modes have similar issue. >>>>>>> >>>>>>> I think it is helpful to detail help description in each jhsdb >>>>>>> modes, but I'd like to separate as another issue because this is >>>>>>> not limited to debugd. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Yasumasa Suenaga >>>>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>>>> To: David Holmes >>>>>>> Cc: Jean Christophe Beyler ; >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> serviceability-dev at openjdk.java.net >>>>>>> ; ?? ? >>>>>>> >>>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>>> >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for checking in CSR, and sorry for my incorrect >>>>>>> description. >>>>>>> I added my opinion to CSR. >>>>>>> >>>>>>> Osamu, do you have any opinion? >>>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> I've made some updates to the CSR request and raised a couple of >>>>>>>> issues. >>>>>>>> >>>>>>>> FYI the specification section only needs to contain the actual >>>>>>>> specification for what has changed ie the new command-line options; >>>>>>>> not the implementation that will bring about those changes. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>>>> Thanks JC! >>>>>>>>> >>>>>>>>> I added key point of this change to specification section in CSR. >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>>>> : >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>>>> specification section could use some text and then send the >>>>>>>>>> reader >>>>>>>>>> to the other bug entry :) Jc >>>>>>>>>> >>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>> >>>>>>>>>>> tests on submit repo have been passed >>>>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>>>> >>>>>>>>>>> Could you review the CSR? >>>>>>>>>>> >>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>>>> I will sponsor you. >>>>>>>>>>>> >>>>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>>>> >>>>>>>>>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>> >>>>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> This will need a bug filed and a corresponding CSR request. I >>>>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>>>> to match other tools. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>>>> --pid `. >>>>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Osamu >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jc > From serguei.spitsyn at oracle.com Thu May 16 02:50:54 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 19:50:54 -0700 Subject: RFR: 8223666: SA: debugd options should follow jhsdb style In-Reply-To: <8313fb86-eee4-08bd-4113-3fa3eb8463bc@nttcom.co.jp> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <92a9d7c2-f005-db6b-717b-f7c3a6db6cd4@oracle.com> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> <04649AF8E13EB949B7D27EFDD2A37DFEE2B2725C@WMBOX4.soad.nttcom.co.jp> <8313fb86-eee4-08bd-4113-3fa3eb8463bc@nttcom.co.jp> Message-ID: <2e81112d-499c-0107-41e8-0c503ae04c9d@oracle.com> Hi Osamu, On 5/15/19 19:45, Osamu Sakamoto wrote: > Hi Serguei, > > > I'm Okay with the fix. > Thank you for reviewing. > I will request Yasumasa to push webrev.00.1 to jdk/jdk when the status > of CSR changes to Approved Great! > > But we have to use correct subject line which includes bug number and > > the exact bug title. > > Otherwise, these emails are not searchable by the bug number. > I added bug number and exact bug title to email subject. Nice. Thanks, Serguei > > Thanks, > Osamu > > > On 5/16/19 11:30, serguei.spitsyn at oracle.com wrote: >> Hi Osamu, >> >> I'm Okay with the fix. >> But we have to use correct subject line which includes bug number and >> the exact bug title. >> Otherwise, these emails are not searchable by the bug number. >> >> Thanks, >> Serguei >> >> >> On 5/15/19 17:57, ?? ? wrote: >>> Hi Serguei, >>> >>> Do you think which is better, to add angle bracket or not to? >>>> By the way, you've added angle brackets to jhsdb debugd --help in >>>> the CSR. >>>> But current other commands --help don't have it. >>>> I think this modification should be also added to other commands >>>> --help if it is added to debugd --help. >>>> This CSR relates on only debugd, so I think this modification >>>> should be included to the RFE which David filed.(JDK-8223814) >>> The webrev which is added angle bracket to debugd --help is here. >>> >>> >>> Thanks, >>> Osamu >>> >>> -- >>> NTT ????????? >>> ???????SE??OSS??? >>> ???? >>> TEL: 03-6713-3034 >>> MAIL: >>> >>> -----Original Message----- >>> From: Osamu Sakamoto >>> Sent: Tuesday, May 14, 2019 4:22 PM >>> To: serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net >>> Cc: ?? ?? >>> Subject: Re: debugd options should regard to jhsdb style >>> >>> Hi Serguei, >>> >>> Thank you for reviewing the CSR. >>> >>> I answer your questions. >>> >>> Q1 & Q2: and can accept >>> both full path and relative path. >>> Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently >>> have the same format, and need not to be updated. >>> >>> >>> By the way, you've added angle brackets to jhsdb debugd --help in >>> the CSR. >>> But current other commands --help don't have it. >>> I think this modification should be also added to other commands >>> --help if it is added to debugd --help. >>> This CSR relates on only debugd, so I think this modification should >>> be included to the RFE which David filed.(JDK-8223814) What do you >>> think about this? >>> >>> Yasumasa has uploaded webrev.00.1 that angle bracket is added to >>> debugd --help. >>> I will request him to push the better one when this is clear >>> >>> >>> >>> Thanks, >>> Osamu >>> >>> >>> On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: >>>> Hi Osamu, >>>> >>>> Sorry for reacting on this so late. >>>> This work on cmd-line options unification is very welcome! >>>> >>>> I looked at the CSR and it looks pretty good in general. >>>> >>>> I've added angle brackets to the jhsdb debugd --help: >>>> >>>> |$ jhsdb debugd --help --serverid >>>> --exe --core --pid >>> process to attach> But this needs to be unified with other commands >>>> |||(clhsdb, hsdb, jstack, etc|), of course. | >>>> >>>> Also, added a comment with the questions: >>>> >>>> |Q1: Should the be always a full path name >>>> or it >>>> can be a relative path? Q2: Should the be always a >>>> full path name or it can be a relative path? Q3: Do all other commans >>>> (clhsdb, hsdb, jstack, jmap, etc.) currently have the same format or >>>> they also need to be updated?| >>>> >>>> >>>> I can update the CSR description if you answer these questions. >>>> They'll file an RFE for this. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> >>>> On 5/13/19 01:06, Osamu Sakamoto wrote: >>>>> Hi David, >>>>> >>>>> Thank you for updating the CSR. >>>>> I agree with filing a RFE to improve the general jhsdb help output. >>>>> >>>>> Could you file the RFE? (I can't access JBS.) >>>>> I would like to contribute it if the RFE will be filed. >>>>> >>>>> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >>>>> So I will request Yasumasa to push it to jdk/jdk when the status of >>>>> CSR changes to Approved, and RFE for jhsdb help is filed. >>>>> >>>>> Thanks, >>>>> Osamu >>>>> >>>>> >>>>> On 5/13/19 16:00, David Holmes wrote: >>>>>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>>>>> Hi, David >>>>>>> >>>>>>> I saw your comment in this CSR. >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>> >>>>>>> I understand that the problem is that the help description of >>>>>>> debugd >>>>>>> I proposed and current other modes is not helpful for users. >>>>>>> >>>>>>> What should we do to go through this CSR? >>>>>>> IMHO we should update help description of all jhsdb modes more >>>>>>> helpful. >>>>>>> Do you have any ideas about this? >>>>>> I think a RFE should be filed to improve the general jhsdb help >>>>>> output, so that it explains that --pid and --exe are mutually >>>>>> exclusive options. That way this CSR, and thus the associated RFE >>>>>> can >>>>>> proceed. I'll add the same info the CSR. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Osamu >>>>>>> >>>>>>> >>>>>>> On 5/10/19 17:46, ?? ? wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I agree with Yasumasa's opinion in CSR. >>>>>>>> >>>>>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>>>>> jmap and so on) in jhdsb. >>>>>>>> Certainly, usage of debugd which I proposed does not explain that >>>>>>>> and cannot be used together, but it is not limited to >>>>>>>> debugd - other modes have similar issue. >>>>>>>> >>>>>>>> I think it is helpful to detail help description in each jhsdb >>>>>>>> modes, but I'd like to separate as another issue because this is >>>>>>>> not limited to debugd. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Yasumasa Suenaga >>>>>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>>>>> To: David Holmes >>>>>>>> Cc: Jean Christophe Beyler ; >>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>> ; ?? ? >>>>>>>> >>>>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>>>> >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thank you for checking in CSR, and sorry for my incorrect >>>>>>>> description. >>>>>>>> I added my opinion to CSR. >>>>>>>> >>>>>>>> Osamu, do you have any opinion? >>>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> I've made some updates to the CSR request and raised a couple of >>>>>>>>> issues. >>>>>>>>> >>>>>>>>> FYI the specification section only needs to contain the actual >>>>>>>>> specification for what has changed ie the new command-line >>>>>>>>> options; >>>>>>>>> not the implementation that will bring about those changes. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>>>>> Thanks JC! >>>>>>>>>> >>>>>>>>>> I added key point of this change to specification section in >>>>>>>>>> CSR. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>>>>> : >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>>>>> specification section could use some text and then send the >>>>>>>>>>> reader >>>>>>>>>>> to the other bug entry :) Jc >>>>>>>>>>> >>>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>>> >>>>>>>>>>>> tests on submit repo have been passed >>>>>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>>>>> >>>>>>>>>>>> Could you review the CSR? >>>>>>>>>>>> >>>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>>>>> I will sponsor you. >>>>>>>>>>>>> >>>>>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>>>>> >>>>>>>>>>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>>> >>>>>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This will need a bug filed and a corresponding CSR >>>>>>>>>>>>>> request. I >>>>>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>>>>> to match other tools. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>>>>> --pid `. >>>>>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Osamu >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jc >> From jcbeyler at google.com Thu May 16 02:57:03 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Wed, 15 May 2019 19:57:03 -0700 Subject: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 In-Reply-To: References: <9bd1e3aa-fc0d-a1cf-ff50-c5fc134c6d12@oracle.com> Message-ID: Hi both, For the linux question, I was doing that less for the AGCT code itself but more for the dlsym I was doing in the test; I was not really wanting to support the various ways of getting the function pointer in the first iteration of the test. If we wanted to add it, I would prefer to do a separate bug/webrev to add it in a second step (For example, my theory is that dlsym works on mac but I'm not sure of the support there either). I like the idea of trying to only know what architectures are supported. >From what I can tell, if I restrain my inspection to linux: For the linux ports and pd_get_top_frame_for_signal_handler: - aarch64, arm, ppc, sparc, x86 seem to have an implementation (or it calls the for_profiling_one) - zero, s390 do not On the AsyncGetCallTrace itself, it seems like the #ifndef around the call that removes ppc64/ia64 is what is blocking it for ppc at least. Which means that on linux, we should remove zero, s390, ia64, and ppc64; or as you are suggesting allow aarch64, arm, sparc, and x86. I offer thus: Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8224020 Thanks for the reviews! Jc *From: *serguei.spitsyn at oracle.com *Date: *Wed, May 15, 2019 at 7:44 PM *To: *Chris Plummer, Jean Christophe Beyler, OpenJDK Serviceability Hi Jc, > > I'm Okay with this fix in general modulo some suggestion from Chris below. > > > On 5/15/19 18:49, Chris Plummer wrote: > > Hi JC, > > Looks like s390 is also not supported. Do we know for usre if it is > implemented on other architectures, like aarch64? I wouldn't necessarily > rely on the lack of a negative comment in > JavaThread::pd_get_top_frame_for_signal_handler() to determine support. > Maybe the test should list supported platforms rather than unsupported ones. > > > I like the suggestion above. > It is better to list what is supported now. > > Also, why does the test currently require linux? > > > My guess is that Jc does not have other platforms to check it on. > Probably, it is Okay for now to keep it this way. > Then we could file an RFE, check if ASGCT tests work Okay on other OS'es > and relax this limitation. > > Thanks, > Serguei > > > Chris > > On 5/15/19 6:01 PM, Jean Christophe Beyler wrote: > > Hi all, > > Could I get a review that restricts the test to not run on PPC64/IA64 > please? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224020 > Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.00/ > > I also moved NULL -> RTLD_DEFAULT as the man page on linux does not > specify the behavior of passing NULL. > > Thanks, > Jc > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Thu May 16 03:10:09 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 15 May 2019 20:10:09 -0700 Subject: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 In-Reply-To: References: <9bd1e3aa-fc0d-a1cf-ff50-c5fc134c6d12@oracle.com> Message-ID: <32be145a-1ba8-57bd-eb43-f4d60e19d782@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 16 03:39:33 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 20:39:33 -0700 Subject: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 In-Reply-To: References: <9bd1e3aa-fc0d-a1cf-ff50-c5fc134c6d12@oracle.com> Message-ID: <7963cc71-96e1-9f17-a2a1-d06a5d9e64e5@oracle.com> An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 16 03:49:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 20:49:58 -0700 Subject: RFR (S) 8223585: vmTestbase/runtime/pcl/* get SEGV in MetadataOnStackClosure::do_metadata(Metadata*)+0x0 In-Reply-To: References: <6703941c-87cb-fa0b-59fa-400baae99148@oracle.com> <3062a50e-9da4-9272-247a-6467d70fd841@oracle.com> Message-ID: <32475696-92c5-2451-0025-f829ae04af84@oracle.com> Hi Coleen, Looks good to me. Thanks, Serguei On 5/15/19 10:04, Jean Christophe Beyler wrote: > Hi Coleen, > > Looks good to me (not an official reviewer), > Jc > > *From: *Vladimir Kozlov > *Date: *Wed, May 15, 2019 at 9:34 AM > *To: * , hotspot-dev developers, > serviceability-dev at openjdk.java.net > > Looks good. >> Thanks, >> Vladimir >> >> On 5/15/19 6:46 AM, coleen.phillimore at oracle.com wrote: >>> Summary: adjust old method table by only one thread. >>> >>> Entries were removed from the redefinition old method table by G1 by >> multiple threads at a safepoint, so didn't take the >>> CodeCache_lock. Moved the removal to nmethod->flush(). The bug is >> confidential because there's a confidential comment >>> not marked confidential but we'll open it up once that's fixed. >>> >>> Passed redefinition tests in repository with "VM_OPTIONS=-Xcomp >> -XX:TieredStopAtLevel=1", including the PCL tests that >>> in the oracle closed repo. >>> >>> Also ran hs-tier1-3. >>> >>> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8223585.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8223585 >>> >>> Thanks, >>> Coleen > From serguei.spitsyn at oracle.com Thu May 16 05:39:54 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 15 May 2019 22:39:54 -0700 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> Message-ID: <3551cf30-8741-2e63-a80e-708f31cf9ebc@oracle.com> An HTML attachment was scrubbed... URL: From robbin.ehn at oracle.com Thu May 16 06:28:56 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 16 May 2019 08:28:56 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <0d0062e5-5913-42a1-9d24-f19ac0b0da96@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> <0d0062e5-5913-42a1-9d24-f19ac0b0da96@oracle.com> Message-ID: Thanks Serguei! /Robbin On 2019-05-16 02:10, serguei.spitsyn at oracle.com wrote: > Hi Robbin, > > Looks good to me. > > Thanks, > Serguei > > > On 5/14/19 07:02, Robbin Ehn wrote: >> Hi Dan, >> >> Full: >> http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html >> Inc: >> http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html >> >> On 2019-05-08 18:02, Daniel D. Daugherty wrote: >>> General comment - Please make sure to update all copyright years before >>> ?????????????????? pushing this changeset. >> >> Fixed. >> >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java >>> ???? L46: >>> ???? L47: ??? private static AddressField????? threadsField; >>> ???? L48: ??? private static CIntegerField???? lengthField; >>> ???????? nit - please delete blank line on L46 >>> ???????? nit - please reduce the space between type and variable names >>> ?????????????? (I have no preference if you still keep them aligned) >>> >>> ???? nit - Please delete blank line on L74. >> >> Fixed. >> >> >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java >>> ???? old L203: ????? Threads threads = VM.getVM().getThreads(); >>> ???? old L204: ????? for (JavaThread cur = threads.first(); cur != null; cur >>> = cur.next()) { >>> ???? new L203: ????? VM.getVM().getThreads().doJavaThreads((cur) -> { >>> ???????? In this case, you did a lambda conversion... >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java >>> ???? old L75: ??????????? for (JavaThread cur = threads.first(); cur != null; >>> cur = cur.next(), i++) { >>> ???? new L75: ??????????? for (int k = 0; k < threads.getNumberOfThreads(); >>> k++) { >>> ???? new L76: ??????????????? JavaThread cur = threads.getJavaThreadAt(k); >>> ???????? In this case, you didn't do a lambda conversion... >>> >>> ???????? I'm trying to grok a reason for the different styles... >>> ???????? Update: Is is maybe a control flow thing? (No, I don't know much >>> ??????????? about lambdas.) As in: Loops that "break" or early return are >>> ??????????? not amenable to conversion to a lambda... (just guessing) >> >> I converted those where it was easy to see that the loop did not have an early >> termination. Lambdas removed. >> >>> >>> ???? L74: ??????????? int i = 1; >>> ???????? Not your bug, but I think that 'i' is not used. >>> >> >> Fixed. >> >>> This all looks good to me... so thumbs up! >> >> Thanks. >> >>> >>> I have some reservations about using lambdas in a debugging tool. >>> My personal philosophy about debugging tools is that they should >>> be built on the simplest/most stable technology to reduce the >>> chances of the more complicated technology failing during a debug >>> session. I hate it when my debugger crashes! >> >> I removed all lambdas! >> >> Thanks for looking at this, Robbin >> >>> >>> That said, SA is pretty much standalone so use of lambdas in this >>> debugging tool shouldn't affect the JVM or core file being debugged. >>> >>> Again, thumbs up! >>> >>> Dan >>> >>> >>>> >>>> /Robbin >>>> >>>> On 2019-05-08 11:17, Robbin Ehn wrote: >>>>> Hi David, >>>>> >>>>> I changed to normal for: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>>>> >>>>> >>>>> Full: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>>>> Inc: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>>>> >>>>> Passes t1-2 >>>>> >>>>> Thanks, Robbin >>>>> >>>>> >>>>> On 2019-05-07 09:47, David Holmes wrote: >>>>>> Hi Robbin, >>>>>> >>>>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>>>> Hi Robbin, >>>>>>>> >>>>>>>> I have a few concerns here. >>>>>>>> >>>>>>>> First I can't see how you are actually integrating the SA with the >>>>>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate but >>>>>>>> IIRC that list can be updated when threads are added/removed and I'm not >>>>>>>> seeing how the SA is left iterating a valid list - we'd normally using a >>>>>>>> ThreadsListHandle for that ?? (I may need a refresher on how this list >>>>>>>> is actually maintained.) >>>>>>> >>>>>>> The processes must be paused. If the processes would be running the >>>>>>> linked list is also broken since if we unlink and delete a JavaThread and >>>>>>> then later SA follows that _next pointer. >>>>>> >>>>>> Ah good point. Thanks for clarifying. >>>>>> >>>>>>>> >>>>>>>> The conversion from external iteration of the list (the for loop) to >>>>>>>> internal iteration (passing a lambda to JavaThreadsDo) is also >>>>>>>> problematic. First I'd be very wary about introducing lambda expressions >>>>>>>> into the SA code - lambda drags in a lot of supporting code that could >>>>>>>> have an impact on the way SA functions. There are places where we have >>>>>>>> to avoid lambdas due to bootstrapping/initialization issues and I think >>>>>>>> the SA may be an area where we also want to keep the code extremely simple. >>>>>>> >>>>>>> There are already several usages of lambdas in SA code, e.g. >>>>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an application, >>>>>>> there is not a bootstrap issue or so. >>>>>> >>>>>> Hmm okay. Lambda carries a lot of baggage. But if its already being used ... >>>>>> >>>>>>>> Second by using lambda's with internal iteration you've lost the ability >>>>>>>> to terminate the iteration loop! In the existing code if we have a >>>>>>>> return in the for-loop then we not only terminate the loop but the >>>>>>>> enclosing method. With the lambda the "return" just ends the current >>>>>>>> iteration and JavaThreadsDo will then continue with the next thread - so >>>>>>>> we don't even terminate the iteration let alone the method performing >>>>>>>> the iteration. So for places were we want to process one thread, for >>>>>>>> example, we will continue to iterate all remaining threads and just do >>>>>>>> nothing with them. That's very inefficient. >>>>>>> >>>>>>> That's why I only used the internal iteration where we didn't have early >>>>>>> returns. >>>>>> >>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>>>> - original code: >>>>>> >>>>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>>>> 1557???????????? public void doit(Tokens t) { >>>>>> ... >>>>>> 1564???????????????????? for (JavaThread thread = threads.first(); thread >>>>>> != null; thread = thread.next()) { >>>>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>>>> ByteArrayOutputStream(); >>>>>> 1566???????????????????????? thread.printThreadIDOn(new PrintStream(bos)); >>>>>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>>>>> 1568???????????????????????????? out.println("Thread " + bos.toString() + >>>>>> " Address: " + thread.getAddress()); >>>>>> ... >>>>>> 1577???????????????????????????? } >>>>>> 1578???????????????????????????? if (!all) return; >>>>>> >>>>>> That looks like an early return to me. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> Thanks, Robbin >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>>>> Hi, please review. >>>>>>>>> >>>>>>>>> Old threads linked list remove and updated SA to use ThreadsList array >>>>>>>>> instead. >>>>>>>>> >>>>>>>>> Issue: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>>>> >>>>>>>>> Passes t1-3 (which includes SA tests). >>>>>>>>> >>>>>>>>> Thanks, Robbin >>> > From robbin.ehn at oracle.com Thu May 16 06:32:08 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 16 May 2019 08:32:08 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: <31e42fd7-5459-4050-eaa8-3db8db3a1716@oracle.com> References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> <354daa4d-4c50-1f79-1f64-c45310d11dce@oracle.com> <7c79092f-5069-b4f1-da46-44d10411e0b3@oracle.com> <31e42fd7-5459-4050-eaa8-3db8db3a1716@oracle.com> Message-ID: Thanks Coleen! On 2019-05-15 17:52, coleen.phillimore at oracle.com wrote: > > Still looks good.? I guess we'll not have any lambdas to cut and paste in the SA > now. > > Do you no longer need this? > > 191 public interface JavaThreadsDo { > 192 void doJavaThread(JavaThread thread); > 193 } > 194 > 195 public void doJavaThreads(JavaThreadsDo jtDo) { > 196 for (int i = 0; i < _list.length(); i++) { > 197 jtDo.doJavaThread(getJavaThreadAt(i)); > 198 } > 199 } > 200 > > > If you remove it, or not, I don't need to see this webrev again. It was removed here if you look at inc: http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java.sdiff.html /Robbin > > Coleen > > On 5/15/19 9:20 AM, Robbin Ehn wrote: >> On 2019-05-15 14:59, David Holmes wrote: >>>> Lambdas removed! >>> >>> I got caught out by the cumulative patch file again :( >>> >>> Changes look good! >> >> Thanks David! >> >> /Robbin >> >>> >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java >>>>> >>>>> Existing: >>>>> >>>>> 76???????????????? JavaThread cur = threads.getJavaThreadAt(k); >>>>> 77???????????????? if (cur.isJavaThread()) { >>>>> >>>>> How can cur possibly be anything other than a JavaThread? >>>> >>>> The SA seems to have a slightly different model, so only pure JavaThreads >>>> return true. >>>> ServiceThread, CompilerThread, etc, returns false. >>> >>> Ah - a poorly named method that emulates ThreadService::is_hidden_thread. >>> >>> Thanks, >>> David >>> >>>> >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java >>>>> >>>>> Same issue: >>>>> >>>>> ??463???????????? if (t.isJavaThread()) { >>>>> >>>>> Possibly more of these I didn't go searching - so probably separate cleanup >>>>> RFE. >>>>> >>>>> --- >>>>> >>>>> Up to you whether you want to keep lambda's but at least ensure consistency >>>>> in their use - ie use them everywhere you can. But you know my thoughts on >>>>> it. :) >>>> >>>> Removed! >>>> >>>> Thanks, Robbin. >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/ >>>>>> http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/ >>>>>> >>>>>> /Robbin >>>>>> >>>>>> On 2019-05-08 11:17, Robbin Ehn wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I changed to normal for: >>>>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>>>>>> >>>>>>> >>>>>>> Full: >>>>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>>>>>> Inc: >>>>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>>>>>> >>>>>>> Passes t1-2 >>>>>>> >>>>>>> Thanks, Robbin >>>>>>> >>>>>>> >>>>>>> On 2019-05-07 09:47, David Holmes wrote: >>>>>>>> Hi Robbin, >>>>>>>> >>>>>>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>>>>>> Hi Robbin, >>>>>>>>>> >>>>>>>>>> I have a few concerns here. >>>>>>>>>> >>>>>>>>>> First I can't see how you are actually integrating the SA with the >>>>>>>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate but >>>>>>>>>> IIRC that list can be updated when threads are added/removed and I'm >>>>>>>>>> not seeing how the SA is left iterating a valid list - we'd normally >>>>>>>>>> using a ThreadsListHandle for that ?? (I may need a refresher on how >>>>>>>>>> this list is actually maintained.) >>>>>>>>> >>>>>>>>> The processes must be paused. If the processes would be running the >>>>>>>>> linked list is also broken since if we unlink and delete a JavaThread >>>>>>>>> and then later SA follows that _next pointer. >>>>>>>> >>>>>>>> Ah good point. Thanks for clarifying. >>>>>>>> >>>>>>>>>> >>>>>>>>>> The conversion from external iteration of the list (the for loop) to >>>>>>>>>> internal iteration (passing a lambda to JavaThreadsDo) is also >>>>>>>>>> problematic. First I'd be very wary about introducing lambda >>>>>>>>>> expressions into the SA code - lambda drags in a lot of supporting >>>>>>>>>> code that could have an impact on the way SA functions. There are >>>>>>>>>> places where we have to avoid lambdas due to >>>>>>>>>> bootstrapping/initialization issues and I think the SA may be an area >>>>>>>>>> where we also want to keep the code extremely simple. >>>>>>>>> >>>>>>>>> There are already several usages of lambdas in SA code, e.g. >>>>>>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an application, >>>>>>>>> there is not a bootstrap issue or so. >>>>>>>> >>>>>>>> Hmm okay. Lambda carries a lot of baggage. But if its already being used >>>>>>>> ... >>>>>>>> >>>>>>>>>> Second by using lambda's with internal iteration you've lost the >>>>>>>>>> ability to terminate the iteration loop! In the existing code if we >>>>>>>>>> have a return in the for-loop then we not only terminate the loop but >>>>>>>>>> the enclosing method. With the lambda the "return" just ends the >>>>>>>>>> current iteration and JavaThreadsDo will then continue with the next >>>>>>>>>> thread - so we don't even terminate the iteration let alone the method >>>>>>>>>> performing the iteration. So for places were we want to process one >>>>>>>>>> thread, for example, we will continue to iterate all remaining threads >>>>>>>>>> and just do nothing with them. That's very inefficient. >>>>>>>>> >>>>>>>>> That's why I only used the internal iteration where we didn't have >>>>>>>>> early returns. >>>>>>>> >>>>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java - >>>>>>>> original code: >>>>>>>> >>>>>>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>>>>>> 1557???????????? public void doit(Tokens t) { >>>>>>>> ... >>>>>>>> 1564???????????????????? for (JavaThread thread = threads.first(); >>>>>>>> thread != null; thread = thread.next()) { >>>>>>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>>>>>> ByteArrayOutputStream(); >>>>>>>> 1566 thread.printThreadIDOn(new PrintStream(bos)); >>>>>>>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>>>>>>> 1568???????????????????????????? out.println("Thread " + bos.toString() >>>>>>>> + " Address: " + thread.getAddress()); >>>>>>>> ... >>>>>>>> 1577???????????????????????????? } >>>>>>>> 1578???????????????????????????? if (!all) return; >>>>>>>> >>>>>>>> That looks like an early return to me. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, Robbin >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>>>>>> Hi, please review. >>>>>>>>>>> >>>>>>>>>>> Old threads linked list remove and updated SA to use ThreadsList >>>>>>>>>>> array instead. >>>>>>>>>>> >>>>>>>>>>> Issue: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>>>>>> >>>>>>>>>>> Passes t1-3 (which includes SA tests). >>>>>>>>>>> >>>>>>>>>>> Thanks, Robbin > From david.holmes at oracle.com Thu May 16 06:33:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 16:33:30 +1000 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> <5D669D64-3296-4F34-BDA0-17E467F2F94A@oracle.com> <8386d219-7680-63e7-cd0b-4e671938cac6@oracle.com> Message-ID: <71a59eb3-d426-cdae-a01c-12803f18f7ac@oracle.com> Hi Daniil, That seems fine to me. Thanks, David On 16/05/2019 5:15 am, Daniil Titov wrote: > Hi David, Chris, and JC, > > Please review a new version of the change that also fixes the similar problems in ClassTypeImpl.subclasses(), InterfaceTypeImpl.subinterfaces(), and InterfaceTypeImpl.implementors() methods. The fix moves the common code that iterates over all loaded types while ignoring ObjectCollectedException in a new method VirtualMachineImpl.forEachClass(Consumer). > > Method ReferenceTypeImpl.nestedTypes() doesn't have this problem (since the only method it calls on a reference type is name() that cannot throw ObjectCollectedException()). However, to avoid potential pitfalls in the future if someone decides to change this code, I modified this method to use the same pattern as in the cases listed above. > > All vmTestbase/nsk/jdi tests as well as tier1, tier2, and tier3 tests succeeded. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > Thanks, > Daniil > > ?On 5/13/19, 2:59 PM, "David Holmes" wrote: > > Hi Daniil, > > On 14/05/2019 5:56 am, Daniil Titov wrote: > > Hi David, > > > > It seems as the chances that class unloading happens during the life-time of these tests are extremely low and switching Graal on increases these chances. At least without Graal I could not locate any test result that showed that ClassUnload event was posted. With Graal on 1 of 500 tests fails (at least on Windows platform, on other platforms it must be more rare if not zero) and I could not find any successful test showing that ClassUnload event was ever posted for any class. > > Interesting that only Graal exposes this ... though it may be that the > reflection accessor actually relates to Graal code, hence the reason the > unloading only shows up with Graal. It may mean there is a hole in our > test coverage with JDI - may need some tests that involve executing > reflection code with accessors eagerly generated so that we do see > class-unload events. Though timing would be problematic. > > > You are right, the similar problem exists for ClassTypeImpl. subclasses() method and there is a separate issue for that: JDK-8223492. And while I was not able to reproduce it so far the logs provided in JDK-8223492 show that the problem here is the same. Initially I planned to keep these issues separated and proceed with JDK-8223492 after the current review is completed. But if you think it makes sense I could update the current webrev to include changes for ClassTypeImpl. subclasses() and then close JDK-8223492 as a duplicate. > > Entirely up to you. But I would be suspicious of all of the code that > iterates vm.allClasses(). > > > I am also curious whether lambda forms, e.g. org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388, are supposed to be visible in JDI but I could not locate any discussion about this. > > I'm trying to find that out too - but we can deal with that as a > separate issue. > > Thanks, > David > > > Thanks! > > --Daniil > > > > > > Per tests data and additional tracing it seems as with Graal on the chances that class unloading happens during the test run are about 1/200 and only on Windows platform. Without Graal there were no single occurrence of the test when any ClassUnload event was posted. > > > > ?On 5/12/19, 3:19 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > On 12/05/2019 3:14 am, Daniil Titov wrote: > > > Hi David, > > > > > > There are two ways how these reference types (for the classes that become unloaded later) could appear in the collection com.sun.tools.jdi.VirtualMachineImpl maintains and stores in VirtualMachineImpl.typesBySignature instance variable: > > > 1) Initial load when all classes are requested from the debuggee > > > 2) Or added later when ClassPrepare event for a specific class is posted and handled > > > > > > The reference types are removed from VirtualMachineImpl.typesBySignature when ClassUnload event is processed. However, additional tracing showed ( pleases see below the sample output) that in some cases these ClassUnload events are received after we entered definedClasses() method and started iterating over the copy of the collection of the classes returned by vm.allClasses() method. > > > > Thanks for clarifying that for me. I was thinking in this case that > > definedClasses() was directly querying the target VM, but it isn't it's > > iterating the existing set of known classes cached in the client > > (vm.allClasses()). > > > > Though it seems that whether or not we will hit this > > ObjectCollectedException depends on what we have already done with a > > particular ReferenceType. In this case we hit the exception when > > invoking classLoader() but that will only throw the exception if we do > > not already have the classLoader cached and have to go and seek it from > > the target VM. > > > > I do wonder why this issue should suddenly appear now? Encountering an > > unloaded class, like a generated reflection accessor, should always have > > been possible and so we should have seen this before. Something must > > have changed recently. ?? > > > > I'm also concerned about other code that iterates through > > vm.allClasses() and which does not seem to be aware of the possibility > > of CollectedObjectException. For example in ClassTypeImpl.java we have: > > > > public List subclasses() { > > List subs = new ArrayList<>(); > > for (ReferenceType refType : vm.allClasses()) { > > if (refType instanceof ClassType) { > > ClassType clazz = (ClassType)refType; > > ClassType superclass = clazz.superclass(); > > if ((superclass != null) && superclass.equals(this)) { > > subs.add((ClassType)refType); > > } > > } > > } > > > > return subs; > > } > > > > If the superclass is already cached then this will work, but if it has > > to call to the target VM over JDWP then we will have the same bug I > > think. Which again raises the question for me as to why we are not > > seeing tests fail here? > > > > > Based on the output below it seems as all unloaded classes are the generated ones or lambda forms. > > > > > > --> debugger: ......getting: List definedClasses = clRef.definedClasses(); > > > > > > Received Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > > Handled Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > > > This is fine - generated reflection accessor are loaded in a custom > > classloader specifically so they can be unloaded promptly. But ... > > > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > > > ... these are I believe definitions of VM anonymous classes (they have > > names of the form foo/ which are not legal class names). Should > > these even be visible to JDI? > > > > Thanks, > > David > > ----- > > > > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > > > > Exception while getting classloader for type jdk.internal.reflect.GeneratedConstructorAccessor1 > > > # ERROR: ##> debugger: ERROR: Exception : com.sun.jdi.ObjectCollectedException > > > > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > ?On 5/11/19, 3:39 AM, "David Holmes" wrote: > > > > > > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > > > > Isn't that the point? The list returned could have unloaded classes and > > > > we can catch it via this exception (from the comment above > > > > the ReferenceType interface): > > > > > > > > * Any method on ReferenceType or which directly or > > > > indirectly takes > > > > * ReferenceType as parameter may throw > > > > * {@link ObjectCollectedException} if the mirrored type has been unloaded. > > > > > > > > Turns out that even in the definedClasses, we can get that exception so > > > > we should check for it while walking the reference types as well? > > > > > > I understand that the list returned to the "debugger" process may > > > contain ReferenceTypes for types that have actually been unloaded by the > > > time it queries them (unless the debuggee is suspended of course). But I > > > don't see how we can encounter those types while compiling the list in > > > the debuggee in the first place. > > > > > > Something seems amiss here ... possibly just my understanding ... > > > > > > David > > > > > > > Jc > > > > > > > > *From: *Chris Plummer > > > > > > > > *Date: *Fri, May 10, 2019 at 9:09 PM > > > > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > > > > > > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > > > > On 5/10/19 8:59 PM, David Holmes wrote: > > > > >> Hi Daniil, > > > > >> > > > > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > > > > >>> Please review the change that fixes an intermittent failure of the > > > > >>> test. > > > > >>> > > > > >>> The tests checks the implementation of the > > > > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > > > > >>> that while > > > > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > > > > iterates > > > > >>> over all loaded classes to retrieve a classloader and compares > > > > it to > > > > >>> the current one, some of the classes might become unloaded and > > > > >>> garbage collected (e.g. > > > > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > > > > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > > > > >>> happens then the attempt to retrieve a classloader for the > > > > collected > > > > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > > > > >> > > > > >> That seems odd to me. If you have a reference to the Class then it > > > > >> can't be unloaded. I would not expect allClasses() to have > > > > >> weak-references, so a class should not be unloadable while you are > > > > >> examining it. Unless it is finding VM anonymous classes (which it > > > > >> should not!). > > > > >> > > > > > I was just typing up something similar. Shouldn't the test do a > > > > > vm.suspend() and then call disableCollection() on each class > > > > returned > > > > > by vm.allClasses()? > > > > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > > > > the user of ClassLoaderReference.definedClasses() to do the suspend. In > > > > fact I'm not sure there's much purpose in calling > > > > ClassLoaderReference.definedClasses() without suspending first. Even > > > > with your changes, the list returned can end up with references to > > > > unloaded classes. > > > > > > > > Chris > > > > > > > > > > Chris > > > > >> David > > > > >> ----- > > > > >> > > > > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > > > > >>> continues iterating over the rest of the classes. > > > > >>> > > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > > > > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > > > >>> > > > > >>> Thanks! > > > > >>> --Daniil > > > > >>> > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > > > > > > > From serguei.spitsyn at oracle.com Thu May 16 07:22:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 May 2019 00:22:58 -0700 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 16 07:25:29 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 May 2019 00:25:29 -0700 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 16 09:04:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 19:04:15 +1000 Subject: RFR: 8223666: SA: debugd options should follow jhsdb style In-Reply-To: <2e81112d-499c-0107-41e8-0c503ae04c9d@oracle.com> References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <635ff466-4e7c-d424-515b-fa04acf1fe3c@gmail.com> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> <04649AF8E13EB949B7D27EFDD2A37DFEE2B2725C@WMBOX4.soad.nttcom.co.jp> <8313fb86-eee4-08bd-4113-3fa3eb8463bc@nttcom.co.jp> <2e81112d-499c-0107-41e8-0c503ae04c9d@oracle.com> Message-ID: Just confirming I'm okay with this too. David On 16/05/2019 12:50 pm, serguei.spitsyn at oracle.com wrote: > Hi Osamu, > > On 5/15/19 19:45, Osamu Sakamoto wrote: >> Hi Serguei, >> >> > I'm Okay with the fix. >> Thank you for reviewing. >> I will request Yasumasa to push webrev.00.1 to jdk/jdk when the status >> of CSR changes to Approved > > Great! > >> > But we have to use correct subject line which includes bug number and >> > the exact bug title. >> > Otherwise, these emails are not searchable by the bug number. >> I added bug number and exact bug title to email subject. > > Nice. > > Thanks, > Serguei > >> >> Thanks, >> Osamu >> >> >> On 5/16/19 11:30, serguei.spitsyn at oracle.com wrote: >>> Hi Osamu, >>> >>> I'm Okay with the fix. >>> But we have to use correct subject line which includes bug number and >>> the exact bug title. >>> Otherwise, these emails are not searchable by the bug number. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/15/19 17:57, ?? ? wrote: >>>> Hi Serguei, >>>> >>>> Do you think which is better, to add angle bracket or not to? >>>>> By the way, you've added angle brackets to jhsdb debugd --help in >>>>> the CSR. >>>>> But current other commands --help don't have it. >>>>> I think this modification should be also added to other commands >>>>> --help if it is added to debugd --help. >>>>> This CSR relates on only debugd, so I think this modification >>>>> should be included to the RFE which David filed.(JDK-8223814) >>>> The webrev which is added angle bracket to debugd --help is here. >>>> >>>> >>>> Thanks, >>>> Osamu >>>> >>>> -- >>>> NTT ????????? >>>> ???????SE??OSS??? >>>> ???? >>>> TEL: 03-6713-3034 >>>> MAIL: >>>> >>>> -----Original Message----- >>>> From: Osamu Sakamoto >>>> Sent: Tuesday, May 14, 2019 4:22 PM >>>> To: serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net >>>> Cc: ?? ?? >>>> Subject: Re: debugd options should regard to jhsdb style >>>> >>>> Hi Serguei, >>>> >>>> Thank you for reviewing the CSR. >>>> >>>> I answer your questions. >>>> >>>> Q1 & Q2: and can accept >>>> both full path and relative path. >>>> Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently >>>> have the same format, and need not to be updated. >>>> >>>> >>>> By the way, you've added angle brackets to jhsdb debugd --help in >>>> the CSR. >>>> But current other commands --help don't have it. >>>> I think this modification should be also added to other commands >>>> --help if it is added to debugd --help. >>>> This CSR relates on only debugd, so I think this modification should >>>> be included to the RFE which David filed.(JDK-8223814) What do you >>>> think about this? >>>> >>>> Yasumasa has uploaded webrev.00.1 that angle bracket is added to >>>> debugd --help. >>>> I will request him to push the better one when this is clear >>>> >>>> >>>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: >>>>> Hi Osamu, >>>>> >>>>> Sorry for reacting on this so late. >>>>> This work on cmd-line options unification is very welcome! >>>>> >>>>> I looked at the CSR and it looks pretty good in general. >>>>> >>>>> I've added angle brackets to the jhsdb debugd --help: >>>>> >>>>> |$ jhsdb debugd --help --serverid >>>>> --exe --core --pid >>>> process to attach> But this needs to be unified with other commands >>>>> |||(clhsdb, hsdb, jstack, etc|), of course. | >>>>> >>>>> Also, added a comment with the questions: >>>>> >>>>> |Q1: Should the be always a full path name >>>>> or it >>>>> can be a relative path? Q2: Should the be always a >>>>> full path name or it can be a relative path? Q3: Do all other commans >>>>> (clhsdb, hsdb, jstack, jmap, etc.) currently have the same format or >>>>> they also need to be updated?| >>>>> >>>>> >>>>> I can update the CSR description if you answer these questions. >>>>> They'll file an RFE for this. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> >>>>> On 5/13/19 01:06, Osamu Sakamoto wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for updating the CSR. >>>>>> I agree with filing a RFE to improve the general jhsdb help output. >>>>>> >>>>>> Could you file the RFE? (I can't access JBS.) >>>>>> I would like to contribute it if the RFE will be filed. >>>>>> >>>>>> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >>>>>> So I will request Yasumasa to push it to jdk/jdk when the status of >>>>>> CSR changes to Approved, and RFE for jhsdb help is filed. >>>>>> >>>>>> Thanks, >>>>>> Osamu >>>>>> >>>>>> >>>>>> On 5/13/19 16:00, David Holmes wrote: >>>>>>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>>>>>> Hi, David >>>>>>>> >>>>>>>> I saw your comment in this CSR. >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>> >>>>>>>> I understand that the problem is that the help description of >>>>>>>> debugd >>>>>>>> I proposed and current other modes is not helpful for users. >>>>>>>> >>>>>>>> What should we do to go through this CSR? >>>>>>>> IMHO we should update help description of all jhsdb modes more >>>>>>>> helpful. >>>>>>>> Do you have any ideas about this? >>>>>>> I think a RFE should be filed to improve the general jhsdb help >>>>>>> output, so that it explains that --pid and --exe are mutually >>>>>>> exclusive options. That way this CSR, and thus the associated RFE >>>>>>> can >>>>>>> proceed. I'll add the same info the CSR. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> Osamu >>>>>>>> >>>>>>>> >>>>>>>> On 5/10/19 17:46, ?? ? wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I agree with Yasumasa's opinion in CSR. >>>>>>>>> >>>>>>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>>>>>> jmap and so on) in jhdsb. >>>>>>>>> Certainly, usage of debugd which I proposed does not explain that >>>>>>>>> and cannot be used together, but it is not limited to >>>>>>>>> debugd - other modes have similar issue. >>>>>>>>> >>>>>>>>> I think it is helpful to detail help description in each jhsdb >>>>>>>>> modes, but I'd like to separate as another issue because this is >>>>>>>>> not limited to debugd. >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Yasumasa Suenaga >>>>>>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>>>>>> To: David Holmes >>>>>>>>> Cc: Jean Christophe Beyler ; >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>> ; ?? ? >>>>>>>>> >>>>>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>>>>> >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thank you for checking in CSR, and sorry for my incorrect >>>>>>>>> description. >>>>>>>>> I added my opinion to CSR. >>>>>>>>> >>>>>>>>> Osamu, do you have any opinion? >>>>>>>>> >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> I've made some updates to the CSR request and raised a couple of >>>>>>>>>> issues. >>>>>>>>>> >>>>>>>>>> FYI the specification section only needs to contain the actual >>>>>>>>>> specification for what has changed ie the new command-line >>>>>>>>>> options; >>>>>>>>>> not the implementation that will bring about those changes. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>>>>>> Thanks JC! >>>>>>>>>>> >>>>>>>>>>> I added key point of this change to specification section in >>>>>>>>>>> CSR. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>>>>>> : >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>>>>>> specification section could use some text and then send the >>>>>>>>>>>> reader >>>>>>>>>>>> to the other bug entry :) Jc >>>>>>>>>>>> >>>>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>>>> >>>>>>>>>>>>> tests on submit repo have been passed >>>>>>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>>>>>> >>>>>>>>>>>>> Could you review the CSR? >>>>>>>>>>>>> >>>>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>>>>>> I will sponsor you. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>>>> >>>>>>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This will need a bug filed and a corresponding CSR >>>>>>>>>>>>>>> request. I >>>>>>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>>>>>> to match other tools. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>>>>>> --pid `. >>>>>>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Osamu >>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jc >>> > From david.holmes at oracle.com Thu May 16 09:25:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 19:25:13 +1000 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> Message-ID: <2f97fa41-eaef-d62c-8091-aa9bf2076bba@oracle.com> Hi Serguei, On 16/05/2019 5:22 pm, serguei.spitsyn at oracle.com wrote: > **Note #2* > > Just realized there is an incorrectness in current spec of this > capability an_redefine_any_class. > > This section > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#jvmtiCapabilities.can_redefine_any_class > > tells: > ?"Can modify (retransform or redefine) any modifiable class." > > It is just wrong. Instead, it should tell: > ?"Can modify (retransform or redefine) any class except primitive, array, > ? and some implementation defined classes." But that's what it does say by saying "any modifiable class". David ----- > In another place it is defined as: > ?"If possessed then all classes (except primitive, array, and some > implementation > ? defined classes) are modifiable (redefine or retransform). " > > For reference, see the section "Optional Features" here: > https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#IsModifiableClass > > I'll update the CSR to fix this issue. > > Thanks, > Serguei > >> >> -Alan > From daniel.fuchs at oracle.com Thu May 16 09:41:03 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 16 May 2019 10:41:03 +0100 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: Message-ID: Hi Ao Qi, I'm adding serviceability-dev, since this is for jdwp. The proposed changes look good to me - but please get someone from the serviceability team to review this. best regards, -- daniel On 16/05/2019 08:41, Ao Qi wrote: > Hi, > > I found build is failed on CentOS 7.6, because of loop initial > declarations. Could I please get reviews for this? > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224028 > > Webrev: > http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ > > Tested: > linux-x86_64-server-release tier1 > > Thanks, > Ao Qi > From serguei.spitsyn at oracle.com Thu May 16 09:47:43 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 May 2019 02:47:43 -0700 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <2f97fa41-eaef-d62c-8091-aa9bf2076bba@oracle.com> References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> <2f97fa41-eaef-d62c-8091-aa9bf2076bba@oracle.com> Message-ID: <15d0402b-3acf-bbc4-a0ed-6f397bc6f945@oracle.com> On 5/16/19 02:25, David Holmes wrote: > Hi Serguei, > > On 16/05/2019 5:22 pm, serguei.spitsyn at oracle.com wrote: >> **Note #2* >> >> Just realized there is an incorrectness in current spec of this >> capability an_redefine_any_class. >> >> This section >> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#jvmtiCapabilities.can_redefine_any_class >> >> >> tells: >> ??"Can modify (retransform or redefine) any modifiable class." >> >> It is just wrong. Instead, it should tell: >> ??"Can modify (retransform or redefine) any class except primitive, >> array, >> ?? and some implementation defined classes." > > But that's what it does say by saying "any modifiable class". I understand your confusion as I have it as well. :) The problem is that in the IsModifiableClass spec the affect of capability is explained as: ? "If possessed then all classes (except primitive, array, and some implementation ?? defined classes) are modifiable (redefine or retransform)." So that successful possession of this capability makes all classes (except primitive, etc.) to be modifiable. Thanks, Serguei > David > ----- > >> In another place it is defined as: >> ??"If possessed then all classes (except primitive, array, and some >> implementation >> ?? defined classes) are modifiable (redefine or retransform). " >> >> For reference, see the section "Optional Features" here: >> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#IsModifiableClass >> >> >> I'll update the CSR to fix this issue. >> >> Thanks, >> Serguei >> >>> >>> -Alan >> From serguei.spitsyn at oracle.com Thu May 16 09:59:07 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 May 2019 02:59:07 -0700 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: Message-ID: <9bf0741f-d480-2835-5077-ada1228caed4@oracle.com> An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu May 16 10:33:59 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 May 2019 11:33:59 +0100 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> Message-ID: On 16/05/2019 08:22, serguei.spitsyn at oracle.com wrote: > > Not sure, if I understand you correctly because there can be a > confusion here. > > Is it about the IsModifiableModule? : My comment was about how can_redefine_any_class is documented in the Capabilities table of IsModifiableClass. It currently has "If possessed then all classes (except ...) are modifiable". That said, I think I'm coming around to agreeing with your proposal. If/when there are unmodifiable modules then it will not be possible for agents to obtain the can_redefine_any_class capability. -Alan From david.holmes at oracle.com Thu May 16 12:30:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 22:30:29 +1000 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: Message-ID: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> What compiler was used here? We shouldn't be using anything that doesn't handle loop variable declarations! Thanks, David On 16/05/2019 7:41 pm, Daniel Fuchs wrote: > Hi Ao Qi, > > I'm adding serviceability-dev, since this is for jdwp. > > The proposed changes look good to me - but please get > someone from the serviceability team to review this. > > best regards, > > -- daniel > > > On 16/05/2019 08:41, Ao Qi wrote: >> Hi, >> >> I found build is failed on CentOS 7.6, because of loop initial >> declarations. Could I please get reviews for this? >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8224028 >> >> Webrev: >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ >> >> Tested: >> linux-x86_64-server-release tier1 >> >> Thanks, >> Ao Qi >> > From david.holmes at oracle.com Thu May 16 12:33:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 16 May 2019 22:33:19 +1000 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <15d0402b-3acf-bbc4-a0ed-6f397bc6f945@oracle.com> References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> <2f97fa41-eaef-d62c-8091-aa9bf2076bba@oracle.com> <15d0402b-3acf-bbc4-a0ed-6f397bc6f945@oracle.com> Message-ID: <520c1743-2607-a8aa-07ae-ba4240c48ba4@oracle.com> On 16/05/2019 7:47 pm, serguei.spitsyn at oracle.com wrote: > On 5/16/19 02:25, David Holmes wrote: >> Hi Serguei, >> >> On 16/05/2019 5:22 pm, serguei.spitsyn at oracle.com wrote: >>> **Note #2* >>> >>> Just realized there is an incorrectness in current spec of this >>> capability an_redefine_any_class. >>> >>> This section >>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#jvmtiCapabilities.can_redefine_any_class >>> >>> >>> tells: >>> ??"Can modify (retransform or redefine) any modifiable class." >>> >>> It is just wrong. Instead, it should tell: >>> ??"Can modify (retransform or redefine) any class except primitive, >>> array, >>> ?? and some implementation defined classes." >> >> But that's what it does say by saying "any modifiable class". > > I understand your confusion as I have it as well. :) > > The problem is that in the IsModifiableClass spec the affect of > capability is explained as: > ? "If possessed then all classes (except primitive, array, and some > implementation > ?? defined classes) are modifiable (redefine or retransform)." > > So that successful possession of this capability makes all classes > (except primitive, etc.) to be modifiable. Yes and so: "Can modify (retransform or redefine) any modifiable class." means "Can modify (retransform or redefine) any class (except primitive, etc)." I'm not seeing the problem. ?? David > Thanks, > Serguei > > >> David >> ----- >> >>> In another place it is defined as: >>> ??"If possessed then all classes (except primitive, array, and some >>> implementation >>> ?? defined classes) are modifiable (redefine or retransform). " >>> >>> For reference, see the section "Optional Features" here: >>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#IsModifiableClass >>> >>> >>> I'll update the CSR to fix this issue. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> -Alan >>> > From volker.simonis at gmail.com Thu May 16 14:08:17 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 16 May 2019 16:08:17 +0200 Subject: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 In-Reply-To: References: <9bd1e3aa-fc0d-a1cf-ff50-c5fc134c6d12@oracle.com> Message-ID: Hi Jc, from the perspective of the ppc64 and s390 port it is OK to exclude the two platforms from the test. When we will fix AGCT on the two platforms we will update the tests. Thanks, Volker On Thu, May 16, 2019 at 4:57 AM Jean Christophe Beyler wrote: > > Hi both, > > For the linux question, I was doing that less for the AGCT code itself but more for the dlsym I was doing in the test; I was not really wanting to support the various ways of getting the function pointer in the first iteration of the test. If we wanted to add it, I would prefer to do a separate bug/webrev to add it in a second step (For example, my theory is that dlsym works on mac but I'm not sure of the support there either). > > I like the idea of trying to only know what architectures are supported. >From what I can tell, if I restrain my inspection to linux: > > For the linux ports and pd_get_top_frame_for_signal_handler: > - aarch64, arm, ppc, sparc, x86 seem to have an implementation (or it calls the for_profiling_one) > - zero, s390 do not > > On the AsyncGetCallTrace itself, it seems like the #ifndef around the call that removes ppc64/ia64 is what is blocking it for ppc at least. > > Which means that on linux, we should remove zero, s390, ia64, and ppc64; or as you are suggesting allow aarch64, arm, sparc, and x86. > > I offer thus: > Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8224020 > > Thanks for the reviews! > Jc > > > > From: serguei.spitsyn at oracle.com > Date: Wed, May 15, 2019 at 7:44 PM > To: Chris Plummer, Jean Christophe Beyler, OpenJDK Serviceability > >> Hi Jc, >> >> I'm Okay with this fix in general modulo some suggestion from Chris below. >> >> >> On 5/15/19 18:49, Chris Plummer wrote: >> >> Hi JC, >> >> Looks like s390 is also not supported. Do we know for usre if it is implemented on other architectures, like aarch64? I wouldn't necessarily rely on the lack of a negative comment in JavaThread::pd_get_top_frame_for_signal_handler() to determine support. Maybe the test should list supported platforms rather than unsupported ones. >> >> >> I like the suggestion above. >> It is better to list what is supported now. >> >> Also, why does the test currently require linux? >> >> >> My guess is that Jc does not have other platforms to check it on. >> Probably, it is Okay for now to keep it this way. >> Then we could file an RFE, check if ASGCT tests work Okay on other OS'es and relax this limitation. >> >> Thanks, >> Serguei >> >> >> Chris >> >> On 5/15/19 6:01 PM, Jean Christophe Beyler wrote: >> >> Hi all, >> >> Could I get a review that restricts the test to not run on PPC64/IA64 please? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224020 >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.00/ >> >> I also moved NULL -> RTLD_DEFAULT as the man page on linux does not specify the behavior of passing NULL. >> >> Thanks, >> Jc >> >> >> > > > -- > > Thanks, > Jc From jcbeyler at google.com Thu May 16 14:26:10 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 16 May 2019 07:26:10 -0700 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> Message-ID: >From my experience, some compiler in Solaris/Windows complain about this (or used to a year ago via the submit repo); Serguei and I had to do this dance when we were getting the heap monitoring tests in. An alternative is to move the file to a C++ file. Adding an extern "C" at the top would make symbols not be mangled and it should "work" without having to go to old-C requirements. Thanks, Jc On Thu, May 16, 2019 at 5:31 AM David Holmes wrote: > What compiler was used here? We shouldn't be using anything that doesn't > handle loop variable declarations! > > Thanks, > David > > On 16/05/2019 7:41 pm, Daniel Fuchs wrote: > > Hi Ao Qi, > > > > I'm adding serviceability-dev, since this is for jdwp. > > > > The proposed changes look good to me - but please get > > someone from the serviceability team to review this. > > > > best regards, > > > > -- daniel > > > > > > On 16/05/2019 08:41, Ao Qi wrote: > >> Hi, > >> > >> I found build is failed on CentOS 7.6, because of loop initial > >> declarations. Could I please get reviews for this? > >> > >> Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8224028 > >> > >> Webrev: > >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ > >> > >> Tested: > >> linux-x86_64-server-release tier1 > >> > >> Thanks, > >> Ao Qi > >> > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Thu May 16 16:32:18 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 May 2019 09:32:18 -0700 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> Message-ID: On 5/16/19 03:33, Alan Bateman wrote: > > > On 16/05/2019 08:22, serguei.spitsyn at oracle.com wrote: >> >> Not sure, if I understand you correctly because there can be a >> confusion here. >> >> Is it about the IsModifiableModule? : > My comment was about how can_redefine_any_class is documented in the > Capabilities table of IsModifiableClass. It currently has "If > possessed then all classes (except ...) are modifiable". > > That said, I think I'm coming around to agreeing with your proposal. > If/when there are unmodifiable modules then it will not be possible > for agents to obtain the can_redefine_any_class capability. Agreed. Thanks, Serguei > -Alan From alexey.menkov at oracle.com Thu May 16 16:38:27 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 16 May 2019 09:38:27 -0700 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> Message-ID: <8578a33a-899c-2163-d1e5-52863976a8ac@oracle.com> On 05/16/2019 06:41, Ao Qi wrote: > Hi Serguei, > > I saw your email [1], but I didn't receive it yet. Thanks for your > review! I updated: > > http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ Looks good. --alex > > On Thu, May 16, 2019 at 8:30 PM David Holmes wrote: >> >> What compiler was used here? We shouldn't be using anything that doesn't >> handle loop variable declarations! > > The compiler I used is gcc 4.8.5. This machine is used for testing > jdk/jdk for months. As far as I remember, loop variable declarations > issue never been found. If gcc 4.8.5 is not a supported compiler, I > think we should update building doc [2]. > >> >> Thanks, >> David >> >> On 16/05/2019 7:41 pm, Daniel Fuchs wrote: >>> Hi Ao Qi, >>> >>> I'm adding serviceability-dev, since this is for jdwp. >>> >>> The proposed changes look good to me - but please get >>> someone from the serviceability team to review this. > > Thanks Daniel! > > Cheers, > Ao Qi > > [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html > [2] https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc > > >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 16/05/2019 08:41, Ao Qi wrote: >>>> Hi, >>>> >>>> I found build is failed on CentOS 7.6, because of loop initial >>>> declarations. Could I please get reviews for this? >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8224028 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ >>>> >>>> Tested: >>>> linux-x86_64-server-release tier1 >>>> >>>> Thanks, >>>> Ao Qi >>>> >>> From serguei.spitsyn at oracle.com Thu May 16 16:40:17 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 May 2019 09:40:17 -0700 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <520c1743-2607-a8aa-07ae-ba4240c48ba4@oracle.com> References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> <2f97fa41-eaef-d62c-8091-aa9bf2076bba@oracle.com> <15d0402b-3acf-bbc4-a0ed-6f397bc6f945@oracle.com> <520c1743-2607-a8aa-07ae-ba4240c48ba4@oracle.com> Message-ID: <5afbe19e-7c5a-9fc1-4243-d0daf8116fdf@oracle.com> Hi David, On 5/16/19 05:33, David Holmes wrote: > On 16/05/2019 7:47 pm, serguei.spitsyn at oracle.com wrote: >> On 5/16/19 02:25, David Holmes wrote: >>> Hi Serguei, >>> >>> On 16/05/2019 5:22 pm, serguei.spitsyn at oracle.com wrote: >>>> **Note #2* >>>> >>>> Just realized there is an incorrectness in current spec of this >>>> capability an_redefine_any_class. >>>> >>>> This section >>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#jvmtiCapabilities.can_redefine_any_class >>>> >>>> >>>> tells: >>>> ??"Can modify (retransform or redefine) any modifiable class." >>>> >>>> It is just wrong. Instead, it should tell: >>>> ??"Can modify (retransform or redefine) any class except primitive, >>>> array, >>>> ?? and some implementation defined classes." >>> >>> But that's what it does say by saying "any modifiable class". >> >> I understand your confusion as I have it as well. :) >> >> The problem is that in the IsModifiableClass spec the affect of >> capability is explained as: >> ?? "If possessed then all classes (except primitive, array, and some >> implementation >> ??? defined classes) are modifiable (redefine or retransform)." >> >> So that successful possession of this capability makes all classes >> (except primitive, etc.) to be modifiable. > > Yes and so: > > "Can modify (retransform or redefine) any modifiable class." > > means > > "Can modify (retransform or redefine) any class (except primitive, etc)." > > I'm not seeing the problem. ?? The problem is that this statement is confusing: ? "Can modify (retransform or redefine) any modifiable class." It is because possessing the capability makes ALL the classes (except primitive, array, ...) modifiable. Which means that there can be non-modifiable classes other than primitive, array, and some implementation defined classes." Thanks, Serguei > > David > >> Thanks, >> Serguei >> >> >>> David >>> ----- >>> >>>> In another place it is defined as: >>>> ??"If possessed then all classes (except primitive, array, and some >>>> implementation >>>> ?? defined classes) are modifiable (redefine or retransform). " >>>> >>>> For reference, see the section "Optional Features" here: >>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#IsModifiableClass >>>> >>>> >>>> I'll update the CSR to fix this issue. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> -Alan >>>> >> From serguei.spitsyn at oracle.com Thu May 16 16:44:59 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 16 May 2019 09:44:59 -0700 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: <8578a33a-899c-2163-d1e5-52863976a8ac@oracle.com> References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> <8578a33a-899c-2163-d1e5-52863976a8ac@oracle.com> Message-ID: <7a41526d-4101-fca3-1f5e-3cfe4b326720@oracle.com> Hi Ao Qi, Thank you for the update. It looks good to me. Do you need a sponsor for integration? Thanks, Serguei On 5/16/19 09:38, Alex Menkov wrote: > > > On 05/16/2019 06:41, Ao Qi wrote: >> Hi Serguei, >> >> I saw your email [1], but I didn't receive it yet. Thanks for your >> review! I updated: >> >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ > > Looks good. > > --alex > >> >> On Thu, May 16, 2019 at 8:30 PM David Holmes >> wrote: >>> >>> What compiler was used here? We shouldn't be using anything that >>> doesn't >>> handle loop variable declarations! >> >> The compiler I used is gcc 4.8.5. This machine is used for testing >> jdk/jdk for months. As far as I remember, loop variable declarations >> issue never been found. If gcc 4.8.5 is not a supported compiler, I >> think we should update building doc [2]. >> >>> >>> Thanks, >>> David >>> >>> On 16/05/2019 7:41 pm, Daniel Fuchs wrote: >>>> Hi Ao Qi, >>>> >>>> I'm adding serviceability-dev, since this is for jdwp. >>>> >>>> The proposed changes look good to me - but please get >>>> someone from the serviceability team to review this. >> >> Thanks Daniel! >> >> Cheers, >> Ao Qi >> >> [1] >> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html >> [2] >> https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc >> >> >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> >>>> On 16/05/2019 08:41, Ao Qi wrote: >>>>> Hi, >>>>> >>>>> I found build is failed on CentOS 7.6, because of loop initial >>>>> declarations. Could I please get reviews for this? >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8224028 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ >>>>> >>>>> Tested: >>>>> linux-x86_64-server-release tier1 >>>>> >>>>> Thanks, >>>>> Ao Qi >>>>> >>>> From daniil.x.titov at oracle.com Thu May 16 18:10:12 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Thu, 16 May 2019 11:10:12 -0700 Subject: 8222422: vmTestbase/nsk/jdi/ClassLoaderReference/definedClasses tests failed with Unexpected Exception: null In-Reply-To: <71a59eb3-d426-cdae-a01c-12803f18f7ac@oracle.com> References: <859659FC-0733-482A-A4C9-0C0452F467FC@oracle.com> <3f4fd121-00f0-6781-c4b7-7e82f0c06973@oracle.com> <72796CA3-D287-4FC1-B144-E9C6BFB255BB@oracle.com> <5D669D64-3296-4F34-BDA0-17E467F2F94A@oracle.com> <8386d219-7680-63e7-cd0b-4e671938cac6@oracle.com> <71a59eb3-d426-cdae-a01c-12803f18f7ac@oracle.com> Message-ID: <8B66D43F-9D85-42CE-90F5-30E8A35879D3@oracle.com> Thank you Chris, David, and JC, for reviewing this change! Best regards, Daniil ?On 5/15/19, 11:33 PM, "David Holmes" wrote: Hi Daniil, That seems fine to me. Thanks, David On 16/05/2019 5:15 am, Daniil Titov wrote: > Hi David, Chris, and JC, > > Please review a new version of the change that also fixes the similar problems in ClassTypeImpl.subclasses(), InterfaceTypeImpl.subinterfaces(), and InterfaceTypeImpl.implementors() methods. The fix moves the common code that iterates over all loaded types while ignoring ObjectCollectedException in a new method VirtualMachineImpl.forEachClass(Consumer). > > Method ReferenceTypeImpl.nestedTypes() doesn't have this problem (since the only method it calls on a reference type is name() that cannot throw ObjectCollectedException()). However, to avoid potential pitfalls in the future if someone decides to change this code, I modified this method to use the same pattern as in the cases listed above. > > All vmTestbase/nsk/jdi tests as well as tier1, tier2, and tier3 tests succeeded. > > Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > Thanks, > Daniil > > ?On 5/13/19, 2:59 PM, "David Holmes" wrote: > > Hi Daniil, > > On 14/05/2019 5:56 am, Daniil Titov wrote: > > Hi David, > > > > It seems as the chances that class unloading happens during the life-time of these tests are extremely low and switching Graal on increases these chances. At least without Graal I could not locate any test result that showed that ClassUnload event was posted. With Graal on 1 of 500 tests fails (at least on Windows platform, on other platforms it must be more rare if not zero) and I could not find any successful test showing that ClassUnload event was ever posted for any class. > > Interesting that only Graal exposes this ... though it may be that the > reflection accessor actually relates to Graal code, hence the reason the > unloading only shows up with Graal. It may mean there is a hole in our > test coverage with JDI - may need some tests that involve executing > reflection code with accessors eagerly generated so that we do see > class-unload events. Though timing would be problematic. > > > You are right, the similar problem exists for ClassTypeImpl. subclasses() method and there is a separate issue for that: JDK-8223492. And while I was not able to reproduce it so far the logs provided in JDK-8223492 show that the problem here is the same. Initially I planned to keep these issues separated and proceed with JDK-8223492 after the current review is completed. But if you think it makes sense I could update the current webrev to include changes for ClassTypeImpl. subclasses() and then close JDK-8223492 as a duplicate. > > Entirely up to you. But I would be suspicious of all of the code that > iterates vm.allClasses(). > > > I am also curious whether lambda forms, e.g. org/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388, are supposed to be visible in JDI but I could not locate any discussion about this. > > I'm trying to find that out too - but we can deal with that as a > separate issue. > > Thanks, > David > > > Thanks! > > --Daniil > > > > > > Per tests data and additional tracing it seems as with Graal on the chances that class unloading happens during the test run are about 1/200 and only on Windows platform. Without Graal there were no single occurrence of the test when any ClassUnload event was posted. > > > > ?On 5/12/19, 3:19 PM, "David Holmes" wrote: > > > > Hi Daniil, > > > > On 12/05/2019 3:14 am, Daniil Titov wrote: > > > Hi David, > > > > > > There are two ways how these reference types (for the classes that become unloaded later) could appear in the collection com.sun.tools.jdi.VirtualMachineImpl maintains and stores in VirtualMachineImpl.typesBySignature instance variable: > > > 1) Initial load when all classes are requested from the debuggee > > > 2) Or added later when ClassPrepare event for a specific class is posted and handled > > > > > > The reference types are removed from VirtualMachineImpl.typesBySignature when ClassUnload event is processed. However, additional tracing showed ( pleases see below the sample output) that in some cases these ClassUnload events are received after we entered definedClasses() method and started iterating over the copy of the collection of the classes returned by vm.allClasses() method. > > > > Thanks for clarifying that for me. I was thinking in this case that > > definedClasses() was directly querying the target VM, but it isn't it's > > iterating the existing set of known classes cached in the client > > (vm.allClasses()). > > > > Though it seems that whether or not we will hit this > > ObjectCollectedException depends on what we have already done with a > > particular ReferenceType. In this case we hit the exception when > > invoking classLoader() but that will only throw the exception if we do > > not already have the classLoader cached and have to go and seek it from > > the target VM. > > > > I do wonder why this issue should suddenly appear now? Encountering an > > unloaded class, like a generated reflection accessor, should always have > > been possible and so we should have seen this before. Something must > > have changed recently. ?? > > > > I'm also concerned about other code that iterates through > > vm.allClasses() and which does not seem to be aware of the possibility > > of CollectedObjectException. For example in ClassTypeImpl.java we have: > > > > public List subclasses() { > > List subs = new ArrayList<>(); > > for (ReferenceType refType : vm.allClasses()) { > > if (refType instanceof ClassType) { > > ClassType clazz = (ClassType)refType; > > ClassType superclass = clazz.superclass(); > > if ((superclass != null) && superclass.equals(this)) { > > subs.add((ClassType)refType); > > } > > } > > } > > > > return subs; > > } > > > > If the superclass is already cached then this will work, but if it has > > to call to the target VM over JDWP then we will have the same bug I > > think. Which again raises the question for me as to why we are not > > seeing tests fail here? > > > > > Based on the output below it seems as all unloaded classes are the generated ones or lambda forms. > > > > > > --> debugger: ......getting: List definedClasses = clRef.definedClasses(); > > > > > > Received Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > > Handled Unload Event for Ljdk/internal/reflect/GeneratedConstructorAccessor1; > > > > This is fine - generated reflection accessor are loaded in a custom > > classloader specifically so they can be unloaded promptly. But ... > > > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$93/1045689388; > > > > ... these are I believe definitions of VM anonymous classes (they have > > names of the form foo/ which are not legal class names). Should > > these even be visible to JDI? > > > > Thanks, > > David > > ----- > > > > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/733189374; > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$94/454340234; > > > Received Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > > Handled Unload Event for Ljava/lang/invoke/LambdaForm$DMH/1780167778; > > > Received Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > Handled Unload Event for Lorg/graalvm/compiler/lir/alloc/lsra/LinearScanLifetimeAnalysisPhase$$Lambda$86/323001064; > > > > > > Exception while getting classloader for type jdk.internal.reflect.GeneratedConstructorAccessor1 > > > # ERROR: ##> debugger: ERROR: Exception : com.sun.jdi.ObjectCollectedException > > > > > > > > > Thanks! > > > --Daniil > > > > > > > > > > > > ?On 5/11/19, 3:39 AM, "David Holmes" wrote: > > > > > > On 11/05/2019 2:14 pm, Jean Christophe Beyler wrote: > > > > Isn't that the point? The list returned could have unloaded classes and > > > > we can catch it via this exception (from the comment above > > > > the ReferenceType interface): > > > > > > > > * Any method on ReferenceType or which directly or > > > > indirectly takes > > > > * ReferenceType as parameter may throw > > > > * {@link ObjectCollectedException} if the mirrored type has been unloaded. > > > > > > > > Turns out that even in the definedClasses, we can get that exception so > > > > we should check for it while walking the reference types as well? > > > > > > I understand that the list returned to the "debugger" process may > > > contain ReferenceTypes for types that have actually been unloaded by the > > > time it queries them (unless the debuggee is suspended of course). But I > > > don't see how we can encounter those types while compiling the list in > > > the debuggee in the first place. > > > > > > Something seems amiss here ... possibly just my understanding ... > > > > > > David > > > > > > > Jc > > > > > > > > *From: *Chris Plummer > > > > > > > > *Date: *Fri, May 10, 2019 at 9:09 PM > > > > *To: *David Holmes, Daniil Titov, OpenJDK Serviceability > > > > > > > > On 5/10/19 9:03 PM, Chris Plummer wrote: > > > > > On 5/10/19 8:59 PM, David Holmes wrote: > > > > >> Hi Daniil, > > > > >> > > > > >> On 11/05/2019 12:10 pm, Daniil Titov wrote: > > > > >>> Please review the change that fixes an intermittent failure of the > > > > >>> test. > > > > >>> > > > > >>> The tests checks the implementation of the > > > > >>> com.sun.tools.jdi.ClassLoaderReference class. The problem here is > > > > >>> that while > > > > >>> com.sun.tools.jdi.ClassLoaderReferenceImpl.definedClasses() > > > > iterates > > > > >>> over all loaded classes to retrieve a classloader and compares > > > > it to > > > > >>> the current one, some of the classes might become unloaded and > > > > >>> garbage collected (e.g. > > > > >>> org.graalvm.compiler.nodes.InliningLog$$Lambda$41.899832640 or > > > > >>> jdk.internal.reflect.GeneratedConstructorAccessor1, etc.). If this > > > > >>> happens then the attempt to retrieve a classloader for the > > > > collected > > > > >>> class results in com.sun.jdi.ObjectCollectedException being thrown. > > > > >> > > > > >> That seems odd to me. If you have a reference to the Class then it > > > > >> can't be unloaded. I would not expect allClasses() to have > > > > >> weak-references, so a class should not be unloadable while you are > > > > >> examining it. Unless it is finding VM anonymous classes (which it > > > > >> should not!). > > > > >> > > > > > I was just typing up something similar. Shouldn't the test do a > > > > > vm.suspend() and then call disableCollection() on each class > > > > returned > > > > > by vm.allClasses()? > > > > Oh wait, this isn't a test. It's part of JDI. I guess it would be up to > > > > the user of ClassLoaderReference.definedClasses() to do the suspend. In > > > > fact I'm not sure there's much purpose in calling > > > > ClassLoaderReference.definedClasses() without suspending first. Even > > > > with your changes, the list returned can end up with references to > > > > unloaded classes. > > > > > > > > Chris > > > > > > > > > > Chris > > > > >> David > > > > >> ----- > > > > >> > > > > >>> The fix catches this com.sun.jdi.ObjectCollectedException and > > > > >>> continues iterating over the rest of the classes. > > > > >>> > > > > >>> Webrev: http://cr.openjdk.java.net/~dtitov/8222422/webrev.01 > > > > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8222422 > > > > >>> > > > > >>> Thanks! > > > > >>> --Daniil > > > > >>> > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Thanks, > > > > Jc > > > > > > > > > > > > > > > > > > From aoqi at loongson.cn Thu May 16 18:25:37 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 17 May 2019 02:25:37 +0800 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: <7a41526d-4101-fca3-1f5e-3cfe4b326720@oracle.com> References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> <8578a33a-899c-2163-d1e5-52863976a8ac@oracle.com> <7a41526d-4101-fca3-1f5e-3cfe4b326720@oracle.com> Message-ID: On Fri, May 17, 2019 at 12:44 AM serguei.spitsyn at oracle.com wrote: > > Hi Ao Qi, > > Thank you for the update. > It looks good to me. Thanks! > > Do you need a sponsor for integration? Yes:) > > Thanks, > Serguei > > > On 5/16/19 09:38, Alex Menkov wrote: > > > > > > On 05/16/2019 06:41, Ao Qi wrote: > >> Hi Serguei, > >> > >> I saw your email [1], but I didn't receive it yet. Thanks for your > >> review! I updated: > >> > >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ > > > > Looks good. > > > > --alex > > > >> > >> On Thu, May 16, 2019 at 8:30 PM David Holmes > >> wrote: > >>> > >>> What compiler was used here? We shouldn't be using anything that > >>> doesn't > >>> handle loop variable declarations! > >> > >> The compiler I used is gcc 4.8.5. This machine is used for testing > >> jdk/jdk for months. As far as I remember, loop variable declarations > >> issue never been found. If gcc 4.8.5 is not a supported compiler, I > >> think we should update building doc [2]. > >> > >>> > >>> Thanks, > >>> David > >>> > >>> On 16/05/2019 7:41 pm, Daniel Fuchs wrote: > >>>> Hi Ao Qi, > >>>> > >>>> I'm adding serviceability-dev, since this is for jdwp. > >>>> > >>>> The proposed changes look good to me - but please get > >>>> someone from the serviceability team to review this. > >> > >> Thanks Daniel! > >> > >> Cheers, > >> Ao Qi > >> > >> [1] > >> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html > >> [2] > >> https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc > >> > >> > >>>> > >>>> best regards, > >>>> > >>>> -- daniel > >>>> > >>>> > >>>> On 16/05/2019 08:41, Ao Qi wrote: > >>>>> Hi, > >>>>> > >>>>> I found build is failed on CentOS 7.6, because of loop initial > >>>>> declarations. Could I please get reviews for this? > >>>>> > >>>>> Bug: > >>>>> https://bugs.openjdk.java.net/browse/JDK-8224028 > >>>>> > >>>>> Webrev: > >>>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ > >>>>> > >>>>> Tested: > >>>>> linux-x86_64-server-release tier1 > >>>>> > >>>>> Thanks, > >>>>> Ao Qi > >>>>> > >>>> > From alexey.menkov at oracle.com Thu May 16 19:17:50 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 16 May 2019 12:17:50 -0700 Subject: RFR: JDK-8221713: JDWP spec - allow option is not described Message-ID: Hi all, Back in JDK10 "allow" option was implemented for dt_socket transport: https://bugs.openjdk.java.net/browse/JDK-8061228 CCC: https://bugs.openjdk.java.net/browse/CCC-8061228 But this option was not reflected in "Connection and Invocation Details" page. JBS: https://bugs.openjdk.java.net/browse/JDK-8221713 webrev: http://cr.openjdk.java.net/~amenkov/docs/allow/webrev/ results: old: http://cr.openjdk.java.net/~amenkov/docs/allow/0/conninv.html new: http://cr.openjdk.java.net/~amenkov/docs/allow/1/conninv.html specdiff: http://cr.openjdk.java.net/~amenkov/docs/allow/conninv.specdiff/diff.html --alex From jcbeyler at google.com Thu May 16 19:52:07 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 16 May 2019 12:52:07 -0700 Subject: RFR: JDK-8221713: JDWP spec - allow option is not described In-Reply-To: References: Message-ID: Hi Alex, Only nit I saw was: + For IPv4 prefix length must be in range 1..31, for IPv6 - in range 1..127. to + For IPv4, the prefix length must be in range 1..31; for IPv6, the range must be 1..127. No need of a new webrev if you do change it of course :) Jc On Thu, May 16, 2019 at 12:18 PM Alex Menkov wrote: > Hi all, > > Back in JDK10 "allow" option was implemented for dt_socket transport: > https://bugs.openjdk.java.net/browse/JDK-8061228 > CCC: https://bugs.openjdk.java.net/browse/CCC-8061228 > But this option was not reflected in "Connection and Invocation Details" > page. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8221713 > webrev: http://cr.openjdk.java.net/~amenkov/docs/allow/webrev/ > > results: > old: http://cr.openjdk.java.net/~amenkov/docs/allow/0/conninv.html > new: http://cr.openjdk.java.net/~amenkov/docs/allow/1/conninv.html > > specdiff: > http://cr.openjdk.java.net/~amenkov/docs/allow/conninv.specdiff/diff.html > > --alex > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcbeyler at google.com Thu May 16 20:58:00 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 16 May 2019 13:58:00 -0700 Subject: RFR (S) 8224020: AsyncGetCallTrace test should not run on PPC64 or IA64 In-Reply-To: References: <9bd1e3aa-fc0d-a1cf-ff50-c5fc134c6d12@oracle.com> Message-ID: Thanks all, I pushed it like this then because it seems more "incremental", Jc On Thu, May 16, 2019 at 7:08 AM Volker Simonis wrote: > Hi Jc, > > from the perspective of the ppc64 and s390 port it is OK to exclude > the two platforms from the test. When we will fix AGCT on the two > platforms we will update the tests. > > Thanks, > Volker > > On Thu, May 16, 2019 at 4:57 AM Jean Christophe Beyler > wrote: > > > > Hi both, > > > > For the linux question, I was doing that less for the AGCT code itself > but more for the dlsym I was doing in the test; I was not really wanting to > support the various ways of getting the function pointer in the first > iteration of the test. If we wanted to add it, I would prefer to do a > separate bug/webrev to add it in a second step (For example, my theory is > that dlsym works on mac but I'm not sure of the support there either). > > > > I like the idea of trying to only know what architectures are supported. > From what I can tell, if I restrain my inspection to linux: > > > > For the linux ports and pd_get_top_frame_for_signal_handler: > > - aarch64, arm, ppc, sparc, x86 seem to have an implementation (or it > calls the for_profiling_one) > > - zero, s390 do not > > > > On the AsyncGetCallTrace itself, it seems like the #ifndef around the > call that removes ppc64/ia64 is what is blocking it for ppc at least. > > > > Which means that on linux, we should remove zero, s390, ia64, and ppc64; > or as you are suggesting allow aarch64, arm, sparc, and x86. > > > > I offer thus: > > Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224020 > > > > Thanks for the reviews! > > Jc > > > > > > > > From: serguei.spitsyn at oracle.com > > Date: Wed, May 15, 2019 at 7:44 PM > > To: Chris Plummer, Jean Christophe Beyler, OpenJDK Serviceability > > > >> Hi Jc, > >> > >> I'm Okay with this fix in general modulo some suggestion from Chris > below. > >> > >> > >> On 5/15/19 18:49, Chris Plummer wrote: > >> > >> Hi JC, > >> > >> Looks like s390 is also not supported. Do we know for usre if it is > implemented on other architectures, like aarch64? I wouldn't necessarily > rely on the lack of a negative comment in > JavaThread::pd_get_top_frame_for_signal_handler() to determine support. > Maybe the test should list supported platforms rather than unsupported ones. > >> > >> > >> I like the suggestion above. > >> It is better to list what is supported now. > >> > >> Also, why does the test currently require linux? > >> > >> > >> My guess is that Jc does not have other platforms to check it on. > >> Probably, it is Okay for now to keep it this way. > >> Then we could file an RFE, check if ASGCT tests work Okay on other > OS'es and relax this limitation. > >> > >> Thanks, > >> Serguei > >> > >> > >> Chris > >> > >> On 5/15/19 6:01 PM, Jean Christophe Beyler wrote: > >> > >> Hi all, > >> > >> Could I get a review that restricts the test to not run on PPC64/IA64 > please? > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8224020 > >> Webrev: http://cr.openjdk.java.net/~jcbeyler/8224020/webrev.00/ > >> > >> I also moved NULL -> RTLD_DEFAULT as the man page on linux does not > specify the behavior of passing NULL. > >> > >> Thanks, > >> Jc > >> > >> > >> > > > > > > -- > > > > Thanks, > > Jc > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 16 22:01:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2019 08:01:25 +1000 Subject: RFC: 8223915: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <5afbe19e-7c5a-9fc1-4243-d0daf8116fdf@oracle.com> References: <24402fc4-e680-a9e1-d770-de0026ca771a@oracle.com> <2f97fa41-eaef-d62c-8091-aa9bf2076bba@oracle.com> <15d0402b-3acf-bbc4-a0ed-6f397bc6f945@oracle.com> <520c1743-2607-a8aa-07ae-ba4240c48ba4@oracle.com> <5afbe19e-7c5a-9fc1-4243-d0daf8116fdf@oracle.com> Message-ID: <8e1a11e8-0c12-caca-47b9-82a0575fc975@oracle.com> On 17/05/2019 2:40 am, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 5/16/19 05:33, David Holmes wrote: >> On 16/05/2019 7:47 pm, serguei.spitsyn at oracle.com wrote: >>> On 5/16/19 02:25, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 16/05/2019 5:22 pm, serguei.spitsyn at oracle.com wrote: >>>>> **Note #2* >>>>> >>>>> Just realized there is an incorrectness in current spec of this >>>>> capability an_redefine_any_class. >>>>> >>>>> This section >>>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#jvmtiCapabilities.can_redefine_any_class >>>>> >>>>> >>>>> tells: >>>>> ??"Can modify (retransform or redefine) any modifiable class." >>>>> >>>>> It is just wrong. Instead, it should tell: >>>>> ??"Can modify (retransform or redefine) any class except primitive, >>>>> array, >>>>> ?? and some implementation defined classes." >>>> >>>> But that's what it does say by saying "any modifiable class". >>> >>> I understand your confusion as I have it as well. :) >>> >>> The problem is that in the IsModifiableClass spec the affect of >>> capability is explained as: >>> ?? "If possessed then all classes (except primitive, array, and some >>> implementation >>> ??? defined classes) are modifiable (redefine or retransform)." >>> >>> So that successful possession of this capability makes all classes >>> (except primitive, etc.) to be modifiable. >> >> Yes and so: >> >> "Can modify (retransform or redefine) any modifiable class." >> >> means >> >> "Can modify (retransform or redefine) any class (except primitive, etc)." >> >> I'm not seeing the problem. ?? > > > The problem is that this statement is confusing: > ? "Can modify (retransform or redefine) any modifiable class." > > It is because possessing the capability makes ALL the classes (except > primitive, array, ...) modifiable. > Which means that there can be non-modifiable classes other than > primitive, array, and some implementation defined classes." Again I don't see any issue. All classes except primitive, array, ... are potentially modifiable but you need the actual capability to be able to modify them. David ----- > Thanks, > Serguei > >> >> David >> >>> Thanks, >>> Serguei >>> >>> >>>> David >>>> ----- >>>> >>>>> In another place it is defined as: >>>>> ??"If possessed then all classes (except primitive, array, and some >>>>> implementation >>>>> ?? defined classes) are modifiable (redefine or retransform). " >>>>> >>>>> For reference, see the section "Optional Features" here: >>>>> https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#IsModifiableClass >>>>> >>>>> >>>>> I'll update the CSR to fix this issue. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> -Alan >>>>> >>> > From david.holmes at oracle.com Thu May 16 22:21:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2019 08:21:17 +1000 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> Message-ID: <04e91b4d-0caf-9772-746a-d12bebbce8d4@oracle.com> On 17/05/2019 12:26 am, Jean Christophe Beyler wrote: > From my experience, some compiler in Solaris/Windows complain about > this (or used to a year ago via the submit repo); Serguei and I had to > do this dance when we were getting the heap monitoring tests in. An I think the tests are different. This file is part of the main build and is being built the same way as all the other .c files in the core libraries. The Windows and Solaris sources already contain code with loop variable declarations. Yet much to my surprise the shared sources do not - seems gcc is the weak link here. :( > alternative is to move the file to a C++ file. Adding an extern "C" at > the top would make symbols not be mangled and it should "work"? without > having to go to old-C requirements. Not sure if that's feasible. Cheers, David ----- > Thanks, > Jc > > On Thu, May 16, 2019 at 5:31 AM David Holmes > wrote: > > What compiler was used here? We shouldn't be using anything that > doesn't > handle loop variable declarations! > > Thanks, > David > > On 16/05/2019 7:41 pm, Daniel Fuchs wrote: > > Hi Ao Qi, > > > > I'm adding serviceability-dev, since this is for jdwp. > > > > The proposed changes look good to me - but please get > > someone from the serviceability team to review this. > > > > best regards, > > > > -- daniel > > > > > > On 16/05/2019 08:41, Ao Qi wrote: > >> Hi, > >> > >> I found build is failed on CentOS 7.6, because of loop initial > >> declarations. Could I please get reviews for this? > >> > >> Bug: > >> https://bugs.openjdk.java.net/browse/JDK-8224028 > >> > >> Webrev: > >> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ > >> > >> Tested: > >> linux-x86_64-server-release tier1 > >> > >> Thanks, > >> Ao Qi > >> > > > > > > -- > > Thanks, > Jc From alexey.menkov at oracle.com Thu May 16 22:23:12 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 16 May 2019 15:23:12 -0700 Subject: Withdrawn: RFR: JDK-8221713: JDWP spec - allow option is not described In-Reply-To: References: Message-ID: Sorry, the request is withdrawn. --alex On 05/16/2019 12:17, Alex Menkov wrote: > Hi all, > > Back in JDK10 "allow" option was implemented for dt_socket transport: > https://bugs.openjdk.java.net/browse/JDK-8061228 > CCC: https://bugs.openjdk.java.net/browse/CCC-8061228 > But this option was not reflected in "Connection and Invocation Details" > page. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8221713 > webrev: http://cr.openjdk.java.net/~amenkov/docs/allow/webrev/ > > results: > old: http://cr.openjdk.java.net/~amenkov/docs/allow/0/conninv.html > new: http://cr.openjdk.java.net/~amenkov/docs/allow/1/conninv.html > > specdiff: > http://cr.openjdk.java.net/~amenkov/docs/allow/conninv.specdiff/diff.html > > --alex From david.holmes at oracle.com Thu May 16 22:25:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2019 08:25:21 +1000 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> Message-ID: <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com> On 16/05/2019 11:41 pm, Ao Qi wrote: > Hi Serguei, > > I saw your email [1], but I didn't receive it yet. Thanks for your > review! I updated: > > http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ > > On Thu, May 16, 2019 at 8:30 PM David Holmes wrote: >> >> What compiler was used here? We shouldn't be using anything that doesn't >> handle loop variable declarations! > > The compiler I used is gcc 4.8.5. This machine is used for testing > jdk/jdk for months. As far as I remember, loop variable declarations > issue never been found. If gcc 4.8.5 is not a supported compiler, I > think we should update building doc [2]. I'm surprised the out-of-the-box settings for 4.8.5 result in such an archaic version of C being supported. I thought we had addressed such limitations quite a while ago. :( That said perhaps it is time to bump the minimum gcc level beyond 4.8 ... Thanks, David ----- >> >> Thanks, >> David >> >> On 16/05/2019 7:41 pm, Daniel Fuchs wrote: >>> Hi Ao Qi, >>> >>> I'm adding serviceability-dev, since this is for jdwp. >>> >>> The proposed changes look good to me - but please get >>> someone from the serviceability team to review this. > > Thanks Daniel! > > Cheers, > Ao Qi > > [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html > [2] https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc > > >>> >>> best regards, >>> >>> -- daniel >>> >>> >>> On 16/05/2019 08:41, Ao Qi wrote: >>>> Hi, >>>> >>>> I found build is failed on CentOS 7.6, because of loop initial >>>> declarations. Could I please get reviews for this? >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8224028 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ >>>> >>>> Tested: >>>> linux-x86_64-server-release tier1 >>>> >>>> Thanks, >>>> Ao Qi >>>> >>> From jcbeyler at google.com Thu May 16 22:56:19 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Thu, 16 May 2019 15:56:19 -0700 Subject: RFR (M) 8224079: ExceptionJniWrapper for the Strace test suite Message-ID: Hi all, I was wanting to continue on deploying the ExceptionJniWrapper and the first on the list was this one C++ file. It is used by various Strace tests and I thought I'd stop at just this one to make it easier for reviewing. Webrev: http://cr.openjdk.java.net/~jcbeyler/8224079/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8224079 The biggest thing to note is that the error messages change a bit, originally if the native code noticed a problem it would return either 1 or 2, providing a message in Java land: a return of 1 would provide a message containing (OutOfMemoryError or StackOverflow) a return of 2 would provide a generic message such as Unexpected exception... Now 1 would give just a generic internal error but it would be with a message such as: FATAL ERROR in native method: JNI method CallIntMethod : internal error from StackTraceController.cpp : 48 at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method) at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343) at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method) at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343) at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method) at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343) at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method) at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343) at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method) at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343) at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method) at nsk.monitoring.stress.thread.RunningThread.recursionJava(strace001.java:343) at nsk.monitoring.stress.thread.RunningThread.recursionNative(Native Method) .... and you would guess it is either an OOM or a stack overflow. And 2 actually now gives you which method failed. So it's a win for the 2 case, for the 1 there is an extra step that, for me, seemed relatively straight forward. I can change the code slightly for the 1 case to make the error message more specific and closer to the original but I was not sure it was worth it.... What do you all think? Thanks for your help, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From martinrb at google.com Thu May 16 22:57:49 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 May 2019 15:57:49 -0700 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com> References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com> Message-ID: Maybe you just need to ask gcc to use a more modern -std=... It might reasonably be defaulting to gnu89 https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu On Thu, May 16, 2019 at 3:25 PM David Holmes wrote: > On 16/05/2019 11:41 pm, Ao Qi wrote: > > Hi Serguei, > > > > I saw your email [1], but I didn't receive it yet. Thanks for your > > review! I updated: > > > > http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ > > > > On Thu, May 16, 2019 at 8:30 PM David Holmes > wrote: > >> > >> What compiler was used here? We shouldn't be using anything that doesn't > >> handle loop variable declarations! > > > > The compiler I used is gcc 4.8.5. This machine is used for testing > > jdk/jdk for months. As far as I remember, loop variable declarations > > issue never been found. If gcc 4.8.5 is not a supported compiler, I > > think we should update building doc [2]. > > I'm surprised the out-of-the-box settings for 4.8.5 result in such an > archaic version of C being supported. I thought we had addressed such > limitations quite a while ago. :( > > That said perhaps it is time to bump the minimum gcc level beyond 4.8 ... > > Thanks, > David > ----- > > >> > >> Thanks, > >> David > >> > >> On 16/05/2019 7:41 pm, Daniel Fuchs wrote: > >>> Hi Ao Qi, > >>> > >>> I'm adding serviceability-dev, since this is for jdwp. > >>> > >>> The proposed changes look good to me - but please get > >>> someone from the serviceability team to review this. > > > > Thanks Daniel! > > > > Cheers, > > Ao Qi > > > > [1] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html > > [2] > https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc > > > > > >>> > >>> best regards, > >>> > >>> -- daniel > >>> > >>> > >>> On 16/05/2019 08:41, Ao Qi wrote: > >>>> Hi, > >>>> > >>>> I found build is failed on CentOS 7.6, because of loop initial > >>>> declarations. Could I please get reviews for this? > >>>> > >>>> Bug: > >>>> https://bugs.openjdk.java.net/browse/JDK-8224028 > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ > >>>> > >>>> Tested: > >>>> linux-x86_64-server-release tier1 > >>>> > >>>> Thanks, > >>>> Ao Qi > >>>> > >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu May 16 23:05:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2019 09:05:52 +1000 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com> Message-ID: On 17/05/2019 8:57 am, Martin Buchholz wrote: > Maybe you just need to ask gcc to use a more modern -std=... > It might reasonably be defaulting to gnu89 > https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu Yes, but I thought we'd already done this dance. Solaris was setting a flag to use C89 IIRC and we removed it. Cheers, David > On Thu, May 16, 2019 at 3:25 PM David Holmes > wrote: > > On 16/05/2019 11:41 pm, Ao Qi wrote: > > Hi Serguei, > > > > I saw your email [1], but I didn't receive it yet. Thanks for your > > review! I updated: > > > > http://cr.openjdk.java.net/~aoqi/8224028/webrev.01/ > > > > On Thu, May 16, 2019 at 8:30 PM David Holmes > > wrote: > >> > >> What compiler was used here? We shouldn't be using anything that > doesn't > >> handle loop variable declarations! > > > > The compiler I used is gcc 4.8.5. This machine is used for testing > > jdk/jdk for months. As far as I remember, loop variable declarations > > issue never been found. If gcc 4.8.5 is not a supported compiler, I > > think we should update building doc [2]. > > I'm surprised the out-of-the-box settings for 4.8.5 result in such an > archaic version of C being supported. I thought we had addressed such > limitations quite a while ago. :( > > That said perhaps it is time to bump the minimum gcc level beyond > 4.8 ... > > Thanks, > David > ----- > > >> > >> Thanks, > >> David > >> > >> On 16/05/2019 7:41 pm, Daniel Fuchs wrote: > >>> Hi Ao Qi, > >>> > >>> I'm adding serviceability-dev, since this is for jdwp. > >>> > >>> The proposed changes look good to me - but please get > >>> someone from the serviceability team to review this. > > > > Thanks Daniel! > > > > Cheers, > > Ao Qi > > > > [1] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-May/028097.html > > [2] > https://hg.openjdk.java.net/jdk/jdk/raw-file/17926213de55/doc/building.html#gcc > > > > > >>> > >>> best regards, > >>> > >>> -- daniel > >>> > >>> > >>> On 16/05/2019 08:41, Ao Qi wrote: > >>>> Hi, > >>>> > >>>> I found build is failed on CentOS 7.6, because of loop initial > >>>> declarations. Could I please get reviews for this? > >>>> > >>>> Bug: > >>>> https://bugs.openjdk.java.net/browse/JDK-8224028 > >>>> > >>>> Webrev: > >>>> http://cr.openjdk.java.net/~aoqi/8224028/webrev.00/ > >>>> > >>>> Tested: > >>>> linux-x86_64-server-release tier1 > >>>> > >>>> Thanks, > >>>> Ao Qi > >>>> > >>> > From martinrb at google.com Thu May 16 23:14:24 2019 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 May 2019 16:14:24 -0700 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com> Message-ID: On Thu, May 16, 2019 at 4:05 PM David Holmes wrote: > On 17/05/2019 8:57 am, Martin Buchholz wrote: > > Maybe you just need to ask gcc to use a more modern -std=... > > It might reasonably be defaulting to gnu89 > > > https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu > > Yes, but I thought we'd already done this dance. Solaris was setting a > flag to use C89 IIRC and we removed it. > A flag to use C89 is obviously bad if you're using features from a later standard. I was suggesting that you could pass gcc -std=gnu99 or -std= c99 (I would go whole hog to C11) $ gcc -v --help |& grep std=.*' C ' -std=c11 Conform to the ISO 2011 C standard -std=c89 Conform to the ISO 1990 C standard -std=c90 Conform to the ISO 1990 C standard -std=c99 Conform to the ISO 1999 C standard -std=gnu11 Conform to the ISO 2011 C standard with GNU -std=gnu89 Conform to the ISO 1990 C standard with GNU -std=gnu90 Conform to the ISO 1990 C standard with GNU -std=gnu99 Conform to the ISO 1999 C standard with GNU -std=iso9899:1990 Conform to the ISO 1990 C standard -std=iso9899:199409 Conform to the ISO 1990 C standard as amended in -std=iso9899:1999 Conform to the ISO 1999 C standard -std=iso9899:2011 Conform to the ISO 2011 C standard -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri May 17 00:19:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 May 2019 10:19:05 +1000 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com> Message-ID: On 17/05/2019 9:14 am, Martin Buchholz wrote: > On Thu, May 16, 2019 at 4:05 PM David Holmes > wrote: > > On 17/05/2019 8:57 am, Martin Buchholz wrote: > > Maybe you just need to ask gcc to use a more modern -std=... > > It might reasonably be defaulting to gnu89 > > > https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu > > Yes, but I thought we'd already done this dance. Solaris was setting a > flag to use C89 IIRC and we removed it. > > > A flag to use C89 is obviously bad if you're using features from a later > standard. > I was suggesting that you could pass gcc -std=gnu99 or -std= c99 (I > would go whole hog to C11) Again I thought we had done this dance. We set -std=gnu++98 but that only affects .cpp files. We need a similar thing for .c files. I know this has been discussed so I'll see if I can dig up the history and find out why we didn't do it. I'll file a build bug if needed. Cheers, David > ?$ gcc -v --help |& grep std=.*' C ' > ? -std=c11? ? ? ? ? ? ? ? ? ? Conform to the ISO 2011 C standard > ? -std=c89? ? ? ? ? ? ? ? ? ? Conform to the ISO 1990 C standard > ? -std=c90? ? ? ? ? ? ? ? ? ? Conform to the ISO 1990 C standard > ? -std=c99? ? ? ? ? ? ? ? ? ? Conform to the ISO 1999 C standard > ? -std=gnu11? ? ? ? ? ? ? ? ? Conform to the ISO 2011 C standard with GNU > ? -std=gnu89? ? ? ? ? ? ? ? ? Conform to the ISO 1990 C standard with GNU > ? -std=gnu90? ? ? ? ? ? ? ? ? Conform to the ISO 1990 C standard with GNU > ? -std=gnu99? ? ? ? ? ? ? ? ? Conform to the ISO 1999 C standard with GNU > ? -std=iso9899:1990? ? ? ? ? ?Conform to the ISO 1990 C standard > ? -std=iso9899:199409? ? ? ? ?Conform to the ISO 1990 C standard as > amended in > ? -std=iso9899:1999? ? ? ? ? ?Conform to the ISO 1999 C standard > ? -std=iso9899:2011? ? ? ? ? ?Conform to the ISO 2011 C standard From yasuenag at gmail.com Fri May 17 05:54:10 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 17 May 2019 14:54:10 +0900 Subject: RFR: 8223666: SA: debugd options should follow jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> <04649AF8E13EB949B7D27EFDD2A37DFEE2B2725C@WMBOX4.soad.nttcom.co.jp> <8313fb86-eee4-08bd-4113-3fa3eb8463bc@nttcom.co.jp> <2e81112d-499c-0107-41e8-0c503ae04c9d@oracle.com> Message-ID: Hi all, I pushed: http://hg.openjdk.java.net/jdk/jdk/rev/81852d53e585 Thanks all for helping us! Osamu, if you are working for JDK-8223814, please tell us when you done to create a patch. I can help you. Yasumasa On 2019/05/16 18:04, David Holmes wrote: > Just confirming I'm okay with this too. > > David > > On 16/05/2019 12:50 pm, serguei.spitsyn at oracle.com wrote: >> Hi Osamu, >> >> On 5/15/19 19:45, Osamu Sakamoto wrote: >>> Hi Serguei, >>> >>>> I'm Okay with the fix. >>> Thank you for reviewing. >>> I will request Yasumasa to push webrev.00.1 to jdk/jdk when the status >>> of CSR changes to Approved >> >> Great! >> >>>> But we have to use correct subject line which includes bug number and >>>> the exact bug title. >>>> Otherwise, these emails are not searchable by the bug number. >>> I added bug number and exact bug title to email subject. >> >> Nice. >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> Osamu >>> >>> >>> On 5/16/19 11:30, serguei.spitsyn at oracle.com wrote: >>>> Hi Osamu, >>>> >>>> I'm Okay with the fix. >>>> But we have to use correct subject line which includes bug number and >>>> the exact bug title. >>>> Otherwise, these emails are not searchable by the bug number. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/15/19 17:57, ?? ? wrote: >>>>> Hi Serguei, >>>>> >>>>> Do you think which is better, to add angle bracket or not to? >>>>>> By the way, you've added angle brackets to jhsdb debugd --help in >>>>>> the CSR. >>>>>> But current other commands --help don't have it. >>>>>> I think this modification should be also added to other commands >>>>>> --help if it is added to debugd --help. >>>>>> This CSR relates on only debugd, so I think this modification >>>>>> should be included to the RFE which David filed.(JDK-8223814) >>>>> The webrev which is added angle bracket to debugd --help is here. >>>>> >>>>> >>>>> Thanks, >>>>> Osamu >>>>> >>>>> -- >>>>> NTT ????????? >>>>> ???????SE??OSS??? >>>>> ???? >>>>> TEL: 03-6713-3034 >>>>> MAIL: >>>>> >>>>> -----Original Message----- >>>>> From: Osamu Sakamoto >>>>> Sent: Tuesday, May 14, 2019 4:22 PM >>>>> To: serguei.spitsyn at oracle.com; serviceability-dev at openjdk.java.net >>>>> Cc: ?? ?? >>>>> Subject: Re: debugd options should regard to jhsdb style >>>>> >>>>> Hi Serguei, >>>>> >>>>> Thank you for reviewing the CSR. >>>>> >>>>> I answer your questions. >>>>> >>>>> Q1 & Q2: and can accept >>>>> both full path and relative path. >>>>> Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently >>>>> have the same format, and need not to be updated. >>>>> >>>>> >>>>> By the way, you've added angle brackets to jhsdb debugd --help in >>>>> the CSR. >>>>> But current other commands --help don't have it. >>>>> I think this modification should be also added to other commands >>>>> --help if it is added to debugd --help. >>>>> This CSR relates on only debugd, so I think this modification should >>>>> be included to the RFE which David filed.(JDK-8223814) What do you >>>>> think about this? >>>>> >>>>> Yasumasa has uploaded webrev.00.1 that angle bracket is added to >>>>> debugd --help. >>>>> I will request him to push the better one when this is clear >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Osamu >>>>> >>>>> >>>>> On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Osamu, >>>>>> >>>>>> Sorry for reacting on this so late. >>>>>> This work on cmd-line options unification is very welcome! >>>>>> >>>>>> I looked at the CSR and it looks pretty good in general. >>>>>> >>>>>> I've added angle brackets to the jhsdb debugd --help: >>>>>> >>>>>> |$ jhsdb debugd --help --serverid >>>>>> --exe --core --pid >>>>> process to attach> But this needs to be unified with other commands >>>>>> |||(clhsdb, hsdb, jstack, etc|), of course. | >>>>>> >>>>>> Also, added a comment with the questions: >>>>>> >>>>>> |Q1: Should the be always a full path name >>>>>> or it >>>>>> can be a relative path? Q2: Should the be always a >>>>>> full path name or it can be a relative path? Q3: Do all other commans >>>>>> (clhsdb, hsdb, jstack, jmap, etc.) currently have the same format or >>>>>> they also need to be updated?| >>>>>> >>>>>> >>>>>> I can update the CSR description if you answer these questions. >>>>>> They'll file an RFE for this. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 5/13/19 01:06, Osamu Sakamoto wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for updating the CSR. >>>>>>> I agree with filing a RFE to improve the general jhsdb help output. >>>>>>> >>>>>>> Could you file the RFE? (I can't access JBS.) >>>>>>> I would like to contribute it if the RFE will be filed. >>>>>>> >>>>>>> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >>>>>>> So I will request Yasumasa to push it to jdk/jdk when the status of >>>>>>> CSR changes to Approved, and RFE for jhsdb help is filed. >>>>>>> >>>>>>> Thanks, >>>>>>> Osamu >>>>>>> >>>>>>> >>>>>>> On 5/13/19 16:00, David Holmes wrote: >>>>>>>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>>>>>>> Hi, David >>>>>>>>> >>>>>>>>> I saw your comment in this CSR. >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>> >>>>>>>>> I understand that the problem is that the help description of >>>>>>>>> debugd >>>>>>>>> I proposed and current other modes is not helpful for users. >>>>>>>>> >>>>>>>>> What should we do to go through this CSR? >>>>>>>>> IMHO we should update help description of all jhsdb modes more >>>>>>>>> helpful. >>>>>>>>> Do you have any ideas about this? >>>>>>>> I think a RFE should be filed to improve the general jhsdb help >>>>>>>> output, so that it explains that --pid and --exe are mutually >>>>>>>> exclusive options. That way this CSR, and thus the associated RFE >>>>>>>> can >>>>>>>> proceed. I'll add the same info the CSR. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Osamu >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/10/19 17:46, ?? ? wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I agree with Yasumasa's opinion in CSR. >>>>>>>>>> >>>>>>>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>>>>>>> jmap and so on) in jhdsb. >>>>>>>>>> Certainly, usage of debugd which I proposed does not explain that >>>>>>>>>> and cannot be used together, but it is not limited to >>>>>>>>>> debugd - other modes have similar issue. >>>>>>>>>> >>>>>>>>>> I think it is helpful to detail help description in each jhsdb >>>>>>>>>> modes, but I'd like to separate as another issue because this is >>>>>>>>>> not limited to debugd. >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>>>>>>> To: David Holmes >>>>>>>>>> Cc: Jean Christophe Beyler ; >>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>> ; ?? ? >>>>>>>>>> >>>>>>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>>>>>> >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thank you for checking in CSR, and sorry for my incorrect >>>>>>>>>> description. >>>>>>>>>> I added my opinion to CSR. >>>>>>>>>> >>>>>>>>>> Osamu, do you have any opinion? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>> >>>>>>>>>>> I've made some updates to the CSR request and raised a couple of >>>>>>>>>>> issues. >>>>>>>>>>> >>>>>>>>>>> FYI the specification section only needs to contain the actual >>>>>>>>>>> specification for what has changed ie the new command-line >>>>>>>>>>> options; >>>>>>>>>>> not the implementation that will bring about those changes. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>>>>>>> Thanks JC! >>>>>>>>>>>> >>>>>>>>>>>> I added key point of this change to specification section in >>>>>>>>>>>> CSR. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Yasumasa >>>>>>>>>>>> >>>>>>>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>>>>>>> : >>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>>>>>>> specification section could use some text and then send the >>>>>>>>>>>>> reader >>>>>>>>>>>>> to the other bug entry :) Jc >>>>>>>>>>>>> >>>>>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>>>>> >>>>>>>>>>>>>> tests on submit repo have been passed >>>>>>>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could you review the CSR? >>>>>>>>>>>>>> >>>>>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga : >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>>>>>>> I will sponsor you. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This will need a bug filed and a corresponding CSR >>>>>>>>>>>>>>>> request. I >>>>>>>>>>>>>>>> suspect that historically the form of this command was done >>>>>>>>>>>>>>>> to match other tools. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>>>>>>> However debugd mode has different options from other modes. >>>>>>>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>>>>>>> --pid `. >>>>>>>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Could you help? I want to contribute it. I need a sponsor. >>>>>>>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Osamu >>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Jc >>>> >> From yasuenag at gmail.com Fri May 17 05:59:42 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 17 May 2019 14:59:42 +0900 Subject: RFR: 8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java failed with timed out Message-ID: <0e7aaaaf-9bce-4da2-48ac-ed777b479742@gmail.com> Hi all, Please review a patch of testbug for debugd server: JBS: https://bugs.openjdk.java.net/browse/JDK-8163805 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ This issue has been reported since 2016, but it is not fixed yet. Root cause of this problem is `jhsdb` attempt to attach to test process. test process is parent of `jhsdb`. So jhsdb calls ptrace syscall to its parent. (test process is hanged by ptrace(2), so it cannot check the response from jhsdb.) We should use LingeredApp like jhsdb testcases. This is a testbug. It works fine with all serviceability/sa tests on my Linux x64. Thanks, Yasumasa From zanglin5 at jd.com Fri May 17 10:18:41 2019 From: zanglin5 at jd.com (=?gb2312?B?6rDB1Q==?=) Date: Fri, 17 May 2019 10:18:41 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <3551cf30-8741-2e63-a80e-708f31cf9ebc@oracle.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <0aa27238065e4b3f97887b82ec1a30bd@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> <3551cf30-8741-2e63-a80e-708f31cf9ebc@oracle.com> Message-ID: <8DC154BA-B292-4638-8AC2-5BAF3FD3A710@jd.com> Dear Serguei, ? 2019?5?16????1:39?serguei.spitsyn at oracle.com ??? On 5/13/19 23:46, ?? wrote: Dear Serguei, Thanks for your comments. > > - incremental[:], enable the incremental dump of heap, dumped > > data will be saved to, by default it is "IncrementalHisto.dump" > > Q1: Should the be full path or short name? > Is there any default path? What is the path of the > "IncrementalHisto.dump" file? The original design doesn't have the option so the file is hardcoded named "IncrementalHisto.dump" and save to the same path as "file=" specified. Or print to whatever output stream is if "file=" is not set. > The file option is described as: file= dump data to > It does not tell anything about the path. Yes, do you agree that we add a comment in the help info like: file= dump data to , file can be specified with full path. With the new design, I suggest firstly parse , if the value contains folder path, use the specified path, if not, use same path as "file=" value, and if "file=" is not set, use output stream. (The reason I prefer to use same path as "file=" is I assume that users prefer to save all data file under the same folder.) > It needs to be clearly specified. > What statements do you suggest? > > One idea of simplification is to get rid of the default > and to require it to be always specified (non-optional). > > Then we could replace this: > file= dump data to > incremental dump support: > incremental[:] enable incremental dump, data will be dumped > to (default is "IncrementalHisto.dump") > > with this: > file= dump data to > incremental= dump incremental data to I think having a default IncrementalHisto.dump file saved at the same path of the is a way to make incremental easy to use. IMHO, when user use jmap -histo with "file=?, and want to enable inremental histo, the easiest way is just use "-incremental" flag and all data files will be saved under the same folder of . They don?t have to consider the specific filename for incremental additionally. This is the reason I set default value of IncrementalHisto.dump. But I also want the user to have freedom to use different filename and path for incremental results, so I make it optional for incremental file_name. If we can make it non-optional, does it mean that user may have following command: Jmap -histo,file=,incremental: pid It seems a little bit complicated to me, what do you think? > > - chunksize=, size of objects (in KB) will be dumped in one chunk. > > Q2: Should it be chunk of dump, not chunk of objects? The purpose of "chunksize" is to decide how many objects' info are dumped at once. for example use "chunksize=1" on a "Xmx1m", there will be at max 1MB/1KB = 1000 chunks, which indicates that there will be 1000 times of file writing when do "jmap -histo". > I hardly understand the point to know max of objects that can be dumped at once. > It is more important to know how much memory in the file it is going to take. > How much of dump memory will take one object? > Does it vary (does it depend on object types)? Yes, the dump memory for one object varies from size and types. The option?chunksize? is for user to control the proportion of heap that the incremental dump can process at a time. IMO the use scenario is as following: when the JVM have an 180GB max heap size, and jmap histo used with chunksize=1g, it means the incremental dump happens when every 1GB heap is scaned, so it does?t has too much incremenal dump, because the incremental dump takes time and may cause jmap -histo work slower. PS, I think we should support ?g?,?m? and ?k? instead of using ?KB? , do you agree? > > - maxfilesize=, size of the incremental data dump file (in KB), when data size > > is larger than maxfilesize, the file is erased and latest data will be written. > Q3: What is a relation and limitations between chunksize and maxfilesize? > Should the maxfilesize be multiple of the chunksize? > The question Q3 above was not unanswered. > But never mind. Please, see the suggestion below. If the chunksize it large, and there are too much objects of different classes in heap, the actual filesize can be larger than the maxfilesize. But I believe this is raraly happened because the size of one class?s histo info only takes several bytes in the final result, and from the implementation of jmap, it can find out all loaded classes before doing heap iteration, so the different of result only happens on the object quantity. > Q4: The sentence "the file is erased and latest data will be written" is not clear enough. > Why the whole file needs to be erased > Should the incremental file behave like a cyclic buffer? > If so, then only next chunk needs to be erased. > Then the chunks need to be numbered in order, so the earliest one can be found. The "maxfilesize" controls the file size not to be too large, so when the dumped data is larger than "maxfilesize", the file is erased and latest data are written.The reason I erase whole file is that chunk data is accumulative, so the latest data includes the previous statistical ones. And this way may make the file easy to read. I agree that we can add ordered number in chunks, I think it more or less help user to get to know how object distributed in heap. I think maybe it is reasonable to have the incremental file behave like gclog, when maxfilesize is reached, the file is renamed with numbered suffix, and new file is created to use. so there can be IncrementalHisto.dump.0 and IncrementalHisto.dump.1 etc for large heap. what do you think? > I think, it is not a bad idea. > In general, new incremental feature design does not look simple and clear enough. > It feels like another step of simplification is needed. > What about to get rid of the maxfilesize option? > Then each chunk can be recorded to a separate file IncrementalHisto.dump.. > A couple of questions to clarify: > - Do want all chunks or just the latest chunk to be saved? I think usually it is not required to save all chunks. The chunk is incremental, so the new one contains all info that old ones have. But having old chunks may help user to know how object is distributed , because one chunk is a fixed proportion of heap, so the different between to a chunk and it?s predecessor can tell the object distribution of the newly scanned portion of heap. The question is do you think these info is necessary? If not, I agree we can get rid of the maxfilesize. > - If we save all chunks then what is the point to have the full dump recorded as well? IMO, the incremental histo solves two problems: <1> The jmap histo may stuck if heap is large, so it is useful if we can get intermediate result. <2> incremental info may help user know object distribution of some portion of the heap. And I agree that if full dump is successfully gotten, the chunks became less useful. > The advantages of this approach is that there is no need to describe: > - relationship between chunksize and maxfilesize > - recording behavior for multiple chunks in the incremental file > - what chunks have been recorded into the incremental I agree that maxfilesize may not be useful because the histo data of chunks are usually not large. And it sounds good to me that we save chunk data in seperate files named IncrementalHisto.dump.. So the problem is how much chunks do you think we need to save? I think the latest chunk is a must, and maybe the previous 3-5 ones? > But again, this still needs to be clearly specified. > It would be nice to reach a consensus on a design first. Totally agree :) > Thanks, > Serguei Again, Thanks for your comments BRs, Lin Thanks, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Saturday, May 11, 2019 2:17:41 AM To: ??; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear Lin, Sorry for the late reply. I've edited the CSR a little bit to fix some incorrect spots. Now, a couple of spots are not clear to me. > - incremental[:], enable the incremental dump of heap, dumped > data will be saved to, by default it is "IncrementalHisto.dump" Q1: Should the be full path or short name? Is there any default path? What is the path of the "IncrementalHisto.dump" file? > - chunksize=, size of objects (in KB) will be dumped in one chunk. Q2: Should it be chunk of dump, not chunk of objects? > - maxfilesize=, size of the incremental data dump file (in KB), when data size > is larger than maxfilesize, the file is erased and latest data will be written. Q3: What is a relation and limitations between chunksize and maxfilesize? Should the maxfilesize be multiple of the chunksize? Q4: The sentence "the file is erased and latest data will be written" is not clear enough. Why the whole file needs to be erased Should the incremental file behave like a cyclic buffer? If so, then only next chunk needs to be erased. Then the chunks need to be numbered in order, so the earliest one can be found. (I do not want you to accept my suggestions right away. It is just a discussion point. You need to prove that your approach is good and clean enough.) If we resolve the questions (or get into agreement) then I'll update the CSR as needed. Thanks, Serguei On 5/5/19 00:34, ?? wrote: Dear All, I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8222319 May I ask your help to review it? When it is finalized, I will refine the webrev. BRs, Lin Dear Serguei? Thanks a lot for your reviewing. System.err.println(" incremental dump support:"); + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); From this description is not clear at all what does the chunkcount mean. Is it to define how many heap objects are dumped in one chunk? If so, would it better to name it chunksize instead where chunksize is measured in heap objects? Then would it better to use the same units to define the maxfilesize as well? (I'm not insisting on this, just asking.) The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. BRs, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Fri May 17 14:13:44 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 17 May 2019 23:13:44 +0900 Subject: RFR: 8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java failed with timed out In-Reply-To: <0e7aaaaf-9bce-4da2-48ac-ed777b479742@gmail.com> References: <0e7aaaaf-9bce-4da2-48ac-ed777b479742@gmail.com> Message-ID: > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ This webrev failed on Windows x64 test on submit repo. I've fixed it, and it works fine on submit repo. (mach5-one-ysuenaga-JDK-8163805-20190517-1302-2522415) http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.01/ Could you review? Yasumasa On 2019/05/17 14:59, Yasumasa Suenaga wrote: > Hi all, > > Please review a patch of testbug for debugd server: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8163805 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ > > This issue has been reported since 2016, but it is not fixed yet. > > Root cause of this problem is `jhsdb` attempt to attach to test process. > test process is parent of `jhsdb`. So jhsdb calls ptrace syscall to its > parent. > (test process is hanged by ptrace(2), so it cannot check the response > from jhsdb.) > > We should use LingeredApp like jhsdb testcases. > > > This is a testbug. It works fine with all serviceability/sa tests on my > Linux x64. > > > Thanks, > > Yasumasa From aoqi at loongson.cn Fri May 17 15:11:53 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 17 May 2019 23:11:53 +0800 Subject: RFR: JDK-8224028: loop initial declarations introduced by JDK-8184770 (jdwp) In-Reply-To: References: <6d5d89dd-27c9-6079-f084-02fbd5f40642@oracle.com> <75d3556c-18a3-a26e-d016-9740d8e72f54@oracle.com> Message-ID: Hi, Aleksey has helped to push: http://hg.openjdk.java.net/jdk/jdk/rev/3205f4c40716. Thank you all! Cheers, Ao Qi On Fri, May 17, 2019 at 8:19 AM David Holmes wrote: > > On 17/05/2019 9:14 am, Martin Buchholz wrote: > > On Thu, May 16, 2019 at 4:05 PM David Holmes > > wrote: > > > > On 17/05/2019 8:57 am, Martin Buchholz wrote: > > > Maybe you just need to ask gcc to use a more modern -std=... > > > It might reasonably be defaulting to gnu89 > > > > > https://stackoverflow.com/questions/14737104/what-is-the-default-c-mode-for-the-current-gcc-especially-on-ubuntu > > > > Yes, but I thought we'd already done this dance. Solaris was setting a > > flag to use C89 IIRC and we removed it. > > > > > > A flag to use C89 is obviously bad if you're using features from a later > > standard. > > I was suggesting that you could pass gcc -std=gnu99 or -std= c99 (I > > would go whole hog to C11) > > Again I thought we had done this dance. We set -std=gnu++98 but that > only affects .cpp files. We need a similar thing for .c files. I know > this has been discussed so I'll see if I can dig up the history and find > out why we didn't do it. I'll file a build bug if needed. > > Cheers, > David > > > > $ gcc -v --help |& grep std=.*' C ' > > -std=c11 Conform to the ISO 2011 C standard > > -std=c89 Conform to the ISO 1990 C standard > > -std=c90 Conform to the ISO 1990 C standard > > -std=c99 Conform to the ISO 1999 C standard > > -std=gnu11 Conform to the ISO 2011 C standard with GNU > > -std=gnu89 Conform to the ISO 1990 C standard with GNU > > -std=gnu90 Conform to the ISO 1990 C standard with GNU > > -std=gnu99 Conform to the ISO 1999 C standard with GNU > > -std=iso9899:1990 Conform to the ISO 1990 C standard > > -std=iso9899:199409 Conform to the ISO 1990 C standard as > > amended in > > -std=iso9899:1999 Conform to the ISO 1999 C standard > > -std=iso9899:2011 Conform to the ISO 2011 C standard From chris.plummer at oracle.com Fri May 17 18:24:15 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 17 May 2019 11:24:15 -0700 Subject: RFR: 8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java failed with timed out In-Reply-To: References: <0e7aaaaf-9bce-4da2-48ac-ed777b479742@gmail.com> Message-ID: Hi Yasumasa, Looks good. Thanks for fixing. Chris On 5/17/19 7:13 AM, Yasumasa Suenaga wrote: > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ > > This webrev failed on Windows x64 test on submit repo. > I've fixed it, and it works fine on submit repo. > (mach5-one-ysuenaga-JDK-8163805-20190517-1302-2522415) > > ? http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.01/ > > Could you review? > > > Yasumasa > > > On 2019/05/17 14:59, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review a patch of testbug for debugd server: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8163805 >> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ >> >> This issue has been reported since 2016, but it is not fixed yet. >> >> Root cause of this problem is `jhsdb` attempt to attach to test process. >> test process is parent of `jhsdb`. So jhsdb calls ptrace syscall to >> its parent. >> (test process is hanged by ptrace(2), so it cannot check the response >> from jhsdb.) >> >> We should use LingeredApp like jhsdb testcases. >> >> >> This is a testbug. It works fine with all serviceability/sa tests on >> my Linux x64. >> >> >> Thanks, >> >> Yasumasa From serguei.spitsyn at oracle.com Fri May 17 18:41:45 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 17 May 2019 11:41:45 -0700 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: <8DC154BA-B292-4638-8AC2-5BAF3FD3A710@jd.com> References: <66546343ae324ab28bb54951ad774a89@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> <3551cf30-8741-2e63-a80e-708f31cf9ebc@oracle.com> <8DC154BA-B292-4638-8AC2-5BAF3FD3A710@jd.com> Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri May 17 18:43:48 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 17 May 2019 11:43:48 -0700 Subject: RFR (M) 8224079: ExceptionJniWrapper for the Strace test suite In-Reply-To: References: Message-ID: <6768087b-cf5f-9a11-0954-c3aa16c9373b@oracle.com> An HTML attachment was scrubbed... URL: From jcbeyler at google.com Fri May 17 23:17:54 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Fri, 17 May 2019 16:17:54 -0700 Subject: RFR: 8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java failed with timed out In-Reply-To: References: <0e7aaaaf-9bce-4da2-48ac-ed777b479742@gmail.com> Message-ID: Hi Yasumasa, Looks good to me too :) Jc On Fri, May 17, 2019 at 11:24 AM Chris Plummer wrote: > Hi Yasumasa, > > Looks good. Thanks for fixing. > > Chris > > On 5/17/19 7:13 AM, Yasumasa Suenaga wrote: > > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ > > > > This webrev failed on Windows x64 test on submit repo. > > I've fixed it, and it works fine on submit repo. > > (mach5-one-ysuenaga-JDK-8163805-20190517-1302-2522415) > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.01/ > > > > Could you review? > > > > > > Yasumasa > > > > > > On 2019/05/17 14:59, Yasumasa Suenaga wrote: > >> Hi all, > >> > >> Please review a patch of testbug for debugd server: > >> > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8163805 > >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ > >> > >> This issue has been reported since 2016, but it is not fixed yet. > >> > >> Root cause of this problem is `jhsdb` attempt to attach to test process. > >> test process is parent of `jhsdb`. So jhsdb calls ptrace syscall to > >> its parent. > >> (test process is hanged by ptrace(2), so it cannot check the response > >> from jhsdb.) > >> > >> We should use LingeredApp like jhsdb testcases. > >> > >> > >> This is a testbug. It works fine with all serviceability/sa tests on > >> my Linux x64. > >> > >> > >> Thanks, > >> > >> Yasumasa > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From yasuenag at gmail.com Sat May 18 06:43:56 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 18 May 2019 15:43:56 +0900 Subject: RFR: 8163805: hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java failed with timed out In-Reply-To: References: <0e7aaaaf-9bce-4da2-48ac-ed777b479742@gmail.com> Message-ID: Thank you Chris and JC! Yasumasa On 2019/05/18 8:17, Jean Christophe Beyler wrote: > Hi Yasumasa, > > Looks good to me too :) > Jc > > On Fri, May 17, 2019 at 11:24 AM Chris Plummer > wrote: > > Hi Yasumasa, > > Looks good. Thanks for fixing. > > Chris > > On 5/17/19 7:13 AM, Yasumasa Suenaga wrote: > > > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ > > > > This webrev failed on Windows x64 test on submit repo. > > I've fixed it, and it works fine on submit repo. > > (mach5-one-ysuenaga-JDK-8163805-20190517-1302-2522415) > > > > http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.01/ > > > > Could you review? > > > > > > Yasumasa > > > > > > On 2019/05/17 14:59, Yasumasa Suenaga wrote: > >> Hi all, > >> > >> Please review a patch of testbug for debugd server: > >> > >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8163805 > >> ?? webrev: > http://cr.openjdk.java.net/~ysuenaga/JDK-8163805/webrev.00/ > >> > >> This issue has been reported since 2016, but it is not fixed yet. > >> > >> Root cause of this problem is `jhsdb` attempt to attach to test > process. > >> test process is parent of `jhsdb`. So jhsdb calls ptrace syscall to > >> its parent. > >> (test process is hanged by ptrace(2), so it cannot check the > response > >> from jhsdb.) > >> > >> We should use LingeredApp like jhsdb testcases. > >> > >> > >> This is a testbug. It works fine with all serviceability/sa > tests on > >> my Linux x64. > >> > >> > >> Thanks, > >> > >> Yasumasa > > > > > > -- > > Thanks, > Jc From daniil.x.titov at oracle.com Sun May 19 21:12:10 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Sun, 19 May 2019 14:12:10 -0700 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows Message-ID: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. Webrev: http://cr.openjdk.java.net/~dtitov/8214545 Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 Thanks! --Daniil From david.holmes at oracle.com Mon May 20 00:43:45 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 20 May 2019 10:43:45 +1000 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: Hi Daniil, cc: Boris and Erik J. On 20/05/2019 7:12 am, Daniil Titov wrote: > Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. > > The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. > > The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. > > Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 I knew this seemed very familiar ... Boris had a fix for this a few weeks ago under JDK-8220581. Similar but not identical to yours - see below. Though getting rid of the exe from the repo is a good idea (thanks Erik!). A few comments test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh Pre-existing: ! REVOKEALL="$TESTNATIVEPATH/revokeall.exe" if [ ! -f "$REVOKEALL" ] ; then I would expect a -x test not -f. --- test/jdk/sun/management/windows/README The first copyright year should be 2004. 25 This directory contains the source and the binary version Delete "and the binary version". --- test/jdk/sun/management/windows/exerevokeall.c Pre-existing: 31 * file - suitable for NT/2000/XP only. Please delete everything after "file". 355 i++; 356 count--; The count-- is obvious as it is the loop counter, but it is far from clear to me that i++ is correct. I don't fully understand the logic but i is only incremented under very specific conditions. If you rewrote the code to avoid the use of the continue then i would not be modified except where it currently is. Thanks, David ----- > Thanks! > --Daniil > > From sakamoto.osamu at nttcom.co.jp Mon May 20 01:22:55 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Mon, 20 May 2019 10:22:55 +0900 Subject: RFR: 8223666: SA: debugd options should follow jhsdb style In-Reply-To: References: <04649AF8E13EB949B7D27EFDD2A37DFEE2B23D65@WMBOX4.soad.nttcom.co.jp> <39b4e658-59b2-7a02-fdf7-d9f97d502481@oracle.com> <04649AF8E13EB949B7D27EFDD2A37DFEE2B24166@WMBOX4.soad.nttcom.co.jp> <3bdaff35-53db-59ef-a528-8b04b55f477d@nttcom.co.jp> <378ccaf9-fade-52f5-3e8e-203d86ec9258@oracle.com> <14b9ac51-42be-54ed-8125-12de1cc5db30@oracle.com> <5a29ef8f-bfb4-0d06-78e1-4635dc515d62@nttcom.co.jp> <04649AF8E13EB949B7D27EFDD2A37DFEE2B2725C@WMBOX4.soad.nttcom.co.jp> <8313fb86-eee4-08bd-4113-3fa3eb8463bc@nttcom.co.jp> <2e81112d-499c-0107-41e8-0c503ae04c9d@oracle.com> Message-ID: Hi David Thank you for reviewing. Yasumasa Thank you for pushing. I will start to work for JDK-8223814. Thank all for helping us! Thanks, Osamu On 5/17/19 14:54, Yasumasa Suenaga wrote: > Hi all, > > I pushed: > ? http://hg.openjdk.java.net/jdk/jdk/rev/81852d53e585 > > Thanks all for helping us! > > > Osamu, if you are working for JDK-8223814, please tell us when you done > to create a patch. I can help you. > > > Yasumasa > > > On 2019/05/16 18:04, David Holmes wrote: >> Just confirming I'm okay with this too. >> >> David >> >> On 16/05/2019 12:50 pm, serguei.spitsyn at oracle.com wrote: >>> Hi Osamu, >>> >>> On 5/15/19 19:45, Osamu Sakamoto wrote: >>>> Hi Serguei, >>>> >>>>> I'm Okay with the fix. >>>> Thank you for reviewing. >>>> I will request Yasumasa to push webrev.00.1 to jdk/jdk when the status >>>> of CSR changes to Approved >>> >>> Great! >>> >>>>> But we have to use correct subject line which includes bug number and >>>>> the exact bug title. >>>>> Otherwise, these emails are not searchable by the bug number. >>>> I added bug number and exact bug title to email subject. >>> >>> Nice. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/16/19 11:30, serguei.spitsyn at oracle.com wrote: >>>>> Hi Osamu, >>>>> >>>>> I'm Okay with the fix. >>>>> But we have to use correct subject line which includes bug number and >>>>> the exact bug title. >>>>> Otherwise, these emails are not searchable by the bug number. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 5/15/19 17:57, ?? ? wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> Do you think which is better, to add angle bracket or not to? >>>>>>> By the way, you've added angle brackets to jhsdb debugd --help in >>>>>>> the CSR. >>>>>>> But current other commands --help don't have it. >>>>>>> I think this modification should be also added to other commands >>>>>>> --help if it is added to debugd --help. >>>>>>> This CSR relates on only debugd, so I think this modification >>>>>>> should be included to the RFE which David filed.(JDK-8223814) >>>>>> The webrev which is added angle bracket to debugd --help is here. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Osamu >>>>>> >>>>>> -- >>>>>> NTT ????????? >>>>>> ???????SE??OSS??? >>>>>> ???? >>>>>> TEL: 03-6713-3034 >>>>>> MAIL: >>>>>> >>>>>> -----Original Message----- >>>>>> From: Osamu Sakamoto >>>>>> Sent: Tuesday, May 14, 2019 4:22 PM >>>>>> To: serguei.spitsyn at oracle.com; serviceability-dev at >>>>>> openjdk.java.net >>>>>> Cc: ?? ?? >>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>> >>>>>> Hi Serguei, >>>>>> >>>>>> Thank you for reviewing the CSR. >>>>>> >>>>>> I answer your questions. >>>>>> >>>>>> Q1 & Q2: and can accept >>>>>> both full path and relative path. >>>>>> Q3: Other commands (clhsdb/hsdb/jstack/jmap/jinfo/jsnap) currently >>>>>> have the same format, and need not to be updated. >>>>>> >>>>>> >>>>>> By the way, you've added angle brackets to jhsdb debugd --help in >>>>>> the CSR. >>>>>> But current other commands --help don't have it. >>>>>> I think this modification should be also added to other commands >>>>>> --help if it is added to debugd --help. >>>>>> This CSR relates on only debugd, so I think this modification should >>>>>> be included to the RFE which David filed.(JDK-8223814) What do you >>>>>> think about this? >>>>>> >>>>>> Yasumasa has uploaded webrev.00.1 that angle bracket is added to >>>>>> debugd --help. >>>>>> I will request him to push the better one when this is clear >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Osamu >>>>>> >>>>>> >>>>>> On 5/14/19 14:07, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Osamu, >>>>>>> >>>>>>> Sorry for reacting on this so late. >>>>>>> This work on cmd-line options unification is very welcome! >>>>>>> >>>>>>> I looked at the CSR and it looks pretty good in general. >>>>>>> >>>>>>> I've added angle brackets to the jhsdb debugd --help: >>>>>>> >>>>>>> |$ jhsdb debugd --help --serverid >>>>>>> --exe --core --pid >>>>>>> >>>>>> process to attach> But this needs to be unified with other commands >>>>>>> |||(clhsdb, hsdb, jstack, etc|), of course. | >>>>>>> >>>>>>> Also, added a comment with the questions: >>>>>>> >>>>>>> |Q1: Should the be always a full path name >>>>>>> or it >>>>>>> can be a relative path? Q2: Should the be >>>>>>> always a >>>>>>> full path name or it can be a relative path? Q3: Do all other >>>>>>> commans >>>>>>> (clhsdb, hsdb, jstack, jmap, etc.) currently have the same format or >>>>>>> they also need to be updated?| >>>>>>> >>>>>>> >>>>>>> I can update the CSR description if you answer these questions. >>>>>>> They'll file an RFE for this. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 5/13/19 01:06, Osamu Sakamoto wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thank you for updating the CSR. >>>>>>>> I agree with filing a RFE to improve the general jhsdb help output. >>>>>>>> >>>>>>>> Could you file the RFE? (I can't access JBS.) >>>>>>>> I would like to contribute it if the RFE will be filed. >>>>>>>> >>>>>>>> My proposal (webrev.00) has been reviewed by Yasumasa and JC. >>>>>>>> So I will request Yasumasa to push it to jdk/jdk when the status of >>>>>>>> CSR changes to Approved, and RFE for jhsdb help is filed. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Osamu >>>>>>>> >>>>>>>> >>>>>>>> On 5/13/19 16:00, David Holmes wrote: >>>>>>>>> On 13/05/2019 4:38 pm, Osamu Sakamoto wrote: >>>>>>>>>> Hi, David >>>>>>>>>> >>>>>>>>>> I saw your comment in this CSR. >>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>> >>>>>>>>>> I understand that the problem is that the help description of >>>>>>>>>> debugd >>>>>>>>>> I proposed and current other modes is not helpful for users. >>>>>>>>>> >>>>>>>>>> What should we do to go through this CSR? >>>>>>>>>> IMHO we should update help description of all jhsdb modes more >>>>>>>>>> helpful. >>>>>>>>>> Do you have any ideas about this? >>>>>>>>> I think a RFE should be filed to improve the general jhsdb help >>>>>>>>> output, so that it explains that --pid and --exe are mutually >>>>>>>>> exclusive options. That way this CSR, and thus the associated RFE >>>>>>>>> can >>>>>>>>> proceed. I'll add the same info the CSR. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Osamu >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/10/19 17:46, ?? ? wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I agree with Yasumasa's opinion in CSR. >>>>>>>>>>> >>>>>>>>>>> I wrote new debugd format and usage to match other modes(jstack, >>>>>>>>>>> jmap and so on) in jhdsb. >>>>>>>>>>> Certainly, usage of debugd which I proposed does not explain >>>>>>>>>>> that >>>>>>>>>>> and cannot be used together, but it is not >>>>>>>>>>> limited to >>>>>>>>>>> debugd - other modes have similar issue. >>>>>>>>>>> >>>>>>>>>>> I think it is helpful to detail help description in each jhsdb >>>>>>>>>>> modes, but I'd like to separate as another issue because this is >>>>>>>>>>> not limited to debugd. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>>>> Sent: Friday, May 10, 2019 4:08 PM >>>>>>>>>>> To: David Holmes >>>>>>>>>>> Cc: Jean Christophe Beyler ; >>>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>>> ; ?? ? >>>>>>>>>>> >>>>>>>>>>> Subject: Re: debugd options should regard to jhsdb style >>>>>>>>>>> >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> Thank you for checking in CSR, and sorry for my incorrect >>>>>>>>>>> description. >>>>>>>>>>> I added my opinion to CSR. >>>>>>>>>>> >>>>>>>>>>> Osamu, do you have any opinion? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2019?5?10?(?) 15:16 David Holmes : >>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>> >>>>>>>>>>>> I've made some updates to the CSR request and raised a >>>>>>>>>>>> couple of >>>>>>>>>>>> issues. >>>>>>>>>>>> >>>>>>>>>>>> FYI the specification section only needs to contain the actual >>>>>>>>>>>> specification for what has changed ie the new command-line >>>>>>>>>>>> options; >>>>>>>>>>>> not the implementation that will bring about those changes. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 10/05/2019 2:12 pm, Yasumasa Suenaga wrote: >>>>>>>>>>>>> Thanks JC! >>>>>>>>>>>>> >>>>>>>>>>>>> I added key point of this change to specification section in >>>>>>>>>>>>> CSR. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>> >>>>>>>>>>>>> 2019?5?10?(?) 12:54 Jean Christophe Beyler >>>>>>>>>>>>> : >>>>>>>>>>>>>> Hi Yasumasa, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm not a reviewer but the CSR looks good; I feel that the >>>>>>>>>>>>>> specification section could use some text and then send the >>>>>>>>>>>>>> reader >>>>>>>>>>>>>> to the other bug entry :) Jc >>>>>>>>>>>>>> >>>>>>>>>>>>>> From: Yasumasa Suenaga >>>>>>>>>>>>>> Date: Thu, May 9, 2019 at 8:06 PM >>>>>>>>>>>>>> To: serviceability-dev at openjdk.java.net >>>>>>>>>>>>>> serviceability-dev at openjdk.java.net >>>>>>>>>>>>>> >>>>>>>>>>>>>>> tests on submit repo have been passed >>>>>>>>>>>>>>> (mach5-one-ysuenaga-JDK-8223665-20190510-0157-2376640) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Could you review the CSR? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2019?5?10?(?) 10:20 Yasumasa Suenaga >>>>>>>>>>>>>> gmail.com>: >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Osamu, your change looks good to me. >>>>>>>>>>>>>>>> I will sponsor you. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David, I filed this issue and requested to CSR: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8223665 >>>>>>>>>>>>>>>> ????? CSR: https://bugs.openjdk.java.net/browse/JDK-8223666 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I uploaded webrev. I will push it to submit repo. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8223665/webrev.00/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Yasumasa >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2019/05/10 7:30, David Holmes wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This will need a bug filed and a corresponding CSR >>>>>>>>>>>>>>>>> request. I >>>>>>>>>>>>>>>>> suspect that historically the form of this command was >>>>>>>>>>>>>>>>> done >>>>>>>>>>>>>>>>> to match other tools. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 9/05/2019 6:33 pm, ?? ? wrote: >>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I want to use `jhsdb debugd` on my laptop. >>>>>>>>>>>>>>>>>> However debugd mode has different options from other >>>>>>>>>>>>>>>>>> modes. >>>>>>>>>>>>>>>>>> I think debugd should have same options like other modes. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For example, `jhsdb debugd ` should be `jhsdb debugd >>>>>>>>>>>>>>>>>> --pid `. >>>>>>>>>>>>>>>>>> Also I added `--serverid` option for serverid. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I attached a patch for this enhancement. >>>>>>>>>>>>>>>>>> This patch passes serviceability/sa jtreg tests. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Testcase for debugd is available as >>>>>>>>>>>>>>>>>> serviceability/sa/sadebugd/SADebugDTest.java . >>>>>>>>>>>>>>>>>> However it has been disabled by JDK-8163805. >>>>>>>>>>>>>>>>>> It will be fixed by Yasumasa Suenaga (ysuenaga) after my >>>>>>>>>>>>>>>>>> proposal has been merged. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Could you help? I want to contribute it. I need a >>>>>>>>>>>>>>>>>> sponsor. >>>>>>>>>>>>>>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Osamu >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Jc >>>>> >>> From Alan.Bateman at oracle.com Mon May 20 06:03:28 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 20 May 2019 07:03:28 +0100 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: <0eebc323-7c82-2a7c-0d3d-ae5488394bf2@oracle.com> On 19/05/2019 22:12, Daniil Titov wrote: > Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. > > The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. > > The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. > > Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 Have you looked at replacing the tool with code that uses the java.nio.file API? You can edit ACLs with that API. -Alan From daniel.fuchs at oracle.com Mon May 20 10:13:08 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 20 May 2019 11:13:08 +0100 Subject: jmx-dev RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: Hi, On 20/05/2019 01:43, David Holmes wrote: >> Webrev: http://cr.openjdk.java.net/~dtitov/8214545 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic but > i is only incremented under very specific conditions. If you rewrote the > code to avoid the use of the continue then i would not be modified > except where it currently is. > Looks like `i` tries to count the entries that were not modified - so the fact that it was not incremented before `continue` looks like an oversight. I'd say that Daniil is right. I believe Alan wrote that tool - he may be able to confirm ;-) That said - if we could do the same thing in java as Alan suggests and replace these shell scripts with java that might be a big win! best regards, -- daniel From boris.ulasevich at bell-sw.com Mon May 20 10:44:03 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Mon, 20 May 2019 13:44:03 +0300 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: The change is good. Thank you! regards, Boris On 20.05.2019 3:43, David Holmes wrote: > Hi Daniil, > > cc: Boris and Erik J. > > On 20/05/2019 7:12 am, Daniil Titov wrote: >> Please review the change that fixes the failure of >> sun/management/jmxremote/bootstrap JMX tests on Windows platform. >> While running, these tests invoke revokeall.exe utility and this >> utility hangs. >> >> The problem here is that invokeall.exe goes into an endless loop >> while iterating over Access Control Entries (ACE) for a given file if >> it encounters at least one ACE with the type different from >> ACCESS_ALLOWED_ACE_TYPE. >> >> The change fixes this problem.? It also removes revokeall.exe binary >> from the repository and changes the makefile? to get it built instead. >> >> Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap >> tests succeeded? in Mach5. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8214545 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > I knew this seemed very familiar ... Boris had a fix for this a few > weeks ago under JDK-8220581. Similar but not identical to yours - see > below. Though getting rid of the exe from the repo is a good idea > (thanks Erik!). > > A few comments > > test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > > Pre-existing: > > !???????? REVOKEALL="$TESTNATIVEPATH/revokeall.exe" > ????????? if [ ! -f "$REVOKEALL" ] ; then > > I would expect a -x test not -f. > > --- > > test/jdk/sun/management/windows/README > > The first copyright year should be 2004. > > ? 25 This directory contains the source and the binary version > > Delete "and the binary version". > > --- > > test/jdk/sun/management/windows/exerevokeall.c > > Pre-existing: > > ?31? * file - suitable for NT/2000/XP only. > > Please delete everything after "file". > > > ?355???????????? i++; > ?356???????????? count--; > > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic but > i is only incremented under very specific conditions. If you rewrote the > code to avoid the use of the continue then i would not be modified > except where it currently is. > > Thanks, > David > ----- > >> Thanks! >> --Daniil >> >> From boris.ulasevich at bell-sw.com Mon May 20 10:52:32 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Mon, 20 May 2019 13:52:32 +0300 Subject: jmx-dev RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: On 20.05.2019 13:13, Daniel Fuchs wrote: > Hi, > > On 20/05/2019 01:43, David Holmes wrote: >>> Webrev: http://cr.openjdk.java.net/~dtitov/8214545 >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 >> The count-- is obvious as it is the loop counter, but it is far from >> clear to me that i++ is correct. I don't fully understand the logic >> but i is only incremented under very specific conditions. If you >> rewrote the code to avoid the use of the continue then i would not be >> modified except where it currently is. >> > > Looks like `i` tries to count the entries that were not > modified - so the fact that it was not incremented before > `continue` looks like an oversight. I'd say that Daniil is > right. There is iterating over list and changing it same time. It is common to iterate backward in such case to simplify logic. But this code is Ok for me too. > I believe Alan wrote that tool - he may be able to confirm ;-) > > That said - if we could do the same thing in java as Alan suggests > and replace these shell scripts with java that might be a big > win! > > best regards, > > -- daniel From zanglin5 at jd.com Mon May 20 15:14:34 2019 From: zanglin5 at jd.com (=?utf-8?B?6Ien55Cz?=) Date: Mon, 20 May 2019 15:14:34 +0000 Subject: [RFR]8215623: Add incremental dump for jmap histo In-Reply-To: References: <66546343ae324ab28bb54951ad774a89@jd.com> <74eaa1f868b74257beffff465f60edb2@jd.com> <29678a6a45ba490b8411315e0ad95837@jd.com> <938C194D-6A60-43BE-B563-7E5B0B728E1B@jd.com> <506CADD5-3533-42A9-8D91-B2D6F594D0E8@jd.com> <92FA3DD0-8A87-499F-A45B-DA2430E0258B@jd.com> <5AE26C74-65EB-410B-B4F4-CAE9BFC22970@jd.com> <825746cf-ee58-359f-3114-6075b3ce65f8@oracle.com> <8C6972EE-7361-4D40-89CA-BD68C601D00D@jd.com> <77bb5841-11cb-a54a-6ef2-e77c5b7fe0f8@oracle.com> <25bcef41d10f470fa2cb6d9f40966ef9@jd.com> <3551cf30-8741-2e63-a80e-708f31cf9ebc@oracle.com> <8DC154BA-B292-4638-8AC2-5BAF3FD3A710@jd.com> Message-ID: <5c6c2f4df6844d9ba118262d55990638@jd.com> Dear Serguei, The main reason of using separate file for incremental dump is due to the consideration of parallel incremental dump implementation, so that every heap-iteration thread could dump its own data in separate file, to avoid using file lock. I originally made the design of whole file-support, incremental, parallel dump together, and then divided them into three sub-tasks, trying to make each task easy to discuss and review. In that design, the file= option is for final results, ?incrementalHisto.dump.? is for thread ?local? incremental dumped data. For incremental dump, I agree it is better if we can get rid of incremental-file options and using file=, but I think we need to discuss how to make it adaptable for parallel dump. What do you think? Thanks, Lin From: serguei.spitsyn at oracle.com Sent: Saturday, May 18, 2019 2:42 AM To: ?? Cc: Hohensee, Paul ; JC Beyler ; serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear Lin, Before I go to the details below could you, please, explain why do we need a separate file for incremental dump. Should we just record the full dump into file= incrementally? Recording into the full dump file just has to be always incremental. It can be done by chunks if necessary, so I'm open to consider introducing new chunksize option. Do I miss anything here? Thanks, Serguei On 5/17/19 03:18, ?? wrote: Dear Serguei, ? 2019?5?16????1:39?serguei.spitsyn at oracle.com ??? On 5/13/19 23:46, ?? wrote: Dear Serguei, Thanks for your comments. > > - incremental[:], enable the incremental dump of heap, dumped > > data will be saved to, by default it is "IncrementalHisto.dump" > > Q1: Should the be full path or short name? > Is there any default path? What is the path of the > "IncrementalHisto.dump" file? The original design doesn't have the option so the file is hardcoded named "IncrementalHisto.dump" and save to the same path as "file=" specified. Or print to whatever output stream is if "file=" is not set. > The file option is described as: file= dump data to > It does not tell anything about the path. Yes, do you agree that we add a comment in the help info like: file= dump data to , file can be specified with full path. With the new design, I suggest firstly parse , if the value contains folder path, use the specified path, if not, use same path as "file=" value, and if "file=" is not set, use output stream. (The reason I prefer to use same path as "file=" is I assume that users prefer to save all data file under the same folder.) > It needs to be clearly specified. > What statements do you suggest? > > One idea of simplification is to get rid of the default > and to require it to be always specified (non-optional). > > Then we could replace this: > file= dump data to > incremental dump support: > incremental[:] enable incremental dump, data will be dumped > to (default is "IncrementalHisto.dump") > > with this: > file= dump data to > incremental= dump incremental data to I think having a default IncrementalHisto.dump file saved at the same path of the is a way to make incremental easy to use. IMHO, when user use jmap -histo with "file=?, and want to enable inremental histo, the easiest way is just use "-incremental" flag and all data files will be saved under the same folder of . They don?t have to consider the specific filename for incremental additionally. This is the reason I set default value of IncrementalHisto.dump. But I also want the user to have freedom to use different filename and path for incremental results, so I make it optional for incremental file_name. If we can make it non-optional, does it mean that user may have following command: Jmap -histo,file=,incremental: pid It seems a little bit complicated to me, what do you think? > > - chunksize=, size of objects (in KB) will be dumped in one chunk. > > Q2: Should it be chunk of dump, not chunk of objects? The purpose of "chunksize" is to decide how many objects' info are dumped at once. for example use "chunksize=1" on a "Xmx1m", there will be at max 1MB/1KB = 1000 chunks, which indicates that there will be 1000 times of file writing when do "jmap -histo". > I hardly understand the point to know max of objects that can be dumped at once. > It is more important to know how much memory in the file it is going to take. > How much of dump memory will take one object? > Does it vary (does it depend on object types)? Yes, the dump memory for one object varies from size and types. The option?chunksize? is for user to control the proportion of heap that the incremental dump can process at a time. IMO the use scenario is as following: when the JVM have an 180GB max heap size, and jmap histo used with chunksize=1g, it means the incremental dump happens when every 1GB heap is scaned, so it does?t has too much incremenal dump, because the incremental dump takes time and may cause jmap -histo work slower. PS, I think we should support ?g?,?m? and ?k? instead of using ?KB? , do you agree? > > - maxfilesize=, size of the incremental data dump file (in KB), when data size > > is larger than maxfilesize, the file is erased and latest data will be written. > Q3: What is a relation and limitations between chunksize and maxfilesize? > Should the maxfilesize be multiple of the chunksize? > The question Q3 above was not unanswered. > But never mind. Please, see the suggestion below. If the chunksize it large, and there are too much objects of different classes in heap, the actual filesize can be larger than the maxfilesize. But I believe this is raraly happened because the size of one class?s histo info only takes several bytes in the final result, and from the implementation of jmap, it can find out all loaded classes before doing heap iteration, so the different of result only happens on the object quantity. > Q4: The sentence "the file is erased and latest data will be written" is not clear enough. > Why the whole file needs to be erased > Should the incremental file behave like a cyclic buffer? > If so, then only next chunk needs to be erased. > Then the chunks need to be numbered in order, so the earliest one can be found. The "maxfilesize" controls the file size not to be too large, so when the dumped data is larger than "maxfilesize", the file is erased and latest data are written.The reason I erase whole file is that chunk data is accumulative, so the latest data includes the previous statistical ones. And this way may make the file easy to read. I agree that we can add ordered number in chunks, I think it more or less help user to get to know how object distributed in heap. I think maybe it is reasonable to have the incremental file behave like gclog, when maxfilesize is reached, the file is renamed with numbered suffix, and new file is created to use. so there can be IncrementalHisto.dump.0 and IncrementalHisto.dump.1 etc for large heap. what do you think? > I think, it is not a bad idea. > In general, new incremental feature design does not look simple and clear enough. > It feels like another step of simplification is needed. > What about to get rid of the maxfilesize option? > Then each chunk can be recorded to a separate file IncrementalHisto.dump.. > A couple of questions to clarify: > - Do want all chunks or just the latest chunk to be saved? I think usually it is not required to save all chunks. The chunk is incremental, so the new one contains all info that old ones have. But having old chunks may help user to know how object is distributed , because one chunk is a fixed proportion of heap, so the different between to a chunk and it?s predecessor can tell the object distribution of the newly scanned portion of heap. The question is do you think these info is necessary? If not, I agree we can get rid of the maxfilesize. > - If we save all chunks then what is the point to have the full dump recorded as well? IMO, the incremental histo solves two problems: <1> The jmap histo may stuck if heap is large, so it is useful if we can get intermediate result. <2> incremental info may help user know object distribution of some portion of the heap. And I agree that if full dump is successfully gotten, the chunks became less useful. > The advantages of this approach is that there is no need to describe: > - relationship between chunksize and maxfilesize > - recording behavior for multiple chunks in the incremental file > - what chunks have been recorded into the incremental I agree that maxfilesize may not be useful because the histo data of chunks are usually not large. And it sounds good to me that we save chunk data in seperate files named IncrementalHisto.dump.. So the problem is how much chunks do you think we need to save? I think the latest chunk is a must, and maybe the previous 3-5 ones? > But again, this still needs to be clearly specified. > It would be nice to reach a consensus on a design first. Totally agree :) > Thanks, > Serguei Again, Thanks for your comments BRs, Lin Thanks, Lin ________________________________________ From: serguei.spitsyn at oracle.com Sent: Saturday, May 11, 2019 2:17:41 AM To: ??; Hohensee, Paul; JC Beyler Cc: serviceability-dev at openjdk.java.net Subject: Re: [RFR]8215623: Add incremental dump for jmap histo Dear Lin, Sorry for the late reply. I've edited the CSR a little bit to fix some incorrect spots. Now, a couple of spots are not clear to me. > - incremental[:], enable the incremental dump of heap, dumped > data will be saved to, by default it is "IncrementalHisto.dump" Q1: Should the be full path or short name? Is there any default path? What is the path of the "IncrementalHisto.dump" file? > - chunksize=, size of objects (in KB) will be dumped in one chunk. Q2: Should it be chunk of dump, not chunk of objects? > - maxfilesize=, size of the incremental data dump file (in KB), when data size > is larger than maxfilesize, the file is erased and latest data will be written. Q3: What is a relation and limitations between chunksize and maxfilesize? Should the maxfilesize be multiple of the chunksize? Q4: The sentence "the file is erased and latest data will be written" is not clear enough. Why the whole file needs to be erased Should the incremental file behave like a cyclic buffer? If so, then only next chunk needs to be erased. Then the chunks need to be numbered in order, so the earliest one can be found. (I do not want you to accept my suggestions right away. It is just a discussion point. You need to prove that your approach is good and clean enough.) If we resolve the questions (or get into agreement) then I'll update the CSR as needed. Thanks, Serguei On 5/5/19 00:34, ?? wrote: Dear All, I have updated the CSR at https://bugs.openjdk.java.net/browse/JDK-8222319 May I ask your help to review it? When it is finalized, I will refine the webrev. BRs, Lin Dear Serguei? Thanks a lot for your reviewing. System.err.println(" incremental dump support:"); + System.err.println(" chunkcount= object number counted (in Kilo) to trigger incremental dump"); + System.err.println(" maxfilesize= size limit of incremental dump file (in KB)"); From this description is not clear at all what does the chunkcount mean. Is it to define how many heap objects are dumped in one chunk? If so, would it better to name it chunksize instead where chunksize is measured in heap objects? Then would it better to use the same units to define the maxfilesize as well? (I'm not insisting on this, just asking.) The original meaning of ?chunkcount" is how many objects are dumped in one chunk, and the ?maxfilesize? is the limited size of the dump file. For example, ?chunkcount=1, maxfilesize=10? means that intermediated data will be written to the dump file for every 1000 objects, and when the dump file is larger than 10k?erase the file and rewrite it with the latest dumped data. The reason I didn?t use object count to control the dump file size is that there can be humongous object, which may cause the file too large. Do you think use object size instead of chunkcount is a good option? So the two options can be with same units. BRs, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Mon May 20 15:24:55 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 May 2019 08:24:55 -0700 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: Build changes look good. /Erik On 2019-05-19 17:43, David Holmes wrote: > Hi Daniil, > > cc: Boris and Erik J. > > On 20/05/2019 7:12 am, Daniil Titov wrote: >> Please review the change that fixes the failure of >> sun/management/jmxremote/bootstrap JMX tests on Windows platform.? >> While running, these tests invoke revokeall.exe utility and this >> utility hangs. >> >> The problem here is that invokeall.exe goes into an endless loop? >> while iterating over Access Control Entries (ACE) for a given file if >> it encounters at least one ACE with the type different from >> ACCESS_ALLOWED_ACE_TYPE. >> >> The change fixes this problem.? It also removes revokeall.exe binary >> from the repository and changes the makefile? to get it built instead. >> >> Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap? >> tests succeeded? in Mach5. >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8214545 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > I knew this seemed very familiar ... Boris had a fix for this a few > weeks ago under JDK-8220581. Similar but not identical to yours - see > below. Though getting rid of the exe from the repo is a good idea > (thanks Erik!). > > A few comments > > test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > > Pre-existing: > > !???????? REVOKEALL="$TESTNATIVEPATH/revokeall.exe" > ????????? if [ ! -f "$REVOKEALL" ] ; then > > I would expect a -x test not -f. > > --- > > test/jdk/sun/management/windows/README > > The first copyright year should be 2004. > > ? 25 This directory contains the source and the binary version > > Delete "and the binary version". > > --- > > test/jdk/sun/management/windows/exerevokeall.c > > Pre-existing: > > ?31? * file - suitable for NT/2000/XP only. > > Please delete everything after "file". > > > ?355???????????? i++; > ?356???????????? count--; > > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic > but i is only incremented under very specific conditions. If you > rewrote the code to avoid the use of the continue then i would not be > modified except where it currently is. > > Thanks, > David > ----- > >> Thanks! >> --Daniil >> >> From martin.doerr at sap.com Mon May 20 15:32:21 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 20 May 2019 15:32:21 +0000 Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace Message-ID: Hi, please review my change which allows usage of AsyncGetCallTrace on PPC64 and s390. Webrev: http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webrev.00/ Bug with more background information: https://bugs.openjdk.java.net/browse/JDK-8224230 Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Mon May 20 15:35:52 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 May 2019 15:35:52 +0000 Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace In-Reply-To: References: Message-ID: Hi Martin, the changes look good. Please fix this comment: // Forte Analyzer AsyncGetCallTrace profiling support is not implemented on Linux/S390x. I guess it's no more true. No new webrev needed. Did you verify that the test works, or did you also try async with the VM on ppc? Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 20. Mai 2019 17:32 > To: serviceability-dev at openjdk.java.net; JC Beyler ; > Volker Simonis (volker.simonis at gmail.com) ; > Lindenmaier, Goetz > Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > Hi, > > > > please review my change which allows usage of AsyncGetCallTrace on PPC64 > and s390. > > > > Webrev: > > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > ev.00/ > > > > Bug with more background information: > > https://bugs.openjdk.java.net/browse/JDK-8224230 > > > > Best regards, > > Martin > > From martin.doerr at sap.com Mon May 20 15:48:49 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 20 May 2019 15:48:49 +0000 Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace In-Reply-To: References: Message-ID: Hi G?tz, thanks for reviewing it so quickly. Thanks for pointing me to the obsolete comment. I've also fixed in on PPC64 and also removed a redundant assertion on PPC64: http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webrev.01/ I haven't used async profiler, but I've ran JTREG tests for hotspot runtime on linux PPC64 (Big and Little Endian) and s390 and all ones have passed. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 20. Mai 2019 17:36 To: Doerr, Martin ; serviceability-dev at openjdk.java.net; JC Beyler ; Volker Simonis (volker.simonis at gmail.com) Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace Hi Martin, the changes look good. Please fix this comment: // Forte Analyzer AsyncGetCallTrace profiling support is not implemented on Linux/S390x. I guess it's no more true. No new webrev needed. Did you verify that the test works, or did you also try async with the VM on ppc? Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 20. Mai 2019 17:32 > To: serviceability-dev at openjdk.java.net; JC Beyler ; > Volker Simonis (volker.simonis at gmail.com) ; > Lindenmaier, Goetz > Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > Hi, > > > > please review my change which allows usage of AsyncGetCallTrace on PPC64 > and s390. > > > > Webrev: > > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > ev.00/ > > > > Bug with more background information: > > https://bugs.openjdk.java.net/browse/JDK-8224230 > > > > Best regards, > > Martin > > From goetz.lindenmaier at sap.com Mon May 20 15:55:57 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 May 2019 15:55:57 +0000 Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace In-Reply-To: References: Message-ID: LGTM Goetz! > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 20. Mai 2019 17:49 > To: Lindenmaier, Goetz ; serviceability- > dev at openjdk.java.net; JC Beyler ; Volker Simonis > (volker.simonis at gmail.com) > Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > Hi G?tz, > > thanks for reviewing it so quickly. > > Thanks for pointing me to the obsolete comment. I've also fixed in on PPC64 > and also removed a redundant assertion on PPC64: > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > ev.01/ > > I haven't used async profiler, but I've ran JTREG tests for hotspot runtime on > linux PPC64 (Big and Little Endian) and s390 and all ones have passed. > > Best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 20. Mai 2019 17:36 > To: Doerr, Martin ; serviceability- > dev at openjdk.java.net; JC Beyler ; Volker Simonis > (volker.simonis at gmail.com) > Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > Hi Martin, > > the changes look good. > > Please fix this comment: > // Forte Analyzer AsyncGetCallTrace profiling support is not implemented on > Linux/S390x. > I guess it's no more true. No new webrev needed. > > Did you verify that the test works, or did you also try > async with the VM on ppc? > > Best regards, > Goetz. > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Montag, 20. Mai 2019 17:32 > > To: serviceability-dev at openjdk.java.net; JC Beyler ; > > Volker Simonis (volker.simonis at gmail.com) ; > > Lindenmaier, Goetz > > Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > > > Hi, > > > > > > > > please review my change which allows usage of AsyncGetCallTrace on PPC64 > > and s390. > > > > > > > > Webrev: > > > > > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > > ev.00/ > > > > > > > > Bug with more background information: > > > > https://bugs.openjdk.java.net/browse/JDK-8224230 > > > > > > > > Best regards, > > > > Martin > > > > From jcbeyler at google.com Mon May 20 16:34:14 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 20 May 2019 09:34:14 -0700 Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace In-Reply-To: References: Message-ID: Hi Martin, Looks good to me too :) Jc On Mon, May 20, 2019 at 8:56 AM Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > LGTM > Goetz! > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Montag, 20. Mai 2019 17:49 > > To: Lindenmaier, Goetz ; serviceability- > > dev at openjdk.java.net; JC Beyler ; Volker Simonis > > (volker.simonis at gmail.com) > > Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > > > Hi G?tz, > > > > thanks for reviewing it so quickly. > > > > Thanks for pointing me to the obsolete comment. I've also fixed in on > PPC64 > > and also removed a redundant assertion on PPC64: > > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > > ev.01/ > > > > I haven't used async profiler, but I've ran JTREG tests for hotspot > runtime on > > linux PPC64 (Big and Little Endian) and s390 and all ones have passed. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Montag, 20. Mai 2019 17:36 > > To: Doerr, Martin ; serviceability- > > dev at openjdk.java.net; JC Beyler ; Volker Simonis > > (volker.simonis at gmail.com) > > Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > > > Hi Martin, > > > > the changes look good. > > > > Please fix this comment: > > // Forte Analyzer AsyncGetCallTrace profiling support is not > implemented on > > Linux/S390x. > > I guess it's no more true. No new webrev needed. > > > > Did you verify that the test works, or did you also try > > async with the VM on ppc? > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: Doerr, Martin > > > Sent: Montag, 20. Mai 2019 17:32 > > > To: serviceability-dev at openjdk.java.net; JC Beyler < > jcbeyler at google.com>; > > > Volker Simonis (volker.simonis at gmail.com) ; > > > Lindenmaier, Goetz > > > Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > > > > > Hi, > > > > > > > > > > > > please review my change which allows usage of AsyncGetCallTrace on > PPC64 > > > and s390. > > > > > > > > > > > > Webrev: > > > > > > > > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > > > ev.00/ > > > > > > > > > > > > Bug with more background information: > > > > > > https://bugs.openjdk.java.net/browse/JDK-8224230 > > > > > > > > > > > > Best regards, > > > > > > Martin > > > > > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Mon May 20 16:37:56 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 20 May 2019 16:37:56 +0000 Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace In-Reply-To: References: Message-ID: Hi G?tz and JC, thanks for reviewing. Best regards, Martin From: Jean Christophe Beyler Sent: Montag, 20. Mai 2019 18:34 To: Lindenmaier, Goetz Cc: Doerr, Martin ; serviceability-dev at openjdk.java.net; Volker Simonis (volker.simonis at gmail.com) Subject: Re: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace Hi Martin, Looks good to me too :) Jc On Mon, May 20, 2019 at 8:56 AM Lindenmaier, Goetz > wrote: LGTM Goetz! > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 20. Mai 2019 17:49 > To: Lindenmaier, Goetz >; serviceability- > dev at openjdk.java.net; JC Beyler >; Volker Simonis > (volker.simonis at gmail.com) > > Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > Hi G?tz, > > thanks for reviewing it so quickly. > > Thanks for pointing me to the obsolete comment. I've also fixed in on PPC64 > and also removed a redundant assertion on PPC64: > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > ev.01/ > > I haven't used async profiler, but I've ran JTREG tests for hotspot runtime on > linux PPC64 (Big and Little Endian) and s390 and all ones have passed. > > Best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 20. Mai 2019 17:36 > To: Doerr, Martin >; serviceability- > dev at openjdk.java.net; JC Beyler >; Volker Simonis > (volker.simonis at gmail.com) > > Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > Hi Martin, > > the changes look good. > > Please fix this comment: > // Forte Analyzer AsyncGetCallTrace profiling support is not implemented on > Linux/S390x. > I guess it's no more true. No new webrev needed. > > Did you verify that the test works, or did you also try > async with the VM on ppc? > > Best regards, > Goetz. > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Montag, 20. Mai 2019 17:32 > > To: serviceability-dev at openjdk.java.net; JC Beyler >; > > Volker Simonis (volker.simonis at gmail.com) >; > > Lindenmaier, Goetz > > > Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > > > Hi, > > > > > > > > please review my change which allows usage of AsyncGetCallTrace on PPC64 > > and s390. > > > > > > > > Webrev: > > > > > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > > ev.00/ > > > > > > > > Bug with more background information: > > > > https://bugs.openjdk.java.net/browse/JDK-8224230 > > > > > > > > Best regards, > > > > Martin > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon May 20 18:07:29 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 11:07:29 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent Message-ID: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Mon May 20 18:20:23 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 20 May 2019 14:20:23 -0400 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Message-ID: On 5/14/19 10:02 AM, Robbin Ehn wrote: > Hi Dan, > > Full: > http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html > Inc: > http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/DeadlockDetector.java ??? L2:? * Copyright (c) 2004, 20019, Oracle and/or its affiliates. All rights reserved. ??????? Typo - s/20019/2019/ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ??? L136: ??????????????? writeJavaThread(jt, i+1); ??????? formatting: s/i+1/i + 1/ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaVM.java ??? L2:? * Copyright (c) 2004, 20019, Oracle and/or its affiliates. All rights reserved. ??????? Typo - s/20019/2019/ Thumbs up! I don't need to see a new webrev for the above nits. I took a quick pass thru: > http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html and nothing jumped out at me... Dan > > On 2019-05-08 18:02, Daniel D. Daugherty wrote: >> General comment - Please make sure to update all copyright years before >> ?????????????????? pushing this changeset. > > Fixed. > >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java >> ???? L46: >> ???? L47: ??? private static AddressField????? threadsField; >> ???? L48: ??? private static CIntegerField???? lengthField; >> ???????? nit - please delete blank line on L46 >> ???????? nit - please reduce the space between type and variable names >> ?????????????? (I have no preference if you still keep them aligned) >> >> ???? nit - Please delete blank line on L74. > > Fixed. > > >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java >> ???? old L203: ????? Threads threads = VM.getVM().getThreads(); >> ???? old L204: ????? for (JavaThread cur = threads.first(); cur != >> null; cur = cur.next()) { >> ???? new L203: ????? VM.getVM().getThreads().doJavaThreads((cur) -> { >> ???????? In this case, you did a lambda conversion... >> >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java >> >> ???? old L75: ??????????? for (JavaThread cur = threads.first(); cur >> != null; cur = cur.next(), i++) { >> ???? new L75: ??????????? for (int k = 0; k < >> threads.getNumberOfThreads(); k++) { >> ???? new L76: ??????????????? JavaThread cur = >> threads.getJavaThreadAt(k); >> ???????? In this case, you didn't do a lambda conversion... >> >> ???????? I'm trying to grok a reason for the different styles... >> ???????? Update: Is is maybe a control flow thing? (No, I don't know >> much >> ??????????? about lambdas.) As in: Loops that "break" or early return >> are >> ??????????? not amenable to conversion to a lambda... (just guessing) > > I converted those where it was easy to see that the loop did not have > an early termination. Lambdas removed. > >> >> ???? L74: ??????????? int i = 1; >> ???????? Not your bug, but I think that 'i' is not used. >> > > Fixed. > >> This all looks good to me... so thumbs up! > > Thanks. > >> >> I have some reservations about using lambdas in a debugging tool. >> My personal philosophy about debugging tools is that they should >> be built on the simplest/most stable technology to reduce the >> chances of the more complicated technology failing during a debug >> session. I hate it when my debugger crashes! > > I removed all lambdas! > > Thanks for looking at this, Robbin > >> >> That said, SA is pretty much standalone so use of lambdas in this >> debugging tool shouldn't affect the JVM or core file being debugged. >> >> Again, thumbs up! >> >> Dan >> >> >>> >>> /Robbin >>> >>> On 2019-05-08 11:17, Robbin Ehn wrote: >>>> Hi David, >>>> >>>> I changed to normal for: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>>> >>>> >>>> Full: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>>> Inc: >>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>>> >>>> Passes t1-2 >>>> >>>> Thanks, Robbin >>>> >>>> >>>> On 2019-05-07 09:47, David Holmes wrote: >>>>> Hi Robbin, >>>>> >>>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>>> Hi David, >>>>>> >>>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>>> Hi Robbin, >>>>>>> >>>>>>> I have a few concerns here. >>>>>>> >>>>>>> First I can't see how you are actually integrating the SA with >>>>>>> the ThreadSMR. You've exposed the _java_thread_list for it to >>>>>>> iterate but IIRC that list can be updated when threads are >>>>>>> added/removed and I'm not seeing how the SA is left iterating a >>>>>>> valid list - we'd normally using a ThreadsListHandle for that ?? >>>>>>> (I may need a refresher on how this list is actually maintained.) >>>>>> >>>>>> The processes must be paused. If the processes would be running >>>>>> the linked list is also broken since if we unlink and delete a >>>>>> JavaThread and then later SA follows that _next pointer. >>>>> >>>>> Ah good point. Thanks for clarifying. >>>>> >>>>>>> >>>>>>> The conversion from external iteration of the list (the for >>>>>>> loop) to internal iteration (passing a lambda to JavaThreadsDo) >>>>>>> is also problematic. First I'd be very wary about introducing >>>>>>> lambda expressions into the SA code - lambda drags in a lot of >>>>>>> supporting code that could have an impact on the way SA >>>>>>> functions. There are places where we have to avoid lambdas due >>>>>>> to bootstrapping/initialization issues and I think the SA may be >>>>>>> an area where we also want to keep the code extremely simple. >>>>>> >>>>>> There are already several usages of lambdas in SA code, e.g. >>>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an >>>>>> application, there is not a bootstrap issue or so. >>>>> >>>>> Hmm okay. Lambda carries a lot of baggage. But if its already >>>>> being used ... >>>>> >>>>>>> Second by using lambda's with internal iteration you've lost the >>>>>>> ability to terminate the iteration loop! In the existing code if >>>>>>> we have a return in the for-loop then we not only terminate the >>>>>>> loop but the enclosing method. With the lambda the "return" just >>>>>>> ends the current iteration and JavaThreadsDo will then continue >>>>>>> with the next thread - so we don't even terminate the iteration >>>>>>> let alone the method performing the iteration. So for places >>>>>>> were we want to process one thread, for example, we will >>>>>>> continue to iterate all remaining threads and just do nothing >>>>>>> with them. That's very inefficient. >>>>>> >>>>>> That's why I only used the internal iteration where we didn't >>>>>> have early returns. >>>>> >>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>>> - original code: >>>>> >>>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>>> 1557???????????? public void doit(Tokens t) { >>>>> ... >>>>> 1564???????????????????? for (JavaThread thread = threads.first(); >>>>> thread != null; thread = thread.next()) { >>>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>>> ByteArrayOutputStream(); >>>>> 1566???????????????????????? thread.printThreadIDOn(new >>>>> PrintStream(bos)); >>>>> 1567???????????????????????? if (all || >>>>> bos.toString().equals(name)) { >>>>> 1568???????????????????????????? out.println("Thread " + >>>>> bos.toString() + " Address: " + thread.getAddress()); >>>>> ... >>>>> 1577???????????????????????????? } >>>>> 1578???????????????????????????? if (!all) return; >>>>> >>>>> That looks like an early return to me. >>>>> >>>>> Cheers, >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> Thanks, Robbin >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>>> Hi, please review. >>>>>>>> >>>>>>>> Old threads linked list remove and updated SA to use >>>>>>>> ThreadsList array instead. >>>>>>>> >>>>>>>> Issue: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>>> >>>>>>>> Passes t1-3 (which includes SA tests). >>>>>>>> >>>>>>>> Thanks, Robbin >> From jcbeyler at google.com Mon May 20 19:38:13 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 20 May 2019 12:38:13 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> Message-ID: Hi Serguei, LGTM :) Jc On Mon, May 20, 2019 at 11:08 AM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Please, review a fix for enhancement: > https://bugs.openjdk.java.net/browse/JDK-8046018 > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223915 > > Webrev: > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ > > > Summary: > > Ps: I am imagining you meant consistent and not inconsistent below ;-) > The fix is to make the JVMTI can_redefine_any_class capability spec more > inconsistent. > It is just about a couple of lines. > > Thanks, > Serguei > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon May 20 19:58:26 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 12:58:26 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> Message-ID: <97003fac-238e-a130-7780-068300b70b4c@oracle.com> An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Mon May 20 20:19:45 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 20 May 2019 13:19:45 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Mon May 20 20:38:20 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 13:38:20 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> Message-ID: <00059983-9cbe-19f1-9694-d0a466bb1a7b@oracle.com> Hi Chris, On 5/20/19 13:19, Chris Plummer wrote: > Hi Serguei, > > Looks good. Thanks a lot! > I think you should make a minor change in the comment: "It tells now" > should be "It now says". Okay, thanks. > Also, your summary comment below says "inconsistent" instead of > "consistent". Good catch! > You should fix that in your commit comment. Fixed in place. Thanks, Serguei > > thanks, > > Chris > > On 5/20/19 11:07 AM, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8046018 >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223915 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >> >> >> Summary: >> >> ? The fix is to make the JVMTI can_redefine_any_class capability spec >> more inconsistent. >> ? It is just about a couple of lines. >> >> Thanks, >> Serguei > > From serguei.spitsyn at oracle.com Tue May 21 00:43:22 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 17:43:22 -0700 Subject: RFR (XS): 8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module Message-ID: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue May 21 00:58:50 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 20 May 2019 17:58:50 -0700 Subject: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: <0eebc323-7c82-2a7c-0d3d-ae5488394bf2@oracle.com> References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> <0eebc323-7c82-2a7c-0d3d-ae5488394bf2@oracle.com> Message-ID: Hi Alan, I think it makes sense to put the work for replacing revokeall.exe utility with a Java code in a separate issue since the current issue is a quite urgent. I created a new issue for that https://bugs.openjdk.java.net/browse/JDK-8224255 Thanks! --Daniil ?On 5/19/19, 11:04 PM, "Alan Bateman" wrote: On 19/05/2019 22:12, Daniil Titov wrote: > Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. > > The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. > > The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. > > Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 Have you looked at replacing the tool with code that uses the java.nio.file API? You can edit ACLs with that API. -Alan From daniil.x.titov at oracle.com Tue May 21 01:02:37 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 20 May 2019 18:02:37 -0700 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: <7929DFDE-28D1-4891-A8B9-D314D20E3CDD@oracle.com> Please review a new version of the fix that includes the changes David suggested. > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic We need to increment i on line 354: 353 if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != ACCESS_ALLOWED_ACE_TYPE) { 354 i++; 355 count--; 356 continue; 357 } since the code iterates over all ACE entries for a given file and deletes ones that grant non-owner access to the file. i is the index of the current ACE entry in the ACL structure. The current ACE entry is retrieved at the beginning of the loop: 349 if (!GetAce(acl, i, &ace)) { and the index is always incremented at the end of the loop unless the current entry is deleted. 382 if (!deleted) { 383 str = getSIDString(sid); 384 if (str != NULL) { 385 printf("ALLOW %s (access mask=%x)\n", str, access->Mask); 386 free(str); 387 } 388 389 /* onto the next ACE */ 390 i++; 391 } 392 count--; I also created a new issue to replace revokeall.exe with Java code as Alan suggested : https://bugs.openjdk.java.net/browse/JDK-8224255 Webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.02 Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 Thanks! --Daniil ?On 5/19/19, 5:43 PM, "David Holmes" wrote: Hi Daniil, cc: Boris and Erik J. On 20/05/2019 7:12 am, Daniil Titov wrote: > Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. > > The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. > > The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. > > Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 I knew this seemed very familiar ... Boris had a fix for this a few weeks ago under JDK-8220581. Similar but not identical to yours - see below. Though getting rid of the exe from the repo is a good idea (thanks Erik!). A few comments test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh Pre-existing: ! REVOKEALL="$TESTNATIVEPATH/revokeall.exe" if [ ! -f "$REVOKEALL" ] ; then I would expect a -x test not -f. --- test/jdk/sun/management/windows/README The first copyright year should be 2004. 25 This directory contains the source and the binary version Delete "and the binary version". --- test/jdk/sun/management/windows/exerevokeall.c Pre-existing: 31 * file - suitable for NT/2000/XP only. Please delete everything after "file". 355 i++; 356 count--; The count-- is obvious as it is the loop counter, but it is far from clear to me that i++ is correct. I don't fully understand the logic but i is only incremented under very specific conditions. If you rewrote the code to avoid the use of the continue then i would not be modified except where it currently is. Thanks, David ----- > Thanks! > --Daniil > > From alexey.menkov at oracle.com Tue May 21 01:15:04 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Mon, 20 May 2019 18:15:04 -0700 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: <7929DFDE-28D1-4891-A8B9-D314D20E3CDD@oracle.com> References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> <7929DFDE-28D1-4891-A8B9-D314D20E3CDD@oracle.com> Message-ID: <22f24d90-2677-9686-f68c-700e84edf333@oracle.com> LGTM --alex On 05/20/2019 18:02, Daniil Titov wrote: > Please review a new version of the fix that includes the changes David suggested. > > > The count-- is obvious as it is the loop counter, but it is far from > > clear to me that i++ is correct. I don't fully understand the logic > > We need to increment i on line 354: > > 353 if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != ACCESS_ALLOWED_ACE_TYPE) { > 354 i++; > 355 count--; > 356 continue; > 357 } > > since the code iterates over all ACE entries for a given file and deletes ones that grant non-owner access to the file. i is the index of the current ACE entry > in the ACL structure. The current ACE entry is retrieved at the beginning of the loop: > > 349 if (!GetAce(acl, i, &ace)) { > > > and the index is always incremented at the end of the loop unless the current entry is deleted. > > 382 if (!deleted) { > 383 str = getSIDString(sid); > 384 if (str != NULL) { > 385 printf("ALLOW %s (access mask=%x)\n", str, access->Mask); > 386 free(str); > 387 } > 388 > 389 /* onto the next ACE */ > 390 i++; > 391 } > 392 count--; > > > I also created a new issue to replace revokeall.exe with Java code as Alan suggested : https://bugs.openjdk.java.net/browse/JDK-8224255 > > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > Thanks! > --Daniil > > > ?On 5/19/19, 5:43 PM, "David Holmes" wrote: > > Hi Daniil, > > cc: Boris and Erik J. > > On 20/05/2019 7:12 am, Daniil Titov wrote: > > Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. > > > > The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. > > > > The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. > > > > Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > I knew this seemed very familiar ... Boris had a fix for this a few > weeks ago under JDK-8220581. Similar but not identical to yours - see > below. Though getting rid of the exe from the repo is a good idea > (thanks Erik!). > > A few comments > > test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > > Pre-existing: > > ! REVOKEALL="$TESTNATIVEPATH/revokeall.exe" > if [ ! -f "$REVOKEALL" ] ; then > > I would expect a -x test not -f. > > --- > > test/jdk/sun/management/windows/README > > The first copyright year should be 2004. > > 25 This directory contains the source and the binary version > > Delete "and the binary version". > > --- > > test/jdk/sun/management/windows/exerevokeall.c > > Pre-existing: > > 31 * file - suitable for NT/2000/XP only. > > Please delete everything after "file". > > > 355 i++; > 356 count--; > > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic but > i is only incremented under very specific conditions. If you rewrote the > code to avoid the use of the continue then i would not be modified > except where it currently is. > > Thanks, > David > ----- > > > Thanks! > > --Daniil > > > > > > > From jcbeyler at google.com Tue May 21 01:41:41 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Mon, 20 May 2019 18:41:41 -0700 Subject: RFR (XS): 8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> References: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> Message-ID: LGTM Serguei :) Jc On Mon, May 20, 2019 at 5:44 PM serguei.spitsyn at oracle.com < serguei.spitsyn at oracle.com> wrote: > Please, review a fix for java.lang.instrument.Instrumentation spec update: > https://bugs.openjdk.java.net/browse/JDK-8183273 > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223740 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8183273-Instr-note.1/ > > > Summary: > A clarification note is added to the > https://bugs.openjdk.java.net/browse/JDK-8223740. > > Thanks, > Serguei > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 21 02:01:26 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 19:01:26 -0700 Subject: RFR (XS): 8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: References: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From daniil.x.titov at oracle.com Tue May 21 03:25:00 2019 From: daniil.x.titov at oracle.com (Daniil Titov) Date: Mon, 20 May 2019 20:25:00 -0700 Subject: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: Please review un updated version of the previous change that also removes unnecessary line chmod ug+x $REVOKEALL from test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh Webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.03 Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 Thanks! --Daniil ?On 5/20/19, 6:02 PM, "serviceability-dev on behalf of Daniil Titov" wrote: Please review a new version of the fix that includes the changes David suggested. > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic We need to increment i on line 354: 353 if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != ACCESS_ALLOWED_ACE_TYPE) { 354 i++; 355 count--; 356 continue; 357 } since the code iterates over all ACE entries for a given file and deletes ones that grant non-owner access to the file. i is the index of the current ACE entry in the ACL structure. The current ACE entry is retrieved at the beginning of the loop: 349 if (!GetAce(acl, i, &ace)) { and the index is always incremented at the end of the loop unless the current entry is deleted. 382 if (!deleted) { 383 str = getSIDString(sid); 384 if (str != NULL) { 385 printf("ALLOW %s (access mask=%x)\n", str, access->Mask); 386 free(str); 387 } 388 389 /* onto the next ACE */ 390 i++; 391 } 392 count--; I also created a new issue to replace revokeall.exe with Java code as Alan suggested : https://bugs.openjdk.java.net/browse/JDK-8224255 Webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.02 Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 Thanks! --Daniil ?On 5/19/19, 5:43 PM, "David Holmes" wrote: Hi Daniil, cc: Boris and Erik J. On 20/05/2019 7:12 am, Daniil Titov wrote: > Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. > > The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. > > The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. > > Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 I knew this seemed very familiar ... Boris had a fix for this a few weeks ago under JDK-8220581. Similar but not identical to yours - see below. Though getting rid of the exe from the repo is a good idea (thanks Erik!). A few comments test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh Pre-existing: ! REVOKEALL="$TESTNATIVEPATH/revokeall.exe" if [ ! -f "$REVOKEALL" ] ; then I would expect a -x test not -f. --- test/jdk/sun/management/windows/README The first copyright year should be 2004. 25 This directory contains the source and the binary version Delete "and the binary version". --- test/jdk/sun/management/windows/exerevokeall.c Pre-existing: 31 * file - suitable for NT/2000/XP only. Please delete everything after "file". 355 i++; 356 count--; The count-- is obvious as it is the loop counter, but it is far from clear to me that i++ is correct. I don't fully understand the logic but i is only incremented under very specific conditions. If you rewrote the code to avoid the use of the continue then i would not be modified except where it currently is. Thanks, David ----- > Thanks! > --Daniil > > From david.holmes at oracle.com Tue May 21 03:53:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 13:53:12 +1000 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> Message-ID: Hi Serguei, On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: > Please, review a fix for enhancement: > https://bugs.openjdk.java.net/browse/JDK-8046018 > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223915 I have some comments on the CSR and about this change overall as to me it is not a simple clarification at all, but potentially a significant change in the meaning of the capability. > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ You introduced a typo: modifialble Assuming this proceeds a similar change is needed earlier: 7444 7445 If possessed then all classes (except primitive, array, and some implementation defined 7446 classes) are modifiable (redefine or retransform). Thanks, David ----- > > Summary: > > ? The fix is to make the JVMTI can_redefine_any_class capability spec > more inconsistent. > ? It is just about a couple of lines. > > Thanks, > Serguei From david.holmes at oracle.com Tue May 21 03:54:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 13:54:52 +1000 Subject: RFR (XS): 8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> References: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> Message-ID: Looks good! Thanks, David On 21/05/2019 10:43 am, serguei.spitsyn at oracle.com wrote: > Please, review a fix for java.lang.instrument.Instrumentation spec update: > https://bugs.openjdk.java.net/browse/JDK-8183273 > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223740 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8183273-Instr-note.1/ > > > Summary: > ? A clarification note is added to the > https://bugs.openjdk.java.net/browse/JDK-8223740. > > Thanks, > Serguei From serguei.spitsyn at oracle.com Tue May 21 03:54:57 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 20:54:57 -0700 Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 21 03:57:59 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 20:57:59 -0700 Subject: RFR (XS): 8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: References: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> Message-ID: <630b4b25-7eee-bdc1-4c21-6c2a75c02214@oracle.com> Thanks a lot, David! Serguei On 5/20/19 20:54, David Holmes wrote: > Looks good! > > Thanks, > David > > On 21/05/2019 10:43 am, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for java.lang.instrument.Instrumentation spec >> update: >> https://bugs.openjdk.java.net/browse/JDK-8183273 >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223740 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8183273-Instr-note.1/ >> >> >> Summary: >> ?? A clarification note is added to the >> https://bugs.openjdk.java.net/browse/JDK-8223740. >> >> Thanks, >> Serguei From david.holmes at oracle.com Tue May 21 04:02:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 14:02:29 +1000 Subject: RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: <7929DFDE-28D1-4891-A8B9-D314D20E3CDD@oracle.com> References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> <7929DFDE-28D1-4891-A8B9-D314D20E3CDD@oracle.com> Message-ID: Hi Daniil, I realize now that the test for -f rather than -x was likely because in the source bundle the exe file couldn't actually have the execute permission. So -f was correct then while -x should I hope be correct now. In which case you should be able to get rid of: chmod ug+x $REVOKEALL as well. But we'd need to be sure the execute bit is kept on the binary after its built and shipped around to other test machines. If in doubt restore the -f. Otherwise the updates look good. Thanks, David On 21/05/2019 11:02 am, Daniil Titov wrote: > Please review a new version of the fix that includes the changes David suggested. > > > The count-- is obvious as it is the loop counter, but it is far from > > clear to me that i++ is correct. I don't fully understand the logic > > We need to increment i on line 354: > > 353 if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != ACCESS_ALLOWED_ACE_TYPE) { > 354 i++; > 355 count--; > 356 continue; > 357 } > > since the code iterates over all ACE entries for a given file and deletes ones that grant non-owner access to the file. i is the index of the current ACE entry > in the ACL structure. The current ACE entry is retrieved at the beginning of the loop: > > 349 if (!GetAce(acl, i, &ace)) { > > > and the index is always incremented at the end of the loop unless the current entry is deleted. > > 382 if (!deleted) { > 383 str = getSIDString(sid); > 384 if (str != NULL) { > 385 printf("ALLOW %s (access mask=%x)\n", str, access->Mask); > 386 free(str); > 387 } > 388 > 389 /* onto the next ACE */ > 390 i++; > 391 } > 392 count--; > > > I also created a new issue to replace revokeall.exe with Java code as Alan suggested : https://bugs.openjdk.java.net/browse/JDK-8224255 > > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > Thanks! > --Daniil > > > ?On 5/19/19, 5:43 PM, "David Holmes" wrote: > > Hi Daniil, > > cc: Boris and Erik J. > > On 20/05/2019 7:12 am, Daniil Titov wrote: > > Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. > > > > The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. > > > > The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. > > > > Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > I knew this seemed very familiar ... Boris had a fix for this a few > weeks ago under JDK-8220581. Similar but not identical to yours - see > below. Though getting rid of the exe from the repo is a good idea > (thanks Erik!). > > A few comments > > test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > > Pre-existing: > > ! REVOKEALL="$TESTNATIVEPATH/revokeall.exe" > if [ ! -f "$REVOKEALL" ] ; then > > I would expect a -x test not -f. > > --- > > test/jdk/sun/management/windows/README > > The first copyright year should be 2004. > > 25 This directory contains the source and the binary version > > Delete "and the binary version". > > --- > > test/jdk/sun/management/windows/exerevokeall.c > > Pre-existing: > > 31 * file - suitable for NT/2000/XP only. > > Please delete everything after "file". > > > 355 i++; > 356 count--; > > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic but > i is only incremented under very specific conditions. If you rewrote the > code to avoid the use of the continue then i would not be modified > except where it currently is. > > Thanks, > David > ----- > > > Thanks! > > --Daniil > > > > > > > From serguei.spitsyn at oracle.com Tue May 21 04:43:28 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 21:43:28 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> Message-ID: <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> Hi David, Thank you for looking at this! On 5/20/19 20:53, David Holmes wrote: > Hi Serguei, > > On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8046018 >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223915 > > I have some comments on the CSR and about this change overall as to me > it is not a simple clarification at all, but potentially a significant > change in the meaning of the capability. I've answered your question in the CSR with my comment. >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >> > > You introduced a typo: modifialble > > Assuming this proceeds a similar change is needed earlier: > > 7444???????? > 7445?????????? If possessed then all classes (except primitive, array, > and some implementation defined > 7446?????????? classes) are modifiable (redefine or retransform). Good catch, thanks! I've updated the webrev in place. Thanks, Serguei > > Thanks, > David > ----- > >> >> Summary: >> >> ?? The fix is to make the JVMTI can_redefine_any_class capability >> spec more inconsistent. >> ?? It is just about a couple of lines. >> >> Thanks, >> Serguei From serguei.spitsyn at oracle.com Tue May 21 06:19:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 20 May 2019 23:19:14 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> Message-ID: Hi guys, I've found one more fragment in the IsModifiableClass spec which has to be fixed. Updated webrev v2: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ Specdiff: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ Enhancement: ? https://bugs.openjdk.java.net/browse/JDK-8046018 Related CSR: ? https://bugs.openjdk.java.net/browse/JDK-8223915 Thanks, Serguei On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: > Hi David, > > Thank you for looking at this! > > > On 5/20/19 20:53, David Holmes wrote: >> Hi Serguei, >> >> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>> Please, review a fix for enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>> >>> Related CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8223915 >> >> I have some comments on the CSR and about this change overall as to >> me it is not a simple clarification at all, but potentially a >> significant change in the meaning of the capability. > > > I've answered your question in the CSR with my comment. > >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>> >> >> You introduced a typo: modifialble >> >> Assuming this proceeds a similar change is needed earlier: >> >> 7444???????? >> 7445?????????? If possessed then all classes (except primitive, >> array, and some implementation defined >> 7446?????????? classes) are modifiable (redefine or retransform). > > Good catch, thanks! > I've updated the webrev in place. > > Thanks, > Serguei > >> >> Thanks, >> David >> ----- >> >>> >>> Summary: >>> >>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>> spec more inconsistent. >>> ?? It is just about a couple of lines. >>> >>> Thanks, >>> Serguei > From david.holmes at oracle.com Tue May 21 06:20:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 16:20:02 +1000 Subject: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: Loosk good. Thanks, David On 21/05/2019 1:25 pm, Daniil Titov wrote: > Please review un updated version of the previous change that also removes unnecessary line > > chmod ug+x $REVOKEALL > > from test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.03 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > Thanks! > --Daniil > > ?On 5/20/19, 6:02 PM, "serviceability-dev on behalf of Daniil Titov" wrote: > > Please review a new version of the fix that includes the changes David suggested. > > > The count-- is obvious as it is the loop counter, but it is far from > > clear to me that i++ is correct. I don't fully understand the logic > > We need to increment i on line 354: > > 353 if (((ACCESS_ALLOWED_ACE *)ace)->Header.AceType != ACCESS_ALLOWED_ACE_TYPE) { > 354 i++; > 355 count--; > 356 continue; > 357 } > > since the code iterates over all ACE entries for a given file and deletes ones that grant non-owner access to the file. i is the index of the current ACE entry > in the ACL structure. The current ACE entry is retrieved at the beginning of the loop: > > 349 if (!GetAce(acl, i, &ace)) { > > > and the index is always incremented at the end of the loop unless the current entry is deleted. > > 382 if (!deleted) { > 383 str = getSIDString(sid); > 384 if (str != NULL) { > 385 printf("ALLOW %s (access mask=%x)\n", str, access->Mask); > 386 free(str); > 387 } > 388 > 389 /* onto the next ACE */ > 390 i++; > 391 } > 392 count--; > > > I also created a new issue to replace revokeall.exe with Java code as Alan suggested : https://bugs.openjdk.java.net/browse/JDK-8224255 > > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.02 > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > Thanks! > --Daniil > > > ?On 5/19/19, 5:43 PM, "David Holmes" wrote: > > Hi Daniil, > > cc: Boris and Erik J. > > On 20/05/2019 7:12 am, Daniil Titov wrote: > > Please review the change that fixes the failure of sun/management/jmxremote/bootstrap JMX tests on Windows platform. While running, these tests invoke revokeall.exe utility and this utility hangs. > > > > The problem here is that invokeall.exe goes into an endless loop while iterating over Access Control Entries (ACE) for a given file if it encounters at least one ACE with the type different from ACCESS_ALLOWED_ACE_TYPE. > > > > The change fixes this problem. It also removes revokeall.exe binary from the repository and changes the makefile to get it built instead. > > > > Tier1, tier2, tier3, jdk_svc, and sun/management/jmxremote/bootstrap tests succeeded in Mach5. > > > > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > > I knew this seemed very familiar ... Boris had a fix for this a few > weeks ago under JDK-8220581. Similar but not identical to yours - see > below. Though getting rid of the exe from the repo is a good idea > (thanks Erik!). > > A few comments > > test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > > Pre-existing: > > ! REVOKEALL="$TESTNATIVEPATH/revokeall.exe" > if [ ! -f "$REVOKEALL" ] ; then > > I would expect a -x test not -f. > > --- > > test/jdk/sun/management/windows/README > > The first copyright year should be 2004. > > 25 This directory contains the source and the binary version > > Delete "and the binary version". > > --- > > test/jdk/sun/management/windows/exerevokeall.c > > Pre-existing: > > 31 * file - suitable for NT/2000/XP only. > > Please delete everything after "file". > > > 355 i++; > 356 count--; > > The count-- is obvious as it is the loop counter, but it is far from > clear to me that i++ is correct. I don't fully understand the logic but > i is only incremented under very specific conditions. If you rewrote the > code to avoid the use of the continue then i would not be modified > except where it currently is. > > Thanks, > David > ----- > > > Thanks! > > --Daniil > > > > > > > > > > > From Alan.Bateman at oracle.com Tue May 21 06:59:23 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 21 May 2019 07:59:23 +0100 Subject: RFR (XS): 8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> References: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> Message-ID: <176fff08-ca7a-6d21-0943-13b4b808c94c@oracle.com> On 21/05/2019 01:43, serguei.spitsyn at oracle.com wrote: > Please, review a fix for java.lang.instrument.Instrumentation spec update: > https://bugs.openjdk.java.net/browse/JDK-8183273 > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223740 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8183273-Instr-note.1/ > Looks good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 21 07:37:43 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 May 2019 00:37:43 -0700 Subject: RFR (XS): 8183273: Clarify Instrumentation interface should not be implemented outside java.instrument module In-Reply-To: <176fff08-ca7a-6d21-0943-13b4b808c94c@oracle.com> References: <7c2adb6c-2ee1-1d14-086e-4106a4d6e16f@oracle.com> <176fff08-ca7a-6d21-0943-13b4b808c94c@oracle.com> Message-ID: <02634fd7-11ae-07c2-4384-6a945f49a4e8@oracle.com> On 5/20/19 23:59, Alan Bateman wrote: > > > On 21/05/2019 01:43, serguei.spitsyn at oracle.com wrote: >> Please, review a fix for java.lang.instrument.Instrumentation spec >> update: >> https://bugs.openjdk.java.net/browse/JDK-8183273 >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223740 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8183273-Instr-note.1/ >> > Looks good. Thanks a lot, Alan! Serguei From david.holmes at oracle.com Tue May 21 07:39:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 May 2019 17:39:14 +1000 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> Message-ID: Hi Serguei, I've updated the CSR and added myself a reviewer. This all looks good. Thanks, David On 21/05/2019 4:19 pm, serguei.spitsyn at oracle.com wrote: > Hi guys, > > I've found one more fragment in the IsModifiableClass spec which has to > be fixed. > > > Updated webrev v2: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ > > > Specdiff: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ > > > > Enhancement: > ? https://bugs.openjdk.java.net/browse/JDK-8046018 > > Related CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8223915 > > > Thanks, > Serguei > > > On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for looking at this! >> >> >> On 5/20/19 20:53, David Holmes wrote: >>> Hi Serguei, >>> >>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>> Please, review a fix for enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>> >>>> Related CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>> >>> I have some comments on the CSR and about this change overall as to >>> me it is not a simple clarification at all, but potentially a >>> significant change in the meaning of the capability. >> >> >> I've answered your question in the CSR with my comment. >> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>> >>> >>> You introduced a typo: modifialble >>> >>> Assuming this proceeds a similar change is needed earlier: >>> >>> 7444???????? >>> 7445?????????? If possessed then all classes (except primitive, >>> array, and some implementation defined >>> 7446?????????? classes) are modifiable (redefine or retransform). >> >> Good catch, thanks! >> I've updated the webrev in place. >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Summary: >>>> >>>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>>> spec more inconsistent. >>>> ?? It is just about a couple of lines. >>>> >>>> Thanks, >>>> Serguei >> > From martin.doerr at sap.com Tue May 21 07:40:17 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 21 May 2019 07:40:17 +0000 Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace In-Reply-To: References: Message-ID: Hi Serguei, thanks for the review. Best regards, Martin From: serviceability-dev On Behalf Of serguei.spitsyn at oracle.com Sent: Dienstag, 21. Mai 2019 05:55 To: Jean Christophe Beyler ; Lindenmaier, Goetz Cc: serviceability-dev at openjdk.java.net Subject: Re: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace Hi Martin, LGTM++ Thanks, Serguei On 5/20/19 09:34, Jean Christophe Beyler wrote: Hi Martin, Looks good to me too :) Jc On Mon, May 20, 2019 at 8:56 AM Lindenmaier, Goetz > wrote: LGTM Goetz! > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 20. Mai 2019 17:49 > To: Lindenmaier, Goetz >; serviceability- > dev at openjdk.java.net; JC Beyler >; Volker Simonis > (volker.simonis at gmail.com) > > Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > Hi G?tz, > > thanks for reviewing it so quickly. > > Thanks for pointing me to the obsolete comment. I've also fixed in on PPC64 > and also removed a redundant assertion on PPC64: > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > ev.01/ > > I haven't used async profiler, but I've ran JTREG tests for hotspot runtime on > linux PPC64 (Big and Little Endian) and s390 and all ones have passed. > > Best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 20. Mai 2019 17:36 > To: Doerr, Martin >; serviceability- > dev at openjdk.java.net; JC Beyler >; Volker Simonis > (volker.simonis at gmail.com) > > Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > Hi Martin, > > the changes look good. > > Please fix this comment: > // Forte Analyzer AsyncGetCallTrace profiling support is not implemented on > Linux/S390x. > I guess it's no more true. No new webrev needed. > > Did you verify that the test works, or did you also try > async with the VM on ppc? > > Best regards, > Goetz. > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Montag, 20. Mai 2019 17:32 > > To: serviceability-dev at openjdk.java.net; JC Beyler >; > > Volker Simonis (volker.simonis at gmail.com) >; > > Lindenmaier, Goetz > > > Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace > > > > Hi, > > > > > > > > please review my change which allows usage of AsyncGetCallTrace on PPC64 > > and s390. > > > > > > > > Webrev: > > > > > http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr > > ev.00/ > > > > > > > > Bug with more background information: > > > > https://bugs.openjdk.java.net/browse/JDK-8224230 > > > > > > > > Best regards, > > > > Martin > > > > -- Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Tue May 21 07:47:10 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 May 2019 00:47:10 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> Message-ID: Hi David, Thank you a lot! Serguei On 5/21/19 00:39, David Holmes wrote: > Hi Serguei, > > I've updated the CSR and added myself a reviewer. This all looks good. > > Thanks, > David > > On 21/05/2019 4:19 pm, serguei.spitsyn at oracle.com wrote: >> Hi guys, >> >> I've found one more fragment in the IsModifiableClass spec which has >> to be fixed. >> >> >> Updated webrev v2: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >> >> >> >> Specdiff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >> >> >> >> Enhancement: >> ?? https://bugs.openjdk.java.net/browse/JDK-8046018 >> >> Related CSR: >> ?? https://bugs.openjdk.java.net/browse/JDK-8223915 >> >> >> Thanks, >> Serguei >> >> >> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for looking at this! >>> >>> >>> On 5/20/19 20:53, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a fix for enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>> >>>>> Related CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>> >>>> I have some comments on the CSR and about this change overall as to >>>> me it is not a simple clarification at all, but potentially a >>>> significant change in the meaning of the capability. >>> >>> >>> I've answered your question in the CSR with my comment. >>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>> >>>> >>>> You introduced a typo: modifialble >>>> >>>> Assuming this proceeds a similar change is needed earlier: >>>> >>>> 7444???????? >>>> 7445?????????? If possessed then all classes (except primitive, >>>> array, and some implementation defined >>>> 7446?????????? classes) are modifiable (redefine or retransform). >>> >>> Good catch, thanks! >>> I've updated the webrev in place. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Summary: >>>>> >>>>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>>>> spec more inconsistent. >>>>> ?? It is just about a couple of lines. >>>>> >>>>> Thanks, >>>>> Serguei >>> >> From robbin.ehn at oracle.com Tue May 21 07:52:39 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 21 May 2019 09:52:39 +0200 Subject: RFR(m): 8223306: Remove threads linked list (use ThreadsList's array in SA) In-Reply-To: References: <62f74ab3-364b-8de0-bce6-69b716103f22@oracle.com> <6525cd5c-441e-b213-1238-321420c15f26@oracle.com> <0d69609b-8c1b-1ae3-6778-d7fee4efea80@oracle.com> <8dd2eed5-b450-ac7a-a5e4-12706453f072@oracle.com> Message-ID: <988a7b22-19cf-b060-7fae-a91851869592@oracle.com> Hi Dan, Fixed below, thanks! /Robbin On 2019-05-20 20:20, Daniel D. Daugherty wrote: > On 5/14/19 10:02 AM, Robbin Ehn wrote: >> Hi Dan, >> >> Full: >> http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html >> Inc: >> http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java > > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/DeadlockDetector.java > ??? L2:? * Copyright (c) 2004, 20019, Oracle and/or its affiliates. All rights > reserved. > ??????? Typo - s/20019/2019/ > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/JavaThreadsPanel.java > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java > > ??? L136: ??????????????? writeJavaThread(jt, i+1); > ??????? formatting: s/i+1/i + 1/ > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PointerFinder.java > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/ReversePtrsAnalysis.java > > ??? No comments. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaVM.java > ??? L2:? * Copyright (c) 2004, 20019, Oracle and/or its affiliates. All rights > reserved. > ??????? Typo - s/20019/2019/ > > Thumbs up! I don't need to see a new webrev for the above nits. > > I took a quick pass thru: > >> http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html > > and nothing jumped out at me... > > Dan > > >> >> On 2019-05-08 18:02, Daniel D. Daugherty wrote: >>> General comment - Please make sure to update all copyright years before >>> ?????????????????? pushing this changeset. >> >> Fixed. >> >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java >>> ???? L46: >>> ???? L47: ??? private static AddressField????? threadsField; >>> ???? L48: ??? private static CIntegerField???? lengthField; >>> ???????? nit - please delete blank line on L46 >>> ???????? nit - please reduce the space between type and variable names >>> ?????????????? (I have no preference if you still keep them aligned) >>> >>> ???? nit - Please delete blank line on L74. >> >> Fixed. >> >> >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java >>> ???? old L203: ????? Threads threads = VM.getVM().getThreads(); >>> ???? old L204: ????? for (JavaThread cur = threads.first(); cur != null; cur >>> = cur.next()) { >>> ???? new L203: ????? VM.getVM().getThreads().doJavaThreads((cur) -> { >>> ???????? In this case, you did a lambda conversion... >>> >>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/StackTrace.java >>> ???? old L75: ??????????? for (JavaThread cur = threads.first(); cur != null; >>> cur = cur.next(), i++) { >>> ???? new L75: ??????????? for (int k = 0; k < threads.getNumberOfThreads(); >>> k++) { >>> ???? new L76: ??????????????? JavaThread cur = threads.getJavaThreadAt(k); >>> ???????? In this case, you didn't do a lambda conversion... >>> >>> ???????? I'm trying to grok a reason for the different styles... >>> ???????? Update: Is is maybe a control flow thing? (No, I don't know much >>> ??????????? about lambdas.) As in: Loops that "break" or early return are >>> ??????????? not amenable to conversion to a lambda... (just guessing) >> >> I converted those where it was easy to see that the loop did not have an early >> termination. Lambdas removed. >> >>> >>> ???? L74: ??????????? int i = 1; >>> ???????? Not your bug, but I think that 'i' is not used. >>> >> >> Fixed. >> >>> This all looks good to me... so thumbs up! >> >> Thanks. >> >>> >>> I have some reservations about using lambdas in a debugging tool. >>> My personal philosophy about debugging tools is that they should >>> be built on the simplest/most stable technology to reduce the >>> chances of the more complicated technology failing during a debug >>> session. I hate it when my debugger crashes! >> >> I removed all lambdas! >> >> Thanks for looking at this, Robbin >> >>> >>> That said, SA is pretty much standalone so use of lambdas in this >>> debugging tool shouldn't affect the JVM or core file being debugged. >>> >>> Again, thumbs up! >>> >>> Dan >>> >>> >>>> >>>> /Robbin >>>> >>>> On 2019-05-08 11:17, Robbin Ehn wrote: >>>>> Hi David, >>>>> >>>>> I changed to normal for: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html >>>>> >>>>> >>>>> Full: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/ >>>>> Inc: >>>>> http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/inc/webrev/ >>>>> >>>>> Passes t1-2 >>>>> >>>>> Thanks, Robbin >>>>> >>>>> >>>>> On 2019-05-07 09:47, David Holmes wrote: >>>>>> Hi Robbin, >>>>>> >>>>>> On 7/05/2019 4:50 pm, Robbin Ehn wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 5/7/19 12:40 AM, David Holmes wrote: >>>>>>>> Hi Robbin, >>>>>>>> >>>>>>>> I have a few concerns here. >>>>>>>> >>>>>>>> First I can't see how you are actually integrating the SA with the >>>>>>>> ThreadSMR. You've exposed the _java_thread_list for it to iterate but >>>>>>>> IIRC that list can be updated when threads are added/removed and I'm not >>>>>>>> seeing how the SA is left iterating a valid list - we'd normally using a >>>>>>>> ThreadsListHandle for that ?? (I may need a refresher on how this list >>>>>>>> is actually maintained.) >>>>>>> >>>>>>> The processes must be paused. If the processes would be running the >>>>>>> linked list is also broken since if we unlink and delete a JavaThread and >>>>>>> then later SA follows that _next pointer. >>>>>> >>>>>> Ah good point. Thanks for clarifying. >>>>>> >>>>>>>> >>>>>>>> The conversion from external iteration of the list (the for loop) to >>>>>>>> internal iteration (passing a lambda to JavaThreadsDo) is also >>>>>>>> problematic. First I'd be very wary about introducing lambda expressions >>>>>>>> into the SA code - lambda drags in a lot of supporting code that could >>>>>>>> have an impact on the way SA functions. There are places where we have >>>>>>>> to avoid lambdas due to bootstrapping/initialization issues and I think >>>>>>>> the SA may be an area where we also want to keep the code extremely simple. >>>>>>> >>>>>>> There are already several usages of lambdas in SA code, e.g. >>>>>>> LinuxDebuggerLocal.java. SA is not a core module, it's an application, >>>>>>> there is not a bootstrap issue or so. >>>>>> >>>>>> Hmm okay. Lambda carries a lot of baggage. But if its already being used ... >>>>>> >>>>>>>> Second by using lambda's with internal iteration you've lost the ability >>>>>>>> to terminate the iteration loop! In the existing code if we have a >>>>>>>> return in the for-loop then we not only terminate the loop but the >>>>>>>> enclosing method. With the lambda the "return" just ends the current >>>>>>>> iteration and JavaThreadsDo will then continue with the next thread - so >>>>>>>> we don't even terminate the iteration let alone the method performing >>>>>>>> the iteration. So for places were we want to process one thread, for >>>>>>>> example, we will continue to iterate all remaining threads and just do >>>>>>>> nothing with them. That's very inefficient. >>>>>>> >>>>>>> That's why I only used the internal iteration where we didn't have early >>>>>>> returns. >>>>>> >>>>>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java >>>>>> - original code: >>>>>> >>>>>> 1556???????? new Command("where", "where { -a | id }", false) { >>>>>> 1557???????????? public void doit(Tokens t) { >>>>>> ... >>>>>> 1564???????????????????? for (JavaThread thread = threads.first(); thread >>>>>> != null; thread = thread.next()) { >>>>>> 1565???????????????????????? ByteArrayOutputStream bos = new >>>>>> ByteArrayOutputStream(); >>>>>> 1566???????????????????????? thread.printThreadIDOn(new PrintStream(bos)); >>>>>> 1567???????????????????????? if (all || bos.toString().equals(name)) { >>>>>> 1568???????????????????????????? out.println("Thread " + bos.toString() + >>>>>> " Address: " + thread.getAddress()); >>>>>> ... >>>>>> 1577???????????????????????????? } >>>>>> 1578???????????????????????????? if (!all) return; >>>>>> >>>>>> That looks like an early return to me. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> Thanks, Robbin >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 6/05/2019 5:31 pm, Robbin Ehn wrote: >>>>>>>>> Hi, please review. >>>>>>>>> >>>>>>>>> Old threads linked list remove and updated SA to use ThreadsList array >>>>>>>>> instead. >>>>>>>>> >>>>>>>>> Issue: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223306 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~rehn/8223306/webrev/ >>>>>>>>> >>>>>>>>> Passes t1-3 (which includes SA tests). >>>>>>>>> >>>>>>>>> Thanks, Robbin >>> > From daniel.fuchs at oracle.com Tue May 21 09:04:56 2019 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 21 May 2019 10:04:56 +0100 Subject: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: <440dab5e-090a-adb4-0caa-a035059611b4@oracle.com> On 21/05/2019 04:25, Daniil Titov wrote: > Please review un updated version of the previous change that also removes unnecessary line > > chmod ug+x $REVOKEALL > > from test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh > > Webrev:http://cr.openjdk.java.net/~dtitov/8214545/webrev.03 > Bug:https://bugs.openjdk.java.net/browse/JDK-8214545 Looks good to me as well. best regards, -- daniel From stefan.karlsson at oracle.com Tue May 21 10:14:03 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 12:14:03 +0200 Subject: RFR: 8224479: New diagnostic command: VM.get_flag Message-ID: Hi all, Please review this patch to introduce a new diagnostic command: VM.get_flag. http://cr.openjdk.java.net/~stefank/8224479/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8224479 Today we have: - VM.set_flag - which allows the user to set a manageable flag - VM.flags - which allows the user to print all set flags or print similar output as -XX:+PrintFlagsFinal I propose that we add a new command to print the value of one flag. Output from help: ========== $ jcmd HelloSleep help VM.get_flag 1060: VM.get_flag Prints the value of a VM flag option. Impact: Low Permission: java.lang.management.ManagementPermission(monitor) Syntax : VM.get_flag Arguments: flag name : The name of the flag we want to get (STRING, no default value) ========== Output from usage: ========== $ jcmd HelloSleep VM.get_flag UseSerialGC 1060: false ========== I'll create a CSR if others also thinks this is a worthwhile feature. Thanks, StefanK From thomas.stuefe at gmail.com Tue May 21 10:37:40 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 12:37:40 +0200 Subject: RFR: 8224479: New diagnostic command: VM.get_flag In-Reply-To: References: Message-ID: I think this is useful. I have a vague preference for reusing VM.flags though - giving it the option to only print one flag - instead of adding a new command. Just my 5c .. Thomas On Tue, May 21, 2019, 12:14 Stefan Karlsson wrote: > Hi all, > > Please review this patch to introduce a new diagnostic command: > VM.get_flag. > > http://cr.openjdk.java.net/~stefank/8224479/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224479 > > Today we have: > > - VM.set_flag - which allows the user to set a manageable flag > - VM.flags - which allows the user to print all set flags or print > similar output as -XX:+PrintFlagsFinal > > I propose that we add a new command to print the value of one flag. > > Output from help: > ========== > $ jcmd HelloSleep help VM.get_flag > 1060: > VM.get_flag > Prints the value of a VM flag option. > > Impact: Low > > Permission: java.lang.management.ManagementPermission(monitor) > > Syntax : VM.get_flag > > Arguments: > flag name : The name of the flag we want to get (STRING, no > default value) > ========== > > Output from usage: > ========== > $ jcmd HelloSleep VM.get_flag UseSerialGC > 1060: > false > ========== > > I'll create a CSR if others also thinks this is a worthwhile feature. > > Thanks, > StefanK > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.karlsson at oracle.com Tue May 21 13:22:07 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 21 May 2019 15:22:07 +0200 Subject: RFR: 8224479: New diagnostic command: VM.get_flag In-Reply-To: References: Message-ID: Hi Thomas, On 2019-05-21 12:37, Thomas St?fe wrote: > I think this is useful. Thanks. I have a vague preference for reusing VM.flags > though - giving it the option to only print one flag - instead of adding > a new command. So, we would have three different modes for VM.flags: $ jcmd HelloSleep VM.flags 371: -XX:CICompilerCount=15 -XX:ConcGCThreads=6 -XX:G1ConcRefinementThreads=23 -XX:G1HeapRegionSize=4194304 -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=2113929216 -XX:MarkStackSize=4194304 -XX:MaxHeapSize=32178700288 -XX:MaxNewSize=19306381312 -XX:MinHeapDeltaBytes=4194304 -XX:NonNMethodCodeHeapSize=8182140 -XX:NonProfiledCodeHeapSize=121738050 -XX:ProfiledCodeHeapSize=121738050 -XX:ReservedCodeCacheSize=251658240 -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseG1GC $ /localhome/java/jdk9/bin/jcmd HelloSleep VM.flags -all 371: [Global flags] ccstrlist AOTLibrary = {product} {default} int ActiveProcessorCount = -1 {product} {default} uintx AdaptiveSizeDecrementScaleFactor = 4 {product} {default} uintx AdaptiveSizeMajorGCDecayTimeScale = 10 {product} {default} uintx AdaptiveSizePolicyCollectionCostMargin = 50 {product} {default} and a new mode: $ /localhome/java/jdk9/bin/jcmd HelloSleep VM.flags -name=UseSerialGC 371: bool UseSerialGC = false {product} {default} Let's see if anyone else has some feedback regarding this. Thanks, StefanK > > Just my 5c > > .. Thomas > > On Tue, May 21, 2019, 12:14 Stefan Karlsson > wrote: > > Hi all, > > Please review this patch to introduce a new diagnostic command: > VM.get_flag. > > http://cr.openjdk.java.net/~stefank/8224479/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8224479 > > Today we have: > > - VM.set_flag - which allows the user to set a manageable flag > - VM.flags - which allows the user to print all set flags or print > similar output as -XX:+PrintFlagsFinal > > I propose that we add a new command to print the value of one flag. > > Output from help: > ========== > $ jcmd HelloSleep help VM.get_flag > 1060: > VM.get_flag > Prints the value of a VM flag option. > > Impact: Low > > Permission: java.lang.management.ManagementPermission(monitor) > > Syntax : VM.get_flag? > > Arguments: > ? ? ? ? flag name :? The name of the flag we want to get (STRING, > no default value) > ========== > > Output from usage: > ========== > $ jcmd HelloSleep VM.get_flag UseSerialGC > 1060: > false > ========== > > I'll create a CSR if others also thinks this is a worthwhile feature. > > Thanks, > StefanK > From thomas.stuefe at gmail.com Tue May 21 13:25:33 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 15:25:33 +0200 Subject: RFR: 8224479: New diagnostic command: VM.get_flag In-Reply-To: References: Message-ID: On Tue, May 21, 2019 at 3:22 PM Stefan Karlsson wrote: > Hi Thomas, > > On 2019-05-21 12:37, Thomas St?fe wrote: > > I think this is useful. > > Thanks. > > I have a vague preference for reusing VM.flags > > though - giving it the option to only print one flag - instead of adding > > a new command. > > So, we would have three different modes for VM.flags: > $ jcmd HelloSleep VM.flags > 371: > -XX:CICompilerCount=15 -XX:ConcGCThreads=6 > -XX:G1ConcRefinementThreads=23 -XX:G1HeapRegionSize=4194304 > -XX:GCDrainStackTargetSize=64 -XX:InitialHeapSize=2113929216 > -XX:MarkStackSize=4194304 -XX:MaxHeapSize=32178700288 > -XX:MaxNewSize=19306381312 -XX:MinHeapDeltaBytes=4194304 > -XX:NonNMethodCodeHeapSize=8182140 -XX:NonProfiledCodeHeapSize=121738050 > -XX:ProfiledCodeHeapSize=121738050 -XX:ReservedCodeCacheSize=251658240 > -XX:+SegmentedCodeCache -XX:+UseCompressedClassPointers > -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps -XX:+UseG1GC > > $ /localhome/java/jdk9/bin/jcmd HelloSleep VM.flags -all > 371: > [Global flags] > ccstrlist AOTLibrary = > {product} {default} > int ActiveProcessorCount = -1 > {product} {default} > uintx AdaptiveSizeDecrementScaleFactor = 4 > {product} {default} > uintx AdaptiveSizeMajorGCDecayTimeScale = 10 > {product} {default} > uintx AdaptiveSizePolicyCollectionCostMargin = 50 > {product} {default} > > and a new mode: > $ /localhome/java/jdk9/bin/jcmd HelloSleep VM.flags -name=UseSerialGC > 371: > bool UseSerialGC = false > {product} {default} > > Let's see if anyone else has some feedback regarding this. > > Thanks, > StefanK > > As I write, slight preference only. If others like VM.get_flag more, I am fine with that too, since it complements the existing VM.set_flag. ..Thomas > > > > Just my 5c > > > > .. Thomas > > > > On Tue, May 21, 2019, 12:14 Stefan Karlsson > > wrote: > > > > Hi all, > > > > Please review this patch to introduce a new diagnostic command: > > VM.get_flag. > > > > http://cr.openjdk.java.net/~stefank/8224479/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8224479 > > > > Today we have: > > > > - VM.set_flag - which allows the user to set a manageable flag > > - VM.flags - which allows the user to print all set flags or print > > similar output as -XX:+PrintFlagsFinal > > > > I propose that we add a new command to print the value of one flag. > > > > Output from help: > > ========== > > $ jcmd HelloSleep help VM.get_flag > > 1060: > > VM.get_flag > > Prints the value of a VM flag option. > > > > Impact: Low > > > > Permission: java.lang.management.ManagementPermission(monitor) > > > > Syntax : VM.get_flag > > > > Arguments: > > flag name : The name of the flag we want to get (STRING, > > no default value) > > ========== > > > > Output from usage: > > ========== > > $ jcmd HelloSleep VM.get_flag UseSerialGC > > 1060: > > false > > ========== > > > > I'll create a CSR if others also thinks this is a worthwhile feature. > > > > Thanks, > > StefanK > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Tue May 21 16:34:25 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 May 2019 12:34:25 -0400 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> Message-ID: <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: > Hi guys, > > I've found one more fragment in the IsModifiableClass spec which has > to be fixed. > > > Updated webrev v2: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ > src/hotspot/share/prims/jvmti.xml ??? No comments. Looks like there was a specific update to the spec to allow can_redefine_any_class to include retransform (in addition to redefine): 1.1.82 13 February 2006 ??? Doc fixes: update can_redefine_any_class to include retransform. Clarify that exception events cover all Throwables. In GetStackTrace, no test is done for start_depth too big if start_depth is zero, Clarify fields reported in Primitive Field Callback -- static vs instance. Repair confusing names of heap types, including callback names. Require consistent usage of stack depth in the face of thread launch methods. Note incompatibility of JVM TI memory management with other systems. I can't tell if you've chased down that change and why you no longer think that change is necessary. I'm okay with the change, but I think you have more research to do here. Dan > Specdiff: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ > > > > Enhancement: > ? https://bugs.openjdk.java.net/browse/JDK-8046018 > > Related CSR: > ? https://bugs.openjdk.java.net/browse/JDK-8223915 > > > Thanks, > Serguei > > > On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> Thank you for looking at this! >> >> >> On 5/20/19 20:53, David Holmes wrote: >>> Hi Serguei, >>> >>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>> Please, review a fix for enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>> >>>> Related CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>> >>> I have some comments on the CSR and about this change overall as to >>> me it is not a simple clarification at all, but potentially a >>> significant change in the meaning of the capability. >> >> >> I've answered your question in the CSR with my comment. >> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>> >>> >>> You introduced a typo: modifialble >>> >>> Assuming this proceeds a similar change is needed earlier: >>> >>> 7444???????? >>> 7445?????????? If possessed then all classes (except primitive, >>> array, and some implementation defined >>> 7446?????????? classes) are modifiable (redefine or retransform). >> >> Good catch, thanks! >> I've updated the webrev in place. >> >> Thanks, >> Serguei >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Summary: >>>> >>>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>>> spec more inconsistent. >>>> ?? It is just about a couple of lines. >>>> >>>> Thanks, >>>> Serguei >> > From chris.plummer at oracle.com Tue May 21 16:45:40 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 21 May 2019 09:45:40 -0700 Subject: RFR: 8224479: New diagnostic command: VM.get_flag In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From jcbeyler at google.com Tue May 21 16:52:52 2019 From: jcbeyler at google.com (Jean Christophe Beyler) Date: Tue, 21 May 2019 09:52:52 -0700 Subject: RFR (XS) 8224500: Put HeapMonitorStatArrayCorrectnessTest in the problem list Message-ID: Hi all, Could I get a review for pushing HeapMonitorStatArrayCorrectnessTest into the problem list? It is a test that is tricky to get always right and I'll work offline on getting it more stable. Bug: https://bugs.openjdk.java.net/browse/JDK-8224500 The diff is a one liner so here it is: diff -r 1b28206dcbcb test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt Tue May 21 18:22:54 2019 +0200 +++ b/test/hotspot/jtreg/ProblemList.txt Tue May 21 09:49:53 2019 -0700 @@ -132,6 +132,7 @@ serviceability/sa/TestUniverse.java#id0 8193639,8211767 solaris-all,linux-ppc64le,linux-ppc64 serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java 8214032 generic-all +serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java 8224150 generic-all ############################################################################# Thanks, Jc -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Tue May 21 17:22:41 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 21 May 2019 19:22:41 +0200 Subject: RFR (XS) 8224500: Put HeapMonitorStatArrayCorrectnessTest in the problem list In-Reply-To: References: Message-ID: Looks fine and trivial. Cheers, Thomas On Tue, May 21, 2019 at 6:53 PM Jean Christophe Beyler wrote: > Hi all, > > Could I get a review for pushing HeapMonitorStatArrayCorrectnessTest into > the problem list? It is a test that is tricky to get always right and I'll > work offline on getting it more stable. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8224500 > > The diff is a one liner so here it is: > > diff -r 1b28206dcbcb test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt Tue May 21 18:22:54 2019 > +0200 > +++ b/test/hotspot/jtreg/ProblemList.txt Tue May 21 09:49:53 2019 > -0700 > @@ -132,6 +132,7 @@ > serviceability/sa/TestUniverse.java#id0 8193639,8211767 > solaris-all,linux-ppc64le,linux-ppc64 > > serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatIntervalTest.java > 8214032 generic-all > +serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitorStatArrayCorrectnessTest.java > 8224150 generic-all > > > ############################################################################# > > Thanks, > Jc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Tue May 21 22:58:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 08:58:12 +1000 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> Message-ID: <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> Hi Dan, On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: > On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >> Hi guys, >> >> I've found one more fragment in the IsModifiableClass spec which has >> to be fixed. >> >> >> Updated webrev v2: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >> > > src/hotspot/share/prims/jvmti.xml > ??? No comments. > > Looks like there was a specific update to the spec to allow > can_redefine_any_class > to include retransform (in addition to redefine): > > 1.1.82 > 13 February 2006 ??? Doc fixes: update can_redefine_any_class to include > retransform. Clarify that exception events cover all Throwables. In > GetStackTrace, no test is done for start_depth too big if start_depth is > zero, Clarify fields reported in Primitive Field Callback -- static vs > instance. Repair confusing names of heap types, including callback > names. Require consistent usage of stack depth in the face of thread > launch methods. Note incompatibility of JVM TI memory management with > other systems. > > I can't tell if you've chased down that change and why you no longer > think that change is necessary. > > I'm okay with the change, but I think you have more research to do here. I already chased that down and mentioned it in the CSR. It was done under: https://bugs.openjdk.java.net/browse/JDK-6328530 Unfortunately I misread the original bug description. In relation to can_redefine_any_class it states: A more precise definition would be: Can retransform or redefine any non-primitive non-array class. It appears to me that they did consider can_redefine_any_class to be a "super" capability that could be added on top of can_redefine_classes to extend it to "any" class; or on top of can_retransform_classes to extend it to "any" class. If so the name choice was unfortunate. Further it seems the implementation never checked this anyway. David > Dan > > >> Specdiff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >> >> >> >> Enhancement: >> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >> >> Related CSR: >> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >> >> >> Thanks, >> Serguei >> >> >> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for looking at this! >>> >>> >>> On 5/20/19 20:53, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a fix for enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>> >>>>> Related CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>> >>>> I have some comments on the CSR and about this change overall as to >>>> me it is not a simple clarification at all, but potentially a >>>> significant change in the meaning of the capability. >>> >>> >>> I've answered your question in the CSR with my comment. >>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>> >>>> >>>> You introduced a typo: modifialble >>>> >>>> Assuming this proceeds a similar change is needed earlier: >>>> >>>> 7444???????? >>>> 7445?????????? If possessed then all classes (except primitive, >>>> array, and some implementation defined >>>> 7446?????????? classes) are modifiable (redefine or retransform). >>> >>> Good catch, thanks! >>> I've updated the webrev in place. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Summary: >>>>> >>>>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>>>> spec more inconsistent. >>>>> ?? It is just about a couple of lines. >>>>> >>>>> Thanks, >>>>> Serguei >>> >> > From daniel.daugherty at oracle.com Tue May 21 23:11:29 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 21 May 2019 19:11:29 -0400 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> Message-ID: <196d1853-4946-2cd6-3248-8b7f34881c2f@oracle.com> On 5/21/19 6:58 PM, David Holmes wrote: > Hi Dan, > > On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>> Hi guys, >>> >>> I've found one more fragment in the IsModifiableClass spec which has >>> to be fixed. >>> >>> >>> Updated webrev v2: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>> >> >> src/hotspot/share/prims/jvmti.xml >> ???? No comments. >> >> Looks like there was a specific update to the spec to allow >> can_redefine_any_class >> to include retransform (in addition to redefine): >> >> 1.1.82 >> 13 February 2006 ??? Doc fixes: update can_redefine_any_class to >> include retransform. Clarify that exception events cover all >> Throwables. In GetStackTrace, no test is done for start_depth too big >> if start_depth is zero, Clarify fields reported in Primitive Field >> Callback -- static vs instance. Repair confusing names of heap types, >> including callback names. Require consistent usage of stack depth in >> the face of thread launch methods. Note incompatibility of JVM TI >> memory management with other systems. >> >> I can't tell if you've chased down that change and why you no longer >> think that change is necessary. >> >> I'm okay with the change, but I think you have more research to do here. > > I already chased that down and mentioned it in the CSR. It was done > under: > > https://bugs.openjdk.java.net/browse/JDK-6328530 > > Unfortunately I misread the original bug description. In relation to > can_redefine_any_class it states: > > A more precise definition would be: > ?????? Can retransform or redefine any non-primitive non-array class. > > It appears to me that they did consider can_redefine_any_class to be a > "super" capability that could be added on top of can_redefine_classes > to extend it to "any" class; or on top of can_retransform_classes to > extend it to "any" class. If so the name choice was unfortunate. > > Further it seems the implementation never checked this anyway. Thanks for closing the loop on this query. When I read the CSR, I missed that bit of research. Dan > > David > >> Dan >> >> >>> Specdiff: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>> >>> >>> >>> Enhancement: >>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>> >>> Related CSR: >>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for looking at this! >>>> >>>> >>>> On 5/20/19 20:53, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review a fix for enhancement: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>> >>>>>> Related CSR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>> >>>>> I have some comments on the CSR and about this change overall as >>>>> to me it is not a simple clarification at all, but potentially a >>>>> significant change in the meaning of the capability. >>>> >>>> >>>> I've answered your question in the CSR with my comment. >>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>> >>>>> >>>>> You introduced a typo: modifialble >>>>> >>>>> Assuming this proceeds a similar change is needed earlier: >>>>> >>>>> 7444???????? >>>>> 7445?????????? If possessed then all classes (except primitive, >>>>> array, and some implementation defined >>>>> 7446?????????? classes) are modifiable (redefine or retransform). >>>> >>>> Good catch, thanks! >>>> I've updated the webrev in place. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>>>>> spec more inconsistent. >>>>>> ?? It is just about a couple of lines. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >>> >> From serguei.spitsyn at oracle.com Tue May 21 23:53:56 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 May 2019 16:53:56 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> Message-ID: Hi Dan and David, On 5/21/19 15:58, David Holmes wrote: > Hi Dan, > > On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>> Hi guys, >>> >>> I've found one more fragment in the IsModifiableClass spec which has >>> to be fixed. >>> >>> >>> Updated webrev v2: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>> >> >> src/hotspot/share/prims/jvmti.xml >> ???? No comments. >> >> Looks like there was a specific update to the spec to allow >> can_redefine_any_class >> to include retransform (in addition to redefine): >> >> 1.1.82 >> 13 February 2006 ??? Doc fixes: update can_redefine_any_class to >> include retransform. Clarify that exception events cover all >> Throwables. In GetStackTrace, no test is done for start_depth too big >> if start_depth is zero, Clarify fields reported in Primitive Field >> Callback -- static vs instance. Repair confusing names of heap types, >> including callback names. Require consistent usage of stack depth in >> the face of thread launch methods. Note incompatibility of JVM TI >> memory management with other systems. >> >> I can't tell if you've chased down that change and why you no longer >> think that change is necessary. >> >> I'm okay with the change, but I think you have more research to do here. > > I already chased that down and mentioned it in the CSR. It was done > under: > > https://bugs.openjdk.java.net/browse/JDK-6328530 > > Unfortunately I misread the original bug description. In relation to > can_redefine_any_class it states: > > A more precise definition would be: > ?????? Can retransform or redefine any non-primitive non-array class. > > It appears to me that they did consider can_redefine_any_class to be a > "super" capability that could be added on top of can_redefine_classes > to extend it to "any" class; or on top of can_retransform_classes to > extend it to "any" class. If so the name choice was unfortunate. > > Further it seems the implementation never checked this anyway. Right. The approach taken for JDK-6328530 is non-symmetrical and confusing. But, I think, I understand why this decision was made. :) If we ever decide to make some (non-primitive and non-array) classes to be non-modifiable then I do not see problems to implement it in a way that can_redefine_any_class will be checked on RedefineClasses only and can_retransform_any_class will be checked on RetransformClasses only. We will get a symmetry (and so, a simplification as well) in two dimensions: ? - between redefine and retransform capabilities ? - between can_redefine_classes and can_redefine_any_class capabilities Thanks, Serguei > > David > >> Dan >> >> >>> Specdiff: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>> >>> >>> >>> Enhancement: >>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>> >>> Related CSR: >>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> Thank you for looking at this! >>>> >>>> >>>> On 5/20/19 20:53, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review a fix for enhancement: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>> >>>>>> Related CSR: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>> >>>>> I have some comments on the CSR and about this change overall as >>>>> to me it is not a simple clarification at all, but potentially a >>>>> significant change in the meaning of the capability. >>>> >>>> >>>> I've answered your question in the CSR with my comment. >>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>> >>>>> >>>>> You introduced a typo: modifialble >>>>> >>>>> Assuming this proceeds a similar change is needed earlier: >>>>> >>>>> 7444???????? >>>>> 7445?????????? If possessed then all classes (except primitive, >>>>> array, and some implementation defined >>>>> 7446?????????? classes) are modifiable (redefine or retransform). >>>> >>>> Good catch, thanks! >>>> I've updated the webrev in place. >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> Summary: >>>>>> >>>>>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>>>>> spec more inconsistent. >>>>>> ?? It is just about a couple of lines. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>> >>> >> From serguei.spitsyn at oracle.com Tue May 21 23:57:45 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 May 2019 16:57:45 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> Message-ID: <8d77a7df-a864-1dc8-56ee-721c4a70fb1e@oracle.com> Hi Dan, On 5/21/19 09:34, Daniel D. Daugherty wrote: > On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >> Hi guys, >> >> I've found one more fragment in the IsModifiableClass spec which has >> to be fixed. >> >> >> Updated webrev v2: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >> > > src/hotspot/share/prims/jvmti.xml > ??? No comments. > > Looks like there was a specific update to the spec to allow > can_redefine_any_class > to include retransform (in addition to redefine): > > 1.1.82 > 13 February 2006 ??? Doc fixes: update can_redefine_any_class to > include retransform. Clarify that exception events cover all > Throwables. In GetStackTrace, no test is done for start_depth too big > if start_depth is zero, Clarify fields reported in Primitive Field > Callback -- static vs instance. Repair confusing names of heap types, > including callback names. Require consistent usage of stack depth in > the face of thread launch methods. Note incompatibility of JVM TI > memory management with other systems. > > I can't tell if you've chased down that change and why you no longer > think that change is necessary. > > I'm okay with the change, Thank you a lot for review! Unfortunately, I've already pushed the fix, so you are not in the reviewers list. > but I think you have more research to do here. This has been replied on latest David's email. Thanks, Serguei > > Dan > > >> Specdiff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >> >> >> >> Enhancement: >> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >> >> Related CSR: >> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >> >> >> Thanks, >> Serguei >> >> >> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> Thank you for looking at this! >>> >>> >>> On 5/20/19 20:53, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>> Please, review a fix for enhancement: >>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>> >>>>> Related CSR: >>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>> >>>> I have some comments on the CSR and about this change overall as to >>>> me it is not a simple clarification at all, but potentially a >>>> significant change in the meaning of the capability. >>> >>> >>> I've answered your question in the CSR with my comment. >>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>> >>>> >>>> You introduced a typo: modifialble >>>> >>>> Assuming this proceeds a similar change is needed earlier: >>>> >>>> 7444???????? >>>> 7445?????????? If possessed then all classes (except primitive, >>>> array, and some implementation defined >>>> 7446?????????? classes) are modifiable (redefine or retransform). >>> >>> Good catch, thanks! >>> I've updated the webrev in place. >>> >>> Thanks, >>> Serguei >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Summary: >>>>> >>>>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>>>> spec more inconsistent. >>>>> ?? It is just about a couple of lines. >>>>> >>>>> Thanks, >>>>> Serguei >>> >> > From david.holmes at oracle.com Wed May 22 00:25:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 10:25:10 +1000 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> Message-ID: <351a16c6-7462-4414-01de-242e8b637854@oracle.com> Hi Serguei, Sorry but I think this "fix" is inappropriate. The capability may be badly named but the intent was to have it apply to both redefine and retransform. Further this change should not have been pushed yet as the CSR has not been approved. David ----- On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: > Hi Dan and David, > > On 5/21/19 15:58, David Holmes wrote: >> Hi Dan, >> >> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi guys, >>>> >>>> I've found one more fragment in the IsModifiableClass spec which has >>>> to be fixed. >>>> >>>> >>>> Updated webrev v2: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>> >>> >>> src/hotspot/share/prims/jvmti.xml >>> ???? No comments. >>> >>> Looks like there was a specific update to the spec to allow >>> can_redefine_any_class >>> to include retransform (in addition to redefine): >>> >>> 1.1.82 >>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class to >>> include retransform. Clarify that exception events cover all >>> Throwables. In GetStackTrace, no test is done for start_depth too big >>> if start_depth is zero, Clarify fields reported in Primitive Field >>> Callback -- static vs instance. Repair confusing names of heap types, >>> including callback names. Require consistent usage of stack depth in >>> the face of thread launch methods. Note incompatibility of JVM TI >>> memory management with other systems. >>> >>> I can't tell if you've chased down that change and why you no longer >>> think that change is necessary. >>> >>> I'm okay with the change, but I think you have more research to do here. >> >> I already chased that down and mentioned it in the CSR. It was done >> under: >> >> https://bugs.openjdk.java.net/browse/JDK-6328530 >> >> Unfortunately I misread the original bug description. In relation to >> can_redefine_any_class it states: >> >> A more precise definition would be: >> ?????? Can retransform or redefine any non-primitive non-array class. >> >> It appears to me that they did consider can_redefine_any_class to be a >> "super" capability that could be added on top of can_redefine_classes >> to extend it to "any" class; or on top of can_retransform_classes to >> extend it to "any" class. If so the name choice was unfortunate. >> >> Further it seems the implementation never checked this anyway. > > Right. > The approach taken for JDK-6328530 is non-symmetrical and confusing. > But, I think, I understand why this decision was made. :) > > If we ever decide to make some (non-primitive and non-array) classes to > be non-modifiable then > I do not see problems to implement it in a way that > can_redefine_any_class will be checked on > RedefineClasses only and can_retransform_any_class will be checked on > RetransformClasses only. > We will get a symmetry (and so, a simplification as well) in two > dimensions: > ? - between redefine and retransform capabilities > ? - between can_redefine_classes and can_redefine_any_class capabilities > > Thanks, > Serguei > >> >> David >> >>> Dan >>> >>> >>>> Specdiff: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>> >>>> >>>> >>>> Enhancement: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>> >>>> Related CSR: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>> Hi David, >>>>> >>>>> Thank you for looking at this! >>>>> >>>>> >>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>> Please, review a fix for enhancement: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>> >>>>>>> Related CSR: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>> >>>>>> I have some comments on the CSR and about this change overall as >>>>>> to me it is not a simple clarification at all, but potentially a >>>>>> significant change in the meaning of the capability. >>>>> >>>>> >>>>> I've answered your question in the CSR with my comment. >>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>> >>>>>> >>>>>> You introduced a typo: modifialble >>>>>> >>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>> >>>>>> 7444???????? >>>>>> 7445?????????? If possessed then all classes (except primitive, >>>>>> array, and some implementation defined >>>>>> 7446?????????? classes) are modifiable (redefine or retransform). >>>>> >>>>> Good catch, thanks! >>>>> I've updated the webrev in place. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class capability >>>>>>> spec more inconsistent. >>>>>>> ?? It is just about a couple of lines. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>> >>>> >>> > From serguei.spitsyn at oracle.com Wed May 22 03:59:11 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 21 May 2019 20:59:11 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <351a16c6-7462-4414-01de-242e8b637854@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> Message-ID: Hi David, On 5/21/19 17:25, David Holmes wrote: > Hi Serguei, > > Sorry but I think this "fix" is inappropriate. The capability may be > badly named but the intent was to have it apply to both redefine and > retransform. Not sure, I fully understand you here. This intent seemed to be wrong or, at least, it is really confusing to everybody. To understand it better, let's do some analysis first and start from what we know. 1) The JVMTI RedefineClasses is implemented with using a VM_RedefineClasses operation. ?? So, the VM_RedefineClasses is triggered on behave of a RedefineClasses call from agent code. ?? The capability "can_redefine_classes" has to be possessed to call RedefineClasses. 2) The JVMTI RetransformClasses is also implemented with using a VM_RedefineClasses operation. ?? So, the VM_RedefineClasses is triggered on behave of a RetransformClasses call from agent code. ?? The capability "can_retransform_classes" has to be possessed to call RetransformClasses. ?? There is no check (and no intent to check) for the capability "can_redefine_classes". 3) The VM_RedefineClasses starts a chain of CFLH's? (per each JvmtiEnv) in both cases above. ?? So that the retransformations (with CFLH's) both RedefineClasses and RetransformClasses calls. ?? If the capability "can_retransform_classes" was not possessed the retransformations ?? caused by RedefineClasses will be processed without problems. ?? It is because both redefine and retransform capabilities are not required for CFLH's. 4) The capability "can_retransform_any_class" was added to allow RetransformClasses calls ?? for any classes including non-modifiable (if the implementation has such a notion). ?? It controls RetransformClasses calls only. 5) As I understand, the capability "can_redefine_any_class" was added to allow ?? RedefineClasses calls for any classes including non-modifiable ?? (if the implementation has such a notion). ?? It should control RedefineClasses only. ?? I do not see why it has to apply to RetransformClasses as well. Could you, explain, please, what is the advantages to apply it to both retransform and redefine? I see only problems/disadvantages with it: D1: The terms "retransform" and "redefine" in this context are confusing. ??? The RetransformClasses is using a VM_RedefineClasses operation. ??? Can we treat this VM_RedefineClasses operation as "redefine"? ??? My guess is that this was initial motivation to list both "retransform" and "redefine" ??? for "can_redefine_any_class" capability. D2: The "can_redefine_classes" and "can_retransform_classes" are equal, ??? but "can_redefine_any_class" and "can_retransform_any_class" are not. ??? There is no symmetry here which adds complexity and generates confusion. D3: The RedefineClasses is controlled with can_redefine_classes and can_redefine_any_class. ??? But the RetransformClasses is controlled with: ????? can_retransform_classes, can_retransform_any_class and can_redefine_any_class. ??? There is no symmetry here which adds complexity and generates confusion. > Further this change should not have been pushed yet as the CSR has not > been approved. Sorry, I confused this bug with another one. This was not pushed yet. Thank you for pointing it out! Thanks, Serguei > > David > ----- > > On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >> Hi Dan and David, >> >> On 5/21/19 15:58, David Holmes wrote: >>> Hi Dan, >>> >>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>> Hi guys, >>>>> >>>>> I've found one more fragment in the IsModifiableClass spec which >>>>> has to be fixed. >>>>> >>>>> >>>>> Updated webrev v2: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>> >>>> >>>> src/hotspot/share/prims/jvmti.xml >>>> ???? No comments. >>>> >>>> Looks like there was a specific update to the spec to allow >>>> can_redefine_any_class >>>> to include retransform (in addition to redefine): >>>> >>>> 1.1.82 >>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class to >>>> include retransform. Clarify that exception events cover all >>>> Throwables. In GetStackTrace, no test is done for start_depth too >>>> big if start_depth is zero, Clarify fields reported in Primitive >>>> Field Callback -- static vs instance. Repair confusing names of >>>> heap types, including callback names. Require consistent usage of >>>> stack depth in the face of thread launch methods. Note >>>> incompatibility of JVM TI memory management with other systems. >>>> >>>> I can't tell if you've chased down that change and why you no longer >>>> think that change is necessary. >>>> >>>> I'm okay with the change, but I think you have more research to do >>>> here. >>> >>> I already chased that down and mentioned it in the CSR. It was done >>> under: >>> >>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>> >>> Unfortunately I misread the original bug description. In relation to >>> can_redefine_any_class it states: >>> >>> A more precise definition would be: >>> ?????? Can retransform or redefine any non-primitive non-array class. >>> >>> It appears to me that they did consider can_redefine_any_class to be >>> a "super" capability that could be added on top of >>> can_redefine_classes to extend it to "any" class; or on top of >>> can_retransform_classes to extend it to "any" class. If so the name >>> choice was unfortunate. >>> >>> Further it seems the implementation never checked this anyway. >> >> Right. >> The approach taken for JDK-6328530 is non-symmetrical and confusing. >> But, I think, I understand why this decision was made. :) >> >> If we ever decide to make some (non-primitive and non-array) classes >> to be non-modifiable then >> I do not see problems to implement it in a way that >> can_redefine_any_class will be checked on >> RedefineClasses only and can_retransform_any_class will be checked on >> RetransformClasses only. >> We will get a symmetry (and so, a simplification as well) in two >> dimensions: >> ?? - between redefine and retransform capabilities >> ?? - between can_redefine_classes and can_redefine_any_class >> capabilities >> >> Thanks, >> Serguei >> >>> >>> David >>> >>>> Dan >>>> >>>> >>>>> Specdiff: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>> >>>>> >>>>> >>>>> Enhancement: >>>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>> >>>>> Related CSR: >>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>> >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for looking at this! >>>>>> >>>>>> >>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>> Please, review a fix for enhancement: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>> >>>>>>>> Related CSR: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>> >>>>>>> I have some comments on the CSR and about this change overall as >>>>>>> to me it is not a simple clarification at all, but potentially a >>>>>>> significant change in the meaning of the capability. >>>>>> >>>>>> >>>>>> I've answered your question in the CSR with my comment. >>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>> >>>>>>> >>>>>>> You introduced a typo: modifialble >>>>>>> >>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>> >>>>>>> 7444???????? >>>>>>> 7445?????????? If possessed then all classes (except primitive, >>>>>>> array, and some implementation defined >>>>>>> 7446?????????? classes) are modifiable (redefine or retransform). >>>>>> >>>>>> Good catch, thanks! >>>>>> I've updated the webrev in place. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>>> >>>>>>>> Summary: >>>>>>>> >>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>> capability spec more inconsistent. >>>>>>>> ?? It is just about a couple of lines. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>> >>>>> >>>> >> From david.holmes at oracle.com Wed May 22 05:36:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 15:36:42 +1000 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> Message-ID: <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> Hi Serguei, Apologies for the confusion around this - and double apologies that you wrote all the below while I was busy going through the history and updating the CSR request with all the relevant details. As I've finally written in the CSR request your change here is correct as it fixes an error/confusion introduced by JDK-6328530 (which itself was confused because of an omission introduced by JDK-6306942; and that omission was rectified by JDK-8145964.) They key end result here is that can_redefine_any_class and can_retransform_any class should be described in exactly the same way other than the redefine/retransform part. This means: - their usage with IsModifiableClass - their usage with RedefineClasses/RetransformClasses - their definitions in the capabilities structure You've addressed the first part here, and the second was already fine, but your change to the third part, while not wrong per-se, uses a different form. You now have: can_redefine_any_class: Can redefine any modifiable class. See IsModifiableClass. (can_redefine_classes must also be set) whereas we already have: can_retransform_any_class: RetransformClasses can be called on any modifiable class. See IsModifiableClass. (can_retransform_classes must also be set) So I recommend instead: can_redefine_any_class: RedefineClasses can be called on any modifiable class. See IsModifiableClass. (can_redefine_classes must also be set) Thanks, David ----- On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 5/21/19 17:25, David Holmes wrote: >> Hi Serguei, >> >> Sorry but I think this "fix" is inappropriate. The capability may be >> badly named but the intent was to have it apply to both redefine and >> retransform. > > Not sure, I fully understand you here. > This intent seemed to be wrong or, at least, it is really confusing to > everybody. > > To understand it better, let's do some analysis first and start from > what we know. > > 1) The JVMTI RedefineClasses is implemented with using a > VM_RedefineClasses operation. > ?? So, the VM_RedefineClasses is triggered on behave of a > RedefineClasses call from agent code. > ?? The capability "can_redefine_classes" has to be possessed to call > RedefineClasses. > > 2) The JVMTI RetransformClasses is also implemented with using a > VM_RedefineClasses operation. > ?? So, the VM_RedefineClasses is triggered on behave of a > RetransformClasses call from agent code. > ?? The capability "can_retransform_classes" has to be possessed to call > RetransformClasses. > ?? There is no check (and no intent to check) for the capability > "can_redefine_classes". > > 3) The VM_RedefineClasses starts a chain of CFLH's? (per each JvmtiEnv) > in both cases above. > ?? So that the retransformations (with CFLH's) both RedefineClasses and > RetransformClasses calls. > ?? If the capability "can_retransform_classes" was not possessed the > retransformations > ?? caused by RedefineClasses will be processed without problems. > ?? It is because both redefine and retransform capabilities are not > required for CFLH's. > > 4) The capability "can_retransform_any_class" was added to allow > RetransformClasses calls > ?? for any classes including non-modifiable (if the implementation has > such a notion). > ?? It controls RetransformClasses calls only. > > 5) As I understand, the capability "can_redefine_any_class" was added to > allow > ?? RedefineClasses calls for any classes including non-modifiable > ?? (if the implementation has such a notion). > ?? It should control RedefineClasses only. > ?? I do not see why it has to apply to RetransformClasses as well. > > > Could you, explain, please, what is the advantages to apply it to both > retransform and redefine? > > I see only problems/disadvantages with it: > > D1: The terms "retransform" and "redefine" in this context are confusing. > ??? The RetransformClasses is using a VM_RedefineClasses operation. > ??? Can we treat this VM_RedefineClasses operation as "redefine"? > ??? My guess is that this was initial motivation to list both > "retransform" and "redefine" > ??? for "can_redefine_any_class" capability. > > D2: The "can_redefine_classes" and "can_retransform_classes" are equal, > ??? but "can_redefine_any_class" and "can_retransform_any_class" are not. > ??? There is no symmetry here which adds complexity and generates > confusion. > > D3: The RedefineClasses is controlled with can_redefine_classes and > can_redefine_any_class. > ??? But the RetransformClasses is controlled with: > ????? can_retransform_classes, can_retransform_any_class and > can_redefine_any_class. > ??? There is no symmetry here which adds complexity and generates > confusion. > > >> Further this change should not have been pushed yet as the CSR has not >> been approved. > > Sorry, I confused this bug with another one. > This was not pushed yet. > Thank you for pointing it out! > > Thanks, > Serguei > > >> >> David >> ----- >> >> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>> Hi Dan and David, >>> >>> On 5/21/19 15:58, David Holmes wrote: >>>> Hi Dan, >>>> >>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi guys, >>>>>> >>>>>> I've found one more fragment in the IsModifiableClass spec which >>>>>> has to be fixed. >>>>>> >>>>>> >>>>>> Updated webrev v2: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>> >>>>> >>>>> src/hotspot/share/prims/jvmti.xml >>>>> ???? No comments. >>>>> >>>>> Looks like there was a specific update to the spec to allow >>>>> can_redefine_any_class >>>>> to include retransform (in addition to redefine): >>>>> >>>>> 1.1.82 >>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class to >>>>> include retransform. Clarify that exception events cover all >>>>> Throwables. In GetStackTrace, no test is done for start_depth too >>>>> big if start_depth is zero, Clarify fields reported in Primitive >>>>> Field Callback -- static vs instance. Repair confusing names of >>>>> heap types, including callback names. Require consistent usage of >>>>> stack depth in the face of thread launch methods. Note >>>>> incompatibility of JVM TI memory management with other systems. >>>>> >>>>> I can't tell if you've chased down that change and why you no longer >>>>> think that change is necessary. >>>>> >>>>> I'm okay with the change, but I think you have more research to do >>>>> here. >>>> >>>> I already chased that down and mentioned it in the CSR. It was done >>>> under: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>> >>>> Unfortunately I misread the original bug description. In relation to >>>> can_redefine_any_class it states: >>>> >>>> A more precise definition would be: >>>> ?????? Can retransform or redefine any non-primitive non-array class. >>>> >>>> It appears to me that they did consider can_redefine_any_class to be >>>> a "super" capability that could be added on top of >>>> can_redefine_classes to extend it to "any" class; or on top of >>>> can_retransform_classes to extend it to "any" class. If so the name >>>> choice was unfortunate. >>>> >>>> Further it seems the implementation never checked this anyway. >>> >>> Right. >>> The approach taken for JDK-6328530 is non-symmetrical and confusing. >>> But, I think, I understand why this decision was made. :) >>> >>> If we ever decide to make some (non-primitive and non-array) classes >>> to be non-modifiable then >>> I do not see problems to implement it in a way that >>> can_redefine_any_class will be checked on >>> RedefineClasses only and can_retransform_any_class will be checked on >>> RetransformClasses only. >>> We will get a symmetry (and so, a simplification as well) in two >>> dimensions: >>> ?? - between redefine and retransform capabilities >>> ?? - between can_redefine_classes and can_redefine_any_class >>> capabilities >>> >>> Thanks, >>> Serguei >>> >>>> >>>> David >>>> >>>>> Dan >>>>> >>>>> >>>>>> Specdiff: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>> >>>>>> >>>>>> >>>>>> Enhancement: >>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>> >>>>>> Related CSR: >>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thank you for looking at this! >>>>>>> >>>>>>> >>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>> Hi Serguei, >>>>>>>> >>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Please, review a fix for enhancement: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>> >>>>>>>>> Related CSR: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>> >>>>>>>> I have some comments on the CSR and about this change overall as >>>>>>>> to me it is not a simple clarification at all, but potentially a >>>>>>>> significant change in the meaning of the capability. >>>>>>> >>>>>>> >>>>>>> I've answered your question in the CSR with my comment. >>>>>>> >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>> >>>>>>>> >>>>>>>> You introduced a typo: modifialble >>>>>>>> >>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>> >>>>>>>> 7444???????? >>>>>>>> 7445?????????? If possessed then all classes (except primitive, >>>>>>>> array, and some implementation defined >>>>>>>> 7446?????????? classes) are modifiable (redefine or retransform). >>>>>>> >>>>>>> Good catch, thanks! >>>>>>> I've updated the webrev in place. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> >>>>>>>>> Summary: >>>>>>>>> >>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>> capability spec more inconsistent. >>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>> >>>>>> >>>>> >>> > From serguei.spitsyn at oracle.com Wed May 22 10:55:53 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 May 2019 03:55:53 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> Message-ID: <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> Hi David, On 5/21/19 22:36, David Holmes wrote: > Hi Serguei, > > Apologies for the confusion around this - and double apologies that > you wrote all the below while I was busy going through the history and > updating the CSR request with all the relevant details. No apologies are accepted. :) The topic is confusing for me too. Thank you for checking all this as it is the best way to make it right! I really appreciate it. > As I've finally written in the CSR request your change here is correct > as it fixes an error/confusion introduced by JDK-6328530 (which itself > was confused because of an omission introduced by JDK-6306942; and > that omission was rectified by JDK-8145964.) > > They key end result here is that can_redefine_any_class and > can_retransform_any class should be described in exactly the same way > other than the redefine/retransform part. This means: > > - their usage with IsModifiableClass > - their usage with RedefineClasses/RetransformClasses > - their definitions in the capabilities structure > > You've addressed the first part here, and the second was already fine, > but your change to the third part, while not wrong per-se, uses a > different form. You now have: > > can_redefine_any_class: Can redefine any modifiable class. See > IsModifiableClass. (can_redefine_classes must also be set) > > whereas we already have: > > can_retransform_any_class: RetransformClasses can be called on any > modifiable class. See IsModifiableClass. (can_retransform_classes must > also be set) > > So I recommend instead: > > can_redefine_any_class: RedefineClasses can be called on any > modifiable class. See IsModifiableClass. (can_redefine_classes must > also be set) Agreed, thanks! When looked at the spec again I came to the same conclusion. I've updated the CSR with this suggestion. Also, please, find the latest versions below: Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ JVMTI spec: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti.html JVMTI spec diff: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti-specdiff/ Enhancement: https://bugs.openjdk.java.net/browse/JDK-8046018 Related CSR: https://bugs.openjdk.java.net/browse/JDK-8223915 Thanks, Serguei > Thanks, > David > ----- > > On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 5/21/19 17:25, David Holmes wrote: >>> Hi Serguei, >>> >>> Sorry but I think this "fix" is inappropriate. The capability may be >>> badly named but the intent was to have it apply to both redefine and >>> retransform. >> >> Not sure, I fully understand you here. >> This intent seemed to be wrong or, at least, it is really confusing >> to everybody. >> >> To understand it better, let's do some analysis first and start from >> what we know. >> >> 1) The JVMTI RedefineClasses is implemented with using a >> VM_RedefineClasses operation. >> ??? So, the VM_RedefineClasses is triggered on behave of a >> RedefineClasses call from agent code. >> ??? The capability "can_redefine_classes" has to be possessed to call >> RedefineClasses. >> >> 2) The JVMTI RetransformClasses is also implemented with using a >> VM_RedefineClasses operation. >> ??? So, the VM_RedefineClasses is triggered on behave of a >> RetransformClasses call from agent code. >> ??? The capability "can_retransform_classes" has to be possessed to >> call RetransformClasses. >> ??? There is no check (and no intent to check) for the capability >> "can_redefine_classes". >> >> 3) The VM_RedefineClasses starts a chain of CFLH's? (per each >> JvmtiEnv) in both cases above. >> ??? So that the retransformations (with CFLH's) both RedefineClasses >> and RetransformClasses calls. >> ??? If the capability "can_retransform_classes" was not possessed the >> retransformations >> ??? caused by RedefineClasses will be processed without problems. >> ??? It is because both redefine and retransform capabilities are not >> required for CFLH's. >> >> 4) The capability "can_retransform_any_class" was added to allow >> RetransformClasses calls >> ??? for any classes including non-modifiable (if the implementation >> has such a notion). >> ??? It controls RetransformClasses calls only. >> >> 5) As I understand, the capability "can_redefine_any_class" was added >> to allow >> ??? RedefineClasses calls for any classes including non-modifiable >> ??? (if the implementation has such a notion). >> ??? It should control RedefineClasses only. >> ??? I do not see why it has to apply to RetransformClasses as well. >> >> >> Could you, explain, please, what is the advantages to apply it to >> both retransform and redefine? >> >> I see only problems/disadvantages with it: >> >> D1: The terms "retransform" and "redefine" in this context are >> confusing. >> ???? The RetransformClasses is using a VM_RedefineClasses operation. >> ???? Can we treat this VM_RedefineClasses operation as "redefine"? >> ???? My guess is that this was initial motivation to list both >> "retransform" and "redefine" >> ???? for "can_redefine_any_class" capability. >> >> D2: The "can_redefine_classes" and "can_retransform_classes" are equal, >> ???? but "can_redefine_any_class" and "can_retransform_any_class" are >> not. >> ???? There is no symmetry here which adds complexity and generates >> confusion. >> >> D3: The RedefineClasses is controlled with can_redefine_classes and >> can_redefine_any_class. >> ???? But the RetransformClasses is controlled with: >> ?????? can_retransform_classes, can_retransform_any_class and >> can_redefine_any_class. >> ???? There is no symmetry here which adds complexity and generates >> confusion. >> >> >>> Further this change should not have been pushed yet as the CSR has >>> not been approved. >> >> Sorry, I confused this bug with another one. >> This was not pushed yet. >> Thank you for pointing it out! >> >> Thanks, >> Serguei >> >> >>> >>> David >>> ----- >>> >>> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>>> Hi Dan and David, >>>> >>>> On 5/21/19 15:58, David Holmes wrote: >>>>> Hi Dan, >>>>> >>>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> I've found one more fragment in the IsModifiableClass spec which >>>>>>> has to be fixed. >>>>>>> >>>>>>> >>>>>>> Updated webrev v2: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>>> >>>>>> >>>>>> src/hotspot/share/prims/jvmti.xml >>>>>> ???? No comments. >>>>>> >>>>>> Looks like there was a specific update to the spec to allow >>>>>> can_redefine_any_class >>>>>> to include retransform (in addition to redefine): >>>>>> >>>>>> 1.1.82 >>>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class to >>>>>> include retransform. Clarify that exception events cover all >>>>>> Throwables. In GetStackTrace, no test is done for start_depth too >>>>>> big if start_depth is zero, Clarify fields reported in Primitive >>>>>> Field Callback -- static vs instance. Repair confusing names of >>>>>> heap types, including callback names. Require consistent usage of >>>>>> stack depth in the face of thread launch methods. Note >>>>>> incompatibility of JVM TI memory management with other systems. >>>>>> >>>>>> I can't tell if you've chased down that change and why you no longer >>>>>> think that change is necessary. >>>>>> >>>>>> I'm okay with the change, but I think you have more research to >>>>>> do here. >>>>> >>>>> I already chased that down and mentioned it in the CSR. It was >>>>> done under: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>>> >>>>> Unfortunately I misread the original bug description. In relation >>>>> to can_redefine_any_class it states: >>>>> >>>>> A more precise definition would be: >>>>> ?????? Can retransform or redefine any non-primitive non-array class. >>>>> >>>>> It appears to me that they did consider can_redefine_any_class to >>>>> be a "super" capability that could be added on top of >>>>> can_redefine_classes to extend it to "any" class; or on top of >>>>> can_retransform_classes to extend it to "any" class. If so the >>>>> name choice was unfortunate. >>>>> >>>>> Further it seems the implementation never checked this anyway. >>>> >>>> Right. >>>> The approach taken for JDK-6328530 is non-symmetrical and confusing. >>>> But, I think, I understand why this decision was made. :) >>>> >>>> If we ever decide to make some (non-primitive and non-array) >>>> classes to be non-modifiable then >>>> I do not see problems to implement it in a way that >>>> can_redefine_any_class will be checked on >>>> RedefineClasses only and can_retransform_any_class will be checked >>>> on RetransformClasses only. >>>> We will get a symmetry (and so, a simplification as well) in two >>>> dimensions: >>>> ?? - between redefine and retransform capabilities >>>> ?? - between can_redefine_classes and can_redefine_any_class >>>> capabilities >>>> >>>> Thanks, >>>> Serguei >>>> >>>>> >>>>> David >>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> Specdiff: >>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Enhancement: >>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>> >>>>>>> Related CSR: >>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thank you for looking at this! >>>>>>>> >>>>>>>> >>>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>>> Hi Serguei, >>>>>>>>> >>>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Please, review a fix for enhancement: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>> >>>>>>>>>> Related CSR: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>> >>>>>>>>> I have some comments on the CSR and about this change overall >>>>>>>>> as to me it is not a simple clarification at all, but >>>>>>>>> potentially a significant change in the meaning of the >>>>>>>>> capability. >>>>>>>> >>>>>>>> >>>>>>>> I've answered your question in the CSR with my comment. >>>>>>>> >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> You introduced a typo: modifialble >>>>>>>>> >>>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>>> >>>>>>>>> 7444???????? >>>>>>>>> 7445?????????? If possessed then all classes (except >>>>>>>>> primitive, array, and some implementation defined >>>>>>>>> 7446?????????? classes) are modifiable (redefine or retransform). >>>>>>>> >>>>>>>> Good catch, thanks! >>>>>>>> I've updated the webrev in place. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Summary: >>>>>>>>>> >>>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>>> capability spec more inconsistent. >>>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>> >>>>>>> >>>>>> >>>> >> From david.holmes at oracle.com Wed May 22 11:49:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 May 2019 21:49:44 +1000 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> Message-ID: <3b71fdaf-ebfd-62ea-410e-977cd9bcb1c3@oracle.com> Hi Serguei, This final version looks good! Thanks, David ----- On 22/05/2019 8:55 pm, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 5/21/19 22:36, David Holmes wrote: >> Hi Serguei, >> >> Apologies for the confusion around this - and double apologies that >> you wrote all the below while I was busy going through the history and >> updating the CSR request with all the relevant details. > > > No apologies are accepted. :) > The topic is confusing for me too. > Thank you for checking all this as it is the best way to make it right! > I really appreciate it. > > >> As I've finally written in the CSR request your change here is correct >> as it fixes an error/confusion introduced by JDK-6328530 (which itself >> was confused because of an omission introduced by JDK-6306942; and >> that omission was rectified by JDK-8145964.) >> >> They key end result here is that can_redefine_any_class and >> can_retransform_any class should be described in exactly the same way >> other than the redefine/retransform part. This means: >> >> - their usage with IsModifiableClass >> - their usage with RedefineClasses/RetransformClasses >> - their definitions in the capabilities structure >> >> You've addressed the first part here, and the second was already fine, >> but your change to the third part, while not wrong per-se, uses a >> different form. You now have: >> >> can_redefine_any_class: Can redefine any modifiable class. See >> IsModifiableClass. (can_redefine_classes must also be set) >> >> whereas we already have: >> >> can_retransform_any_class: RetransformClasses can be called on any >> modifiable class. See IsModifiableClass. (can_retransform_classes must >> also be set) >> >> So I recommend instead: >> >> can_redefine_any_class: RedefineClasses can be called on any >> modifiable class. See IsModifiableClass. (can_redefine_classes must >> also be set) > > Agreed, thanks! > When looked at the spec again I came to the same conclusion. > I've updated the CSR with this suggestion. > > Also, please, find the latest versions below: > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ > > JVMTI spec: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti.html > > > JVMTI spec diff: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti-specdiff/ > > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8046018 > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223915 > > > Thanks, > Serguei > > >> Thanks, >> David >> ----- >> >> On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 5/21/19 17:25, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Sorry but I think this "fix" is inappropriate. The capability may be >>>> badly named but the intent was to have it apply to both redefine and >>>> retransform. >>> >>> Not sure, I fully understand you here. >>> This intent seemed to be wrong or, at least, it is really confusing >>> to everybody. >>> >>> To understand it better, let's do some analysis first and start from >>> what we know. >>> >>> 1) The JVMTI RedefineClasses is implemented with using a >>> VM_RedefineClasses operation. >>> ??? So, the VM_RedefineClasses is triggered on behave of a >>> RedefineClasses call from agent code. >>> ??? The capability "can_redefine_classes" has to be possessed to call >>> RedefineClasses. >>> >>> 2) The JVMTI RetransformClasses is also implemented with using a >>> VM_RedefineClasses operation. >>> ??? So, the VM_RedefineClasses is triggered on behave of a >>> RetransformClasses call from agent code. >>> ??? The capability "can_retransform_classes" has to be possessed to >>> call RetransformClasses. >>> ??? There is no check (and no intent to check) for the capability >>> "can_redefine_classes". >>> >>> 3) The VM_RedefineClasses starts a chain of CFLH's? (per each >>> JvmtiEnv) in both cases above. >>> ??? So that the retransformations (with CFLH's) both RedefineClasses >>> and RetransformClasses calls. >>> ??? If the capability "can_retransform_classes" was not possessed the >>> retransformations >>> ??? caused by RedefineClasses will be processed without problems. >>> ??? It is because both redefine and retransform capabilities are not >>> required for CFLH's. >>> >>> 4) The capability "can_retransform_any_class" was added to allow >>> RetransformClasses calls >>> ??? for any classes including non-modifiable (if the implementation >>> has such a notion). >>> ??? It controls RetransformClasses calls only. >>> >>> 5) As I understand, the capability "can_redefine_any_class" was added >>> to allow >>> ??? RedefineClasses calls for any classes including non-modifiable >>> ??? (if the implementation has such a notion). >>> ??? It should control RedefineClasses only. >>> ??? I do not see why it has to apply to RetransformClasses as well. >>> >>> >>> Could you, explain, please, what is the advantages to apply it to >>> both retransform and redefine? >>> >>> I see only problems/disadvantages with it: >>> >>> D1: The terms "retransform" and "redefine" in this context are >>> confusing. >>> ???? The RetransformClasses is using a VM_RedefineClasses operation. >>> ???? Can we treat this VM_RedefineClasses operation as "redefine"? >>> ???? My guess is that this was initial motivation to list both >>> "retransform" and "redefine" >>> ???? for "can_redefine_any_class" capability. >>> >>> D2: The "can_redefine_classes" and "can_retransform_classes" are equal, >>> ???? but "can_redefine_any_class" and "can_retransform_any_class" are >>> not. >>> ???? There is no symmetry here which adds complexity and generates >>> confusion. >>> >>> D3: The RedefineClasses is controlled with can_redefine_classes and >>> can_redefine_any_class. >>> ???? But the RetransformClasses is controlled with: >>> ?????? can_retransform_classes, can_retransform_any_class and >>> can_redefine_any_class. >>> ???? There is no symmetry here which adds complexity and generates >>> confusion. >>> >>> >>>> Further this change should not have been pushed yet as the CSR has >>>> not been approved. >>> >>> Sorry, I confused this bug with another one. >>> This was not pushed yet. >>> Thank you for pointing it out! >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> David >>>> ----- >>>> >>>> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dan and David, >>>>> >>>>> On 5/21/19 15:58, David Holmes wrote: >>>>>> Hi Dan, >>>>>> >>>>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> I've found one more fragment in the IsModifiableClass spec which >>>>>>>> has to be fixed. >>>>>>>> >>>>>>>> >>>>>>>> Updated webrev v2: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>>>> >>>>>>> >>>>>>> src/hotspot/share/prims/jvmti.xml >>>>>>> ???? No comments. >>>>>>> >>>>>>> Looks like there was a specific update to the spec to allow >>>>>>> can_redefine_any_class >>>>>>> to include retransform (in addition to redefine): >>>>>>> >>>>>>> 1.1.82 >>>>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class to >>>>>>> include retransform. Clarify that exception events cover all >>>>>>> Throwables. In GetStackTrace, no test is done for start_depth too >>>>>>> big if start_depth is zero, Clarify fields reported in Primitive >>>>>>> Field Callback -- static vs instance. Repair confusing names of >>>>>>> heap types, including callback names. Require consistent usage of >>>>>>> stack depth in the face of thread launch methods. Note >>>>>>> incompatibility of JVM TI memory management with other systems. >>>>>>> >>>>>>> I can't tell if you've chased down that change and why you no longer >>>>>>> think that change is necessary. >>>>>>> >>>>>>> I'm okay with the change, but I think you have more research to >>>>>>> do here. >>>>>> >>>>>> I already chased that down and mentioned it in the CSR. It was >>>>>> done under: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>>>> >>>>>> Unfortunately I misread the original bug description. In relation >>>>>> to can_redefine_any_class it states: >>>>>> >>>>>> A more precise definition would be: >>>>>> ?????? Can retransform or redefine any non-primitive non-array class. >>>>>> >>>>>> It appears to me that they did consider can_redefine_any_class to >>>>>> be a "super" capability that could be added on top of >>>>>> can_redefine_classes to extend it to "any" class; or on top of >>>>>> can_retransform_classes to extend it to "any" class. If so the >>>>>> name choice was unfortunate. >>>>>> >>>>>> Further it seems the implementation never checked this anyway. >>>>> >>>>> Right. >>>>> The approach taken for JDK-6328530 is non-symmetrical and confusing. >>>>> But, I think, I understand why this decision was made. :) >>>>> >>>>> If we ever decide to make some (non-primitive and non-array) >>>>> classes to be non-modifiable then >>>>> I do not see problems to implement it in a way that >>>>> can_redefine_any_class will be checked on >>>>> RedefineClasses only and can_retransform_any_class will be checked >>>>> on RetransformClasses only. >>>>> We will get a symmetry (and so, a simplification as well) in two >>>>> dimensions: >>>>> ?? - between redefine and retransform capabilities >>>>> ?? - between can_redefine_classes and can_redefine_any_class >>>>> capabilities >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> Specdiff: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Enhancement: >>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>> >>>>>>>> Related CSR: >>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thank you for looking at this! >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review a fix for enhancement: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>>> >>>>>>>>>>> Related CSR: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>> >>>>>>>>>> I have some comments on the CSR and about this change overall >>>>>>>>>> as to me it is not a simple clarification at all, but >>>>>>>>>> potentially a significant change in the meaning of the >>>>>>>>>> capability. >>>>>>>>> >>>>>>>>> >>>>>>>>> I've answered your question in the CSR with my comment. >>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You introduced a typo: modifialble >>>>>>>>>> >>>>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>>>> >>>>>>>>>> 7444???????? >>>>>>>>>> 7445?????????? If possessed then all classes (except >>>>>>>>>> primitive, array, and some implementation defined >>>>>>>>>> 7446?????????? classes) are modifiable (redefine or retransform). >>>>>>>>> >>>>>>>>> Good catch, thanks! >>>>>>>>> I've updated the webrev in place. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> >>>>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>>>> capability spec more inconsistent. >>>>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From thomas.stuefe at gmail.com Wed May 22 11:50:09 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 22 May 2019 13:50:09 +0200 Subject: RFR: CSR: 8224601: Provide VM.events diagnostic command Message-ID: Hi all, could I please have opinions and a reviewer for the following CSR: https://bugs.openjdk.java.net/browse/JDK-8224601 which aims to add a dedicated "VM.events" command to jcmd to print out event logs. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Wed May 22 14:00:38 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 May 2019 10:00:38 -0400 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> Message-ID: <2d138d94-7b8b-d35d-990b-7d27481a314b@oracle.com> > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ Thumbs up on this version. I did add a historical note to the CSR... Dan On 5/22/19 6:55 AM, serguei.spitsyn at oracle.com wrote: > Hi David, > > > On 5/21/19 22:36, David Holmes wrote: >> Hi Serguei, >> >> Apologies for the confusion around this - and double apologies that >> you wrote all the below while I was busy going through the history >> and updating the CSR request with all the relevant details. > > > No apologies are accepted. :) > The topic is confusing for me too. > Thank you for checking all this as it is the best way to make it right! > I really appreciate it. > > >> As I've finally written in the CSR request your change here is >> correct as it fixes an error/confusion introduced by JDK-6328530 >> (which itself was confused because of an omission introduced by >> JDK-6306942; and that omission was rectified by JDK-8145964.) >> >> They key end result here is that can_redefine_any_class and >> can_retransform_any class should be described in exactly the same way >> other than the redefine/retransform part. This means: >> >> - their usage with IsModifiableClass >> - their usage with RedefineClasses/RetransformClasses >> - their definitions in the capabilities structure >> >> You've addressed the first part here, and the second was already >> fine, but your change to the third part, while not wrong per-se, uses >> a different form. You now have: >> >> can_redefine_any_class: Can redefine any modifiable class. See >> IsModifiableClass. (can_redefine_classes must also be set) >> >> whereas we already have: >> >> can_retransform_any_class: RetransformClasses can be called on any >> modifiable class. See IsModifiableClass. (can_retransform_classes >> must also be set) >> >> So I recommend instead: >> >> can_redefine_any_class: RedefineClasses can be called on any >> modifiable class. See IsModifiableClass. (can_redefine_classes must >> also be set) > > Agreed, thanks! > When looked at the spec again I came to the same conclusion. > I've updated the CSR with this suggestion. > > Also, please, find the latest versions below: > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ > > > JVMTI spec: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti.html > > > JVMTI spec diff: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti-specdiff/ > > > Enhancement: > https://bugs.openjdk.java.net/browse/JDK-8046018 > > Related CSR: > https://bugs.openjdk.java.net/browse/JDK-8223915 > > > Thanks, > Serguei > > >> Thanks, >> David >> ----- >> >> On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 5/21/19 17:25, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Sorry but I think this "fix" is inappropriate. The capability may >>>> be badly named but the intent was to have it apply to both redefine >>>> and retransform. >>> >>> Not sure, I fully understand you here. >>> This intent seemed to be wrong or, at least, it is really confusing >>> to everybody. >>> >>> To understand it better, let's do some analysis first and start from >>> what we know. >>> >>> 1) The JVMTI RedefineClasses is implemented with using a >>> VM_RedefineClasses operation. >>> ??? So, the VM_RedefineClasses is triggered on behave of a >>> RedefineClasses call from agent code. >>> ??? The capability "can_redefine_classes" has to be possessed to >>> call RedefineClasses. >>> >>> 2) The JVMTI RetransformClasses is also implemented with using a >>> VM_RedefineClasses operation. >>> ??? So, the VM_RedefineClasses is triggered on behave of a >>> RetransformClasses call from agent code. >>> ??? The capability "can_retransform_classes" has to be possessed to >>> call RetransformClasses. >>> ??? There is no check (and no intent to check) for the capability >>> "can_redefine_classes". >>> >>> 3) The VM_RedefineClasses starts a chain of CFLH's? (per each >>> JvmtiEnv) in both cases above. >>> ??? So that the retransformations (with CFLH's) both RedefineClasses >>> and RetransformClasses calls. >>> ??? If the capability "can_retransform_classes" was not possessed >>> the retransformations >>> ??? caused by RedefineClasses will be processed without problems. >>> ??? It is because both redefine and retransform capabilities are not >>> required for CFLH's. >>> >>> 4) The capability "can_retransform_any_class" was added to allow >>> RetransformClasses calls >>> ??? for any classes including non-modifiable (if the implementation >>> has such a notion). >>> ??? It controls RetransformClasses calls only. >>> >>> 5) As I understand, the capability "can_redefine_any_class" was >>> added to allow >>> ??? RedefineClasses calls for any classes including non-modifiable >>> ??? (if the implementation has such a notion). >>> ??? It should control RedefineClasses only. >>> ??? I do not see why it has to apply to RetransformClasses as well. >>> >>> >>> Could you, explain, please, what is the advantages to apply it to >>> both retransform and redefine? >>> >>> I see only problems/disadvantages with it: >>> >>> D1: The terms "retransform" and "redefine" in this context are >>> confusing. >>> ???? The RetransformClasses is using a VM_RedefineClasses operation. >>> ???? Can we treat this VM_RedefineClasses operation as "redefine"? >>> ???? My guess is that this was initial motivation to list both >>> "retransform" and "redefine" >>> ???? for "can_redefine_any_class" capability. >>> >>> D2: The "can_redefine_classes" and "can_retransform_classes" are equal, >>> ???? but "can_redefine_any_class" and "can_retransform_any_class" >>> are not. >>> ???? There is no symmetry here which adds complexity and generates >>> confusion. >>> >>> D3: The RedefineClasses is controlled with can_redefine_classes and >>> can_redefine_any_class. >>> ???? But the RetransformClasses is controlled with: >>> ?????? can_retransform_classes, can_retransform_any_class and >>> can_redefine_any_class. >>> ???? There is no symmetry here which adds complexity and generates >>> confusion. >>> >>> >>>> Further this change should not have been pushed yet as the CSR has >>>> not been approved. >>> >>> Sorry, I confused this bug with another one. >>> This was not pushed yet. >>> Thank you for pointing it out! >>> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> David >>>> ----- >>>> >>>> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>>>> Hi Dan and David, >>>>> >>>>> On 5/21/19 15:58, David Holmes wrote: >>>>>> Hi Dan, >>>>>> >>>>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> I've found one more fragment in the IsModifiableClass spec >>>>>>>> which has to be fixed. >>>>>>>> >>>>>>>> >>>>>>>> Updated webrev v2: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>>>> >>>>>>> >>>>>>> src/hotspot/share/prims/jvmti.xml >>>>>>> ???? No comments. >>>>>>> >>>>>>> Looks like there was a specific update to the spec to allow >>>>>>> can_redefine_any_class >>>>>>> to include retransform (in addition to redefine): >>>>>>> >>>>>>> 1.1.82 >>>>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class to >>>>>>> include retransform. Clarify that exception events cover all >>>>>>> Throwables. In GetStackTrace, no test is done for start_depth >>>>>>> too big if start_depth is zero, Clarify fields reported in >>>>>>> Primitive Field Callback -- static vs instance. Repair confusing >>>>>>> names of heap types, including callback names. Require >>>>>>> consistent usage of stack depth in the face of thread launch >>>>>>> methods. Note incompatibility of JVM TI memory management with >>>>>>> other systems. >>>>>>> >>>>>>> I can't tell if you've chased down that change and why you no >>>>>>> longer >>>>>>> think that change is necessary. >>>>>>> >>>>>>> I'm okay with the change, but I think you have more research to >>>>>>> do here. >>>>>> >>>>>> I already chased that down and mentioned it in the CSR. It was >>>>>> done under: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>>>> >>>>>> Unfortunately I misread the original bug description. In relation >>>>>> to can_redefine_any_class it states: >>>>>> >>>>>> A more precise definition would be: >>>>>> ?????? Can retransform or redefine any non-primitive non-array >>>>>> class. >>>>>> >>>>>> It appears to me that they did consider can_redefine_any_class to >>>>>> be a "super" capability that could be added on top of >>>>>> can_redefine_classes to extend it to "any" class; or on top of >>>>>> can_retransform_classes to extend it to "any" class. If so the >>>>>> name choice was unfortunate. >>>>>> >>>>>> Further it seems the implementation never checked this anyway. >>>>> >>>>> Right. >>>>> The approach taken for JDK-6328530 is non-symmetrical and confusing. >>>>> But, I think, I understand why this decision was made. :) >>>>> >>>>> If we ever decide to make some (non-primitive and non-array) >>>>> classes to be non-modifiable then >>>>> I do not see problems to implement it in a way that >>>>> can_redefine_any_class will be checked on >>>>> RedefineClasses only and can_retransform_any_class will be checked >>>>> on RetransformClasses only. >>>>> We will get a symmetry (and so, a simplification as well) in two >>>>> dimensions: >>>>> ?? - between redefine and retransform capabilities >>>>> ?? - between can_redefine_classes and can_redefine_any_class >>>>> capabilities >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>>> >>>>>> David >>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>>> Specdiff: >>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Enhancement: >>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>> >>>>>>>> Related CSR: >>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Thank you for looking at this! >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>>>> Hi Serguei, >>>>>>>>>> >>>>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Please, review a fix for enhancement: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>>> >>>>>>>>>>> Related CSR: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>> >>>>>>>>>> I have some comments on the CSR and about this change overall >>>>>>>>>> as to me it is not a simple clarification at all, but >>>>>>>>>> potentially a significant change in the meaning of the >>>>>>>>>> capability. >>>>>>>>> >>>>>>>>> >>>>>>>>> I've answered your question in the CSR with my comment. >>>>>>>>> >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You introduced a typo: modifialble >>>>>>>>>> >>>>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>>>> >>>>>>>>>> 7444???????? >>>>>>>>>> 7445?????????? If possessed then all classes (except >>>>>>>>>> primitive, array, and some implementation defined >>>>>>>>>> 7446?????????? classes) are modifiable (redefine or >>>>>>>>>> retransform). >>>>>>>>> >>>>>>>>> Good catch, thanks! >>>>>>>>> I've updated the webrev in place. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Summary: >>>>>>>>>>> >>>>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>>>> capability spec more inconsistent. >>>>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> > From serguei.spitsyn at oracle.com Wed May 22 17:36:38 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 May 2019 10:36:38 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <3b71fdaf-ebfd-62ea-410e-977cd9bcb1c3@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> <3b71fdaf-ebfd-62ea-410e-977cd9bcb1c3@oracle.com> Message-ID: <423fca5a-e119-c5eb-cb7d-f3fcff2b95d7@oracle.com> Thanks, David! Serguei On 5/22/19 04:49, David Holmes wrote: > Hi Serguei, > > This final version looks good! > > Thanks, > David > ----- > > On 22/05/2019 8:55 pm, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 5/21/19 22:36, David Holmes wrote: >>> Hi Serguei, >>> >>> Apologies for the confusion around this - and double apologies that >>> you wrote all the below while I was busy going through the history >>> and updating the CSR request with all the relevant details. >> >> >> No apologies are accepted. :) >> The topic is confusing for me too. >> Thank you for checking all this as it is the best way to make it right! >> I really appreciate it. >> >> >>> As I've finally written in the CSR request your change here is >>> correct as it fixes an error/confusion introduced by JDK-6328530 >>> (which itself was confused because of an omission introduced by >>> JDK-6306942; and that omission was rectified by JDK-8145964.) >>> >>> They key end result here is that can_redefine_any_class and >>> can_retransform_any class should be described in exactly the same >>> way other than the redefine/retransform part. This means: >>> >>> - their usage with IsModifiableClass >>> - their usage with RedefineClasses/RetransformClasses >>> - their definitions in the capabilities structure >>> >>> You've addressed the first part here, and the second was already >>> fine, but your change to the third part, while not wrong per-se, >>> uses a different form. You now have: >>> >>> can_redefine_any_class: Can redefine any modifiable class. See >>> IsModifiableClass. (can_redefine_classes must also be set) >>> >>> whereas we already have: >>> >>> can_retransform_any_class: RetransformClasses can be called on any >>> modifiable class. See IsModifiableClass. (can_retransform_classes >>> must also be set) >>> >>> So I recommend instead: >>> >>> can_redefine_any_class: RedefineClasses can be called on any >>> modifiable class. See IsModifiableClass. (can_redefine_classes must >>> also be set) >> >> Agreed, thanks! >> When looked at the spec again I came to the same conclusion. >> I've updated the CSR with this suggestion. >> >> Also, please, find the latest versions below: >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ >> >> >> JVMTI spec: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti.html >> >> >> JVMTI spec diff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti-specdiff/ >> >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8046018 >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223915 >> >> >> Thanks, >> Serguei >> >> >>> Thanks, >>> David >>> ----- >>> >>> On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> >>>> On 5/21/19 17:25, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Sorry but I think this "fix" is inappropriate. The capability may >>>>> be badly named but the intent was to have it apply to both >>>>> redefine and retransform. >>>> >>>> Not sure, I fully understand you here. >>>> This intent seemed to be wrong or, at least, it is really confusing >>>> to everybody. >>>> >>>> To understand it better, let's do some analysis first and start >>>> from what we know. >>>> >>>> 1) The JVMTI RedefineClasses is implemented with using a >>>> VM_RedefineClasses operation. >>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>> RedefineClasses call from agent code. >>>> ??? The capability "can_redefine_classes" has to be possessed to >>>> call RedefineClasses. >>>> >>>> 2) The JVMTI RetransformClasses is also implemented with using a >>>> VM_RedefineClasses operation. >>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>> RetransformClasses call from agent code. >>>> ??? The capability "can_retransform_classes" has to be possessed to >>>> call RetransformClasses. >>>> ??? There is no check (and no intent to check) for the capability >>>> "can_redefine_classes". >>>> >>>> 3) The VM_RedefineClasses starts a chain of CFLH's? (per each >>>> JvmtiEnv) in both cases above. >>>> ??? So that the retransformations (with CFLH's) both >>>> RedefineClasses and RetransformClasses calls. >>>> ??? If the capability "can_retransform_classes" was not possessed >>>> the retransformations >>>> ??? caused by RedefineClasses will be processed without problems. >>>> ??? It is because both redefine and retransform capabilities are >>>> not required for CFLH's. >>>> >>>> 4) The capability "can_retransform_any_class" was added to allow >>>> RetransformClasses calls >>>> ??? for any classes including non-modifiable (if the implementation >>>> has such a notion). >>>> ??? It controls RetransformClasses calls only. >>>> >>>> 5) As I understand, the capability "can_redefine_any_class" was >>>> added to allow >>>> ??? RedefineClasses calls for any classes including non-modifiable >>>> ??? (if the implementation has such a notion). >>>> ??? It should control RedefineClasses only. >>>> ??? I do not see why it has to apply to RetransformClasses as well. >>>> >>>> >>>> Could you, explain, please, what is the advantages to apply it to >>>> both retransform and redefine? >>>> >>>> I see only problems/disadvantages with it: >>>> >>>> D1: The terms "retransform" and "redefine" in this context are >>>> confusing. >>>> ???? The RetransformClasses is using a VM_RedefineClasses operation. >>>> ???? Can we treat this VM_RedefineClasses operation as "redefine"? >>>> ???? My guess is that this was initial motivation to list both >>>> "retransform" and "redefine" >>>> ???? for "can_redefine_any_class" capability. >>>> >>>> D2: The "can_redefine_classes" and "can_retransform_classes" are >>>> equal, >>>> ???? but "can_redefine_any_class" and "can_retransform_any_class" >>>> are not. >>>> ???? There is no symmetry here which adds complexity and generates >>>> confusion. >>>> >>>> D3: The RedefineClasses is controlled with can_redefine_classes and >>>> can_redefine_any_class. >>>> ???? But the RetransformClasses is controlled with: >>>> ?????? can_retransform_classes, can_retransform_any_class and >>>> can_redefine_any_class. >>>> ???? There is no symmetry here which adds complexity and generates >>>> confusion. >>>> >>>> >>>>> Further this change should not have been pushed yet as the CSR has >>>>> not been approved. >>>> >>>> Sorry, I confused this bug with another one. >>>> This was not pushed yet. >>>> Thank you for pointing it out! >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dan and David, >>>>>> >>>>>> On 5/21/19 15:58, David Holmes wrote: >>>>>>> Hi Dan, >>>>>>> >>>>>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> I've found one more fragment in the IsModifiableClass spec >>>>>>>>> which has to be fixed. >>>>>>>>> >>>>>>>>> >>>>>>>>> Updated webrev v2: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>>>>> >>>>>>>> >>>>>>>> src/hotspot/share/prims/jvmti.xml >>>>>>>> ???? No comments. >>>>>>>> >>>>>>>> Looks like there was a specific update to the spec to allow >>>>>>>> can_redefine_any_class >>>>>>>> to include retransform (in addition to redefine): >>>>>>>> >>>>>>>> 1.1.82 >>>>>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class >>>>>>>> to include retransform. Clarify that exception events cover all >>>>>>>> Throwables. In GetStackTrace, no test is done for start_depth >>>>>>>> too big if start_depth is zero, Clarify fields reported in >>>>>>>> Primitive Field Callback -- static vs instance. Repair >>>>>>>> confusing names of heap types, including callback names. >>>>>>>> Require consistent usage of stack depth in the face of thread >>>>>>>> launch methods. Note incompatibility of JVM TI memory >>>>>>>> management with other systems. >>>>>>>> >>>>>>>> I can't tell if you've chased down that change and why you no >>>>>>>> longer >>>>>>>> think that change is necessary. >>>>>>>> >>>>>>>> I'm okay with the change, but I think you have more research to >>>>>>>> do here. >>>>>>> >>>>>>> I already chased that down and mentioned it in the CSR. It was >>>>>>> done under: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>>>>> >>>>>>> Unfortunately I misread the original bug description. In >>>>>>> relation to can_redefine_any_class it states: >>>>>>> >>>>>>> A more precise definition would be: >>>>>>> ?????? Can retransform or redefine any non-primitive non-array >>>>>>> class. >>>>>>> >>>>>>> It appears to me that they did consider can_redefine_any_class >>>>>>> to be a "super" capability that could be added on top of >>>>>>> can_redefine_classes to extend it to "any" class; or on top of >>>>>>> can_retransform_classes to extend it to "any" class. If so the >>>>>>> name choice was unfortunate. >>>>>>> >>>>>>> Further it seems the implementation never checked this anyway. >>>>>> >>>>>> Right. >>>>>> The approach taken for JDK-6328530 is non-symmetrical and confusing. >>>>>> But, I think, I understand why this decision was made. :) >>>>>> >>>>>> If we ever decide to make some (non-primitive and non-array) >>>>>> classes to be non-modifiable then >>>>>> I do not see problems to implement it in a way that >>>>>> can_redefine_any_class will be checked on >>>>>> RedefineClasses only and can_retransform_any_class will be >>>>>> checked on RetransformClasses only. >>>>>> We will get a symmetry (and so, a simplification as well) in two >>>>>> dimensions: >>>>>> ?? - between redefine and retransform capabilities >>>>>> ?? - between can_redefine_classes and can_redefine_any_class >>>>>> capabilities >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> Specdiff: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Enhancement: >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>> >>>>>>>>> Related CSR: >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thank you for looking at this! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Please, review a fix for enhancement: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>>>> >>>>>>>>>>>> Related CSR: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>>> >>>>>>>>>>> I have some comments on the CSR and about this change >>>>>>>>>>> overall as to me it is not a simple clarification at all, >>>>>>>>>>> but potentially a significant change in the meaning of the >>>>>>>>>>> capability. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've answered your question in the CSR with my comment. >>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You introduced a typo: modifialble >>>>>>>>>>> >>>>>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>>>>> >>>>>>>>>>> 7444???????? >>>>>>>>>>> 7445?????????? If possessed then all classes (except >>>>>>>>>>> primitive, array, and some implementation defined >>>>>>>>>>> 7446?????????? classes) are modifiable (redefine or >>>>>>>>>>> retransform). >>>>>>>>>> >>>>>>>>>> Good catch, thanks! >>>>>>>>>> I've updated the webrev in place. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Summary: >>>>>>>>>>>> >>>>>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>>>>> capability spec more inconsistent. >>>>>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >> From serguei.spitsyn at oracle.com Wed May 22 17:52:26 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 May 2019 10:52:26 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <3b71fdaf-ebfd-62ea-410e-977cd9bcb1c3@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> <3b71fdaf-ebfd-62ea-410e-977cd9bcb1c3@oracle.com> Message-ID: Thanks, David! Serguei On 5/22/19 04:49, David Holmes wrote: > Hi Serguei, > > This final version looks good! > > Thanks, > David > ----- > > On 22/05/2019 8:55 pm, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 5/21/19 22:36, David Holmes wrote: >>> Hi Serguei, >>> >>> Apologies for the confusion around this - and double apologies that >>> you wrote all the below while I was busy going through the history >>> and updating the CSR request with all the relevant details. >> >> >> No apologies are accepted. :) >> The topic is confusing for me too. >> Thank you for checking all this as it is the best way to make it right! >> I really appreciate it. >> >> >>> As I've finally written in the CSR request your change here is >>> correct as it fixes an error/confusion introduced by JDK-6328530 >>> (which itself was confused because of an omission introduced by >>> JDK-6306942; and that omission was rectified by JDK-8145964.) >>> >>> They key end result here is that can_redefine_any_class and >>> can_retransform_any class should be described in exactly the same >>> way other than the redefine/retransform part. This means: >>> >>> - their usage with IsModifiableClass >>> - their usage with RedefineClasses/RetransformClasses >>> - their definitions in the capabilities structure >>> >>> You've addressed the first part here, and the second was already >>> fine, but your change to the third part, while not wrong per-se, >>> uses a different form. You now have: >>> >>> can_redefine_any_class: Can redefine any modifiable class. See >>> IsModifiableClass. (can_redefine_classes must also be set) >>> >>> whereas we already have: >>> >>> can_retransform_any_class: RetransformClasses can be called on any >>> modifiable class. See IsModifiableClass. (can_retransform_classes >>> must also be set) >>> >>> So I recommend instead: >>> >>> can_redefine_any_class: RedefineClasses can be called on any >>> modifiable class. See IsModifiableClass. (can_redefine_classes must >>> also be set) >> >> Agreed, thanks! >> When looked at the spec again I came to the same conclusion. >> I've updated the CSR with this suggestion. >> >> Also, please, find the latest versions below: >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ >> >> >> JVMTI spec: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti.html >> >> >> JVMTI spec diff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti-specdiff/ >> >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8046018 >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223915 >> >> >> Thanks, >> Serguei >> >> >>> Thanks, >>> David >>> ----- >>> >>> On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> >>>> On 5/21/19 17:25, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Sorry but I think this "fix" is inappropriate. The capability may >>>>> be badly named but the intent was to have it apply to both >>>>> redefine and retransform. >>>> >>>> Not sure, I fully understand you here. >>>> This intent seemed to be wrong or, at least, it is really confusing >>>> to everybody. >>>> >>>> To understand it better, let's do some analysis first and start >>>> from what we know. >>>> >>>> 1) The JVMTI RedefineClasses is implemented with using a >>>> VM_RedefineClasses operation. >>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>> RedefineClasses call from agent code. >>>> ??? The capability "can_redefine_classes" has to be possessed to >>>> call RedefineClasses. >>>> >>>> 2) The JVMTI RetransformClasses is also implemented with using a >>>> VM_RedefineClasses operation. >>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>> RetransformClasses call from agent code. >>>> ??? The capability "can_retransform_classes" has to be possessed to >>>> call RetransformClasses. >>>> ??? There is no check (and no intent to check) for the capability >>>> "can_redefine_classes". >>>> >>>> 3) The VM_RedefineClasses starts a chain of CFLH's? (per each >>>> JvmtiEnv) in both cases above. >>>> ??? So that the retransformations (with CFLH's) both >>>> RedefineClasses and RetransformClasses calls. >>>> ??? If the capability "can_retransform_classes" was not possessed >>>> the retransformations >>>> ??? caused by RedefineClasses will be processed without problems. >>>> ??? It is because both redefine and retransform capabilities are >>>> not required for CFLH's. >>>> >>>> 4) The capability "can_retransform_any_class" was added to allow >>>> RetransformClasses calls >>>> ??? for any classes including non-modifiable (if the implementation >>>> has such a notion). >>>> ??? It controls RetransformClasses calls only. >>>> >>>> 5) As I understand, the capability "can_redefine_any_class" was >>>> added to allow >>>> ??? RedefineClasses calls for any classes including non-modifiable >>>> ??? (if the implementation has such a notion). >>>> ??? It should control RedefineClasses only. >>>> ??? I do not see why it has to apply to RetransformClasses as well. >>>> >>>> >>>> Could you, explain, please, what is the advantages to apply it to >>>> both retransform and redefine? >>>> >>>> I see only problems/disadvantages with it: >>>> >>>> D1: The terms "retransform" and "redefine" in this context are >>>> confusing. >>>> ???? The RetransformClasses is using a VM_RedefineClasses operation. >>>> ???? Can we treat this VM_RedefineClasses operation as "redefine"? >>>> ???? My guess is that this was initial motivation to list both >>>> "retransform" and "redefine" >>>> ???? for "can_redefine_any_class" capability. >>>> >>>> D2: The "can_redefine_classes" and "can_retransform_classes" are >>>> equal, >>>> ???? but "can_redefine_any_class" and "can_retransform_any_class" >>>> are not. >>>> ???? There is no symmetry here which adds complexity and generates >>>> confusion. >>>> >>>> D3: The RedefineClasses is controlled with can_redefine_classes and >>>> can_redefine_any_class. >>>> ???? But the RetransformClasses is controlled with: >>>> ?????? can_retransform_classes, can_retransform_any_class and >>>> can_redefine_any_class. >>>> ???? There is no symmetry here which adds complexity and generates >>>> confusion. >>>> >>>> >>>>> Further this change should not have been pushed yet as the CSR has >>>>> not been approved. >>>> >>>> Sorry, I confused this bug with another one. >>>> This was not pushed yet. >>>> Thank you for pointing it out! >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dan and David, >>>>>> >>>>>> On 5/21/19 15:58, David Holmes wrote: >>>>>>> Hi Dan, >>>>>>> >>>>>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> I've found one more fragment in the IsModifiableClass spec >>>>>>>>> which has to be fixed. >>>>>>>>> >>>>>>>>> >>>>>>>>> Updated webrev v2: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>>>>> >>>>>>>> >>>>>>>> src/hotspot/share/prims/jvmti.xml >>>>>>>> ???? No comments. >>>>>>>> >>>>>>>> Looks like there was a specific update to the spec to allow >>>>>>>> can_redefine_any_class >>>>>>>> to include retransform (in addition to redefine): >>>>>>>> >>>>>>>> 1.1.82 >>>>>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class >>>>>>>> to include retransform. Clarify that exception events cover all >>>>>>>> Throwables. In GetStackTrace, no test is done for start_depth >>>>>>>> too big if start_depth is zero, Clarify fields reported in >>>>>>>> Primitive Field Callback -- static vs instance. Repair >>>>>>>> confusing names of heap types, including callback names. >>>>>>>> Require consistent usage of stack depth in the face of thread >>>>>>>> launch methods. Note incompatibility of JVM TI memory >>>>>>>> management with other systems. >>>>>>>> >>>>>>>> I can't tell if you've chased down that change and why you no >>>>>>>> longer >>>>>>>> think that change is necessary. >>>>>>>> >>>>>>>> I'm okay with the change, but I think you have more research to >>>>>>>> do here. >>>>>>> >>>>>>> I already chased that down and mentioned it in the CSR. It was >>>>>>> done under: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>>>>> >>>>>>> Unfortunately I misread the original bug description. In >>>>>>> relation to can_redefine_any_class it states: >>>>>>> >>>>>>> A more precise definition would be: >>>>>>> ?????? Can retransform or redefine any non-primitive non-array >>>>>>> class. >>>>>>> >>>>>>> It appears to me that they did consider can_redefine_any_class >>>>>>> to be a "super" capability that could be added on top of >>>>>>> can_redefine_classes to extend it to "any" class; or on top of >>>>>>> can_retransform_classes to extend it to "any" class. If so the >>>>>>> name choice was unfortunate. >>>>>>> >>>>>>> Further it seems the implementation never checked this anyway. >>>>>> >>>>>> Right. >>>>>> The approach taken for JDK-6328530 is non-symmetrical and confusing. >>>>>> But, I think, I understand why this decision was made. :) >>>>>> >>>>>> If we ever decide to make some (non-primitive and non-array) >>>>>> classes to be non-modifiable then >>>>>> I do not see problems to implement it in a way that >>>>>> can_redefine_any_class will be checked on >>>>>> RedefineClasses only and can_retransform_any_class will be >>>>>> checked on RetransformClasses only. >>>>>> We will get a symmetry (and so, a simplification as well) in two >>>>>> dimensions: >>>>>> ?? - between redefine and retransform capabilities >>>>>> ?? - between can_redefine_classes and can_redefine_any_class >>>>>> capabilities >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> Specdiff: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Enhancement: >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>> >>>>>>>>> Related CSR: >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thank you for looking at this! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Please, review a fix for enhancement: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>>>> >>>>>>>>>>>> Related CSR: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>>> >>>>>>>>>>> I have some comments on the CSR and about this change >>>>>>>>>>> overall as to me it is not a simple clarification at all, >>>>>>>>>>> but potentially a significant change in the meaning of the >>>>>>>>>>> capability. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've answered your question in the CSR with my comment. >>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You introduced a typo: modifialble >>>>>>>>>>> >>>>>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>>>>> >>>>>>>>>>> 7444???????? >>>>>>>>>>> 7445?????????? If possessed then all classes (except >>>>>>>>>>> primitive, array, and some implementation defined >>>>>>>>>>> 7446?????????? classes) are modifiable (redefine or >>>>>>>>>>> retransform). >>>>>>>>>> >>>>>>>>>> Good catch, thanks! >>>>>>>>>> I've updated the webrev in place. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Summary: >>>>>>>>>>>> >>>>>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>>>>> capability spec more inconsistent. >>>>>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >> From serguei.spitsyn at oracle.com Wed May 22 17:54:43 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 May 2019 10:54:43 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <2d138d94-7b8b-d35d-990b-7d27481a314b@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> <2d138d94-7b8b-d35d-990b-7d27481a314b@oracle.com> Message-ID: <1f8e83e8-9d11-de48-83c0-032a97ee7b1f@oracle.com> On 5/22/19 07:00, Daniel D. Daugherty wrote: >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ > > > > Thumbs up on this version. I did add a historical note to the CSR... Good comment. I've added a note with a small correction/addition. Thanks, Dan! Serguei > > Dan > > > On 5/22/19 6:55 AM, serguei.spitsyn at oracle.com wrote: >> Hi David, >> >> >> On 5/21/19 22:36, David Holmes wrote: >>> Hi Serguei, >>> >>> Apologies for the confusion around this - and double apologies that >>> you wrote all the below while I was busy going through the history >>> and updating the CSR request with all the relevant details. >> >> >> No apologies are accepted. :) >> The topic is confusing for me too. >> Thank you for checking all this as it is the best way to make it right! >> I really appreciate it. >> >> >>> As I've finally written in the CSR request your change here is >>> correct as it fixes an error/confusion introduced by JDK-6328530 >>> (which itself was confused because of an omission introduced by >>> JDK-6306942; and that omission was rectified by JDK-8145964.) >>> >>> They key end result here is that can_redefine_any_class and >>> can_retransform_any class should be described in exactly the same >>> way other than the redefine/retransform part. This means: >>> >>> - their usage with IsModifiableClass >>> - their usage with RedefineClasses/RetransformClasses >>> - their definitions in the capabilities structure >>> >>> You've addressed the first part here, and the second was already >>> fine, but your change to the third part, while not wrong per-se, >>> uses a different form. You now have: >>> >>> can_redefine_any_class: Can redefine any modifiable class. See >>> IsModifiableClass. (can_redefine_classes must also be set) >>> >>> whereas we already have: >>> >>> can_retransform_any_class: RetransformClasses can be called on any >>> modifiable class. See IsModifiableClass. (can_retransform_classes >>> must also be set) >>> >>> So I recommend instead: >>> >>> can_redefine_any_class: RedefineClasses can be called on any >>> modifiable class. See IsModifiableClass. (can_redefine_classes must >>> also be set) >> >> Agreed, thanks! >> When looked at the spec again I came to the same conclusion. >> I've updated the CSR with this suggestion. >> >> Also, please, find the latest versions below: >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ >> >> >> JVMTI spec: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti.html >> >> >> JVMTI spec diff: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti-specdiff/ >> >> >> Enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8046018 >> >> Related CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223915 >> >> >> Thanks, >> Serguei >> >> >>> Thanks, >>> David >>> ----- >>> >>> On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> >>>> On 5/21/19 17:25, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Sorry but I think this "fix" is inappropriate. The capability may >>>>> be badly named but the intent was to have it apply to both >>>>> redefine and retransform. >>>> >>>> Not sure, I fully understand you here. >>>> This intent seemed to be wrong or, at least, it is really confusing >>>> to everybody. >>>> >>>> To understand it better, let's do some analysis first and start >>>> from what we know. >>>> >>>> 1) The JVMTI RedefineClasses is implemented with using a >>>> VM_RedefineClasses operation. >>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>> RedefineClasses call from agent code. >>>> ??? The capability "can_redefine_classes" has to be possessed to >>>> call RedefineClasses. >>>> >>>> 2) The JVMTI RetransformClasses is also implemented with using a >>>> VM_RedefineClasses operation. >>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>> RetransformClasses call from agent code. >>>> ??? The capability "can_retransform_classes" has to be possessed to >>>> call RetransformClasses. >>>> ??? There is no check (and no intent to check) for the capability >>>> "can_redefine_classes". >>>> >>>> 3) The VM_RedefineClasses starts a chain of CFLH's? (per each >>>> JvmtiEnv) in both cases above. >>>> ??? So that the retransformations (with CFLH's) both >>>> RedefineClasses and RetransformClasses calls. >>>> ??? If the capability "can_retransform_classes" was not possessed >>>> the retransformations >>>> ??? caused by RedefineClasses will be processed without problems. >>>> ??? It is because both redefine and retransform capabilities are >>>> not required for CFLH's. >>>> >>>> 4) The capability "can_retransform_any_class" was added to allow >>>> RetransformClasses calls >>>> ??? for any classes including non-modifiable (if the implementation >>>> has such a notion). >>>> ??? It controls RetransformClasses calls only. >>>> >>>> 5) As I understand, the capability "can_redefine_any_class" was >>>> added to allow >>>> ??? RedefineClasses calls for any classes including non-modifiable >>>> ??? (if the implementation has such a notion). >>>> ??? It should control RedefineClasses only. >>>> ??? I do not see why it has to apply to RetransformClasses as well. >>>> >>>> >>>> Could you, explain, please, what is the advantages to apply it to >>>> both retransform and redefine? >>>> >>>> I see only problems/disadvantages with it: >>>> >>>> D1: The terms "retransform" and "redefine" in this context are >>>> confusing. >>>> ???? The RetransformClasses is using a VM_RedefineClasses operation. >>>> ???? Can we treat this VM_RedefineClasses operation as "redefine"? >>>> ???? My guess is that this was initial motivation to list both >>>> "retransform" and "redefine" >>>> ???? for "can_redefine_any_class" capability. >>>> >>>> D2: The "can_redefine_classes" and "can_retransform_classes" are >>>> equal, >>>> ???? but "can_redefine_any_class" and "can_retransform_any_class" >>>> are not. >>>> ???? There is no symmetry here which adds complexity and generates >>>> confusion. >>>> >>>> D3: The RedefineClasses is controlled with can_redefine_classes and >>>> can_redefine_any_class. >>>> ???? But the RetransformClasses is controlled with: >>>> ?????? can_retransform_classes, can_retransform_any_class and >>>> can_redefine_any_class. >>>> ???? There is no symmetry here which adds complexity and generates >>>> confusion. >>>> >>>> >>>>> Further this change should not have been pushed yet as the CSR has >>>>> not been approved. >>>> >>>> Sorry, I confused this bug with another one. >>>> This was not pushed yet. >>>> Thank you for pointing it out! >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Dan and David, >>>>>> >>>>>> On 5/21/19 15:58, David Holmes wrote: >>>>>>> Hi Dan, >>>>>>> >>>>>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi guys, >>>>>>>>> >>>>>>>>> I've found one more fragment in the IsModifiableClass spec >>>>>>>>> which has to be fixed. >>>>>>>>> >>>>>>>>> >>>>>>>>> Updated webrev v2: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>>>>> >>>>>>>> >>>>>>>> src/hotspot/share/prims/jvmti.xml >>>>>>>> ???? No comments. >>>>>>>> >>>>>>>> Looks like there was a specific update to the spec to allow >>>>>>>> can_redefine_any_class >>>>>>>> to include retransform (in addition to redefine): >>>>>>>> >>>>>>>> 1.1.82 >>>>>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class >>>>>>>> to include retransform. Clarify that exception events cover all >>>>>>>> Throwables. In GetStackTrace, no test is done for start_depth >>>>>>>> too big if start_depth is zero, Clarify fields reported in >>>>>>>> Primitive Field Callback -- static vs instance. Repair >>>>>>>> confusing names of heap types, including callback names. >>>>>>>> Require consistent usage of stack depth in the face of thread >>>>>>>> launch methods. Note incompatibility of JVM TI memory >>>>>>>> management with other systems. >>>>>>>> >>>>>>>> I can't tell if you've chased down that change and why you no >>>>>>>> longer >>>>>>>> think that change is necessary. >>>>>>>> >>>>>>>> I'm okay with the change, but I think you have more research to >>>>>>>> do here. >>>>>>> >>>>>>> I already chased that down and mentioned it in the CSR. It was >>>>>>> done under: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>>>>> >>>>>>> Unfortunately I misread the original bug description. In >>>>>>> relation to can_redefine_any_class it states: >>>>>>> >>>>>>> A more precise definition would be: >>>>>>> ?????? Can retransform or redefine any non-primitive non-array >>>>>>> class. >>>>>>> >>>>>>> It appears to me that they did consider can_redefine_any_class >>>>>>> to be a "super" capability that could be added on top of >>>>>>> can_redefine_classes to extend it to "any" class; or on top of >>>>>>> can_retransform_classes to extend it to "any" class. If so the >>>>>>> name choice was unfortunate. >>>>>>> >>>>>>> Further it seems the implementation never checked this anyway. >>>>>> >>>>>> Right. >>>>>> The approach taken for JDK-6328530 is non-symmetrical and confusing. >>>>>> But, I think, I understand why this decision was made. :) >>>>>> >>>>>> If we ever decide to make some (non-primitive and non-array) >>>>>> classes to be non-modifiable then >>>>>> I do not see problems to implement it in a way that >>>>>> can_redefine_any_class will be checked on >>>>>> RedefineClasses only and can_retransform_any_class will be >>>>>> checked on RetransformClasses only. >>>>>> We will get a symmetry (and so, a simplification as well) in two >>>>>> dimensions: >>>>>> ?? - between redefine and retransform capabilities >>>>>> ?? - between can_redefine_classes and can_redefine_any_class >>>>>> capabilities >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Dan >>>>>>>> >>>>>>>> >>>>>>>>> Specdiff: >>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Enhancement: >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>> >>>>>>>>> Related CSR: >>>>>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi David, >>>>>>>>>> >>>>>>>>>> Thank you for looking at this! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>>>>> Hi Serguei, >>>>>>>>>>> >>>>>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Please, review a fix for enhancement: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>>>> >>>>>>>>>>>> Related CSR: >>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>>> >>>>>>>>>>> I have some comments on the CSR and about this change >>>>>>>>>>> overall as to me it is not a simple clarification at all, >>>>>>>>>>> but potentially a significant change in the meaning of the >>>>>>>>>>> capability. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've answered your question in the CSR with my comment. >>>>>>>>>> >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You introduced a typo: modifialble >>>>>>>>>>> >>>>>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>>>>> >>>>>>>>>>> 7444???????? >>>>>>>>>>> 7445?????????? If possessed then all classes (except >>>>>>>>>>> primitive, array, and some implementation defined >>>>>>>>>>> 7446?????????? classes) are modifiable (redefine or >>>>>>>>>>> retransform). >>>>>>>>>> >>>>>>>>>> Good catch, thanks! >>>>>>>>>> I've updated the webrev in place. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> ----- >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Summary: >>>>>>>>>>>> >>>>>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>>>>> capability spec more inconsistent. >>>>>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>> >> > From serguei.spitsyn at oracle.com Wed May 22 18:46:58 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 22 May 2019 11:46:58 -0700 Subject: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: References: <00C8E0C5-D10E-4B96-9FD3-41693CF77C97@oracle.com> Message-ID: <44b57cb9-e0bb-db3a-3fb4-2b7e1d7d32ac@oracle.com> Hi Daniil, +1 Thanks, Serguei On 5/20/19 23:20, David Holmes wrote: > Loosk good. > > Thanks, > David > > On 21/05/2019 1:25 pm, Daniil Titov wrote: >> Please review un updated version of the previous change that also >> removes unnecessary line >> >> chmod ug+x $REVOKEALL >> >> from >> test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh >> >> Webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.03 >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 >> ???? Thanks! >> --Daniil >> >> ?On 5/20/19, 6:02 PM, "serviceability-dev on behalf of Daniil Titov" >> > daniil.x.titov at oracle.com> wrote: >> >> ???? Please review a new version of the fix that includes the changes >> David suggested. >> ???? ????? > The count-- is obvious as it is the loop counter, but it >> is far from >> ????? >? clear to me that i++ is correct. I don't fully understand >> the logic >> ???? ???? We need to increment i on line 354: >> ???? ????? 353???????? if (((ACCESS_ALLOWED_ACE >> *)ace)->Header.AceType != ACCESS_ALLOWED_ACE_TYPE) { >> ????? 354???????????? i++; >> ????? 355???????????? count--; >> ????? 356???????????? continue; >> ????? 357???????? } >> ???? ???? since the code iterates over all ACE entries for a given >> file and deletes ones that grant non-owner access to the file.? i is >> the index of the current ACE entry >> ???? in the ACL structure. The current ACE entry is retrieved at the >> beginning of the loop: >> ???? ???? 349???????? if (!GetAce(acl, i, &ace)) { >> ???? ???? ???? and the index is always incremented at the end of the >> loop unless the current entry is deleted. >> ???? ???? 382???????? if (!deleted) { >> ????? 383???????????? str = getSIDString(sid); >> ????? 384???????????? if (str != NULL) { >> ????? 385???????????????? printf("ALLOW %s (access mask=%x)\n", str, >> access->Mask); >> ????? 386???????????????? free(str); >> ????? 387???????????? } >> ????? 388 >> ????? 389???????????? /* onto the next ACE */ >> ????? 390???????????? i++; >> ????? 391???????? } >> ????? 392???????? count--; >> ???? ???? ???? I also created a new issue to replace revokeall.exe >> with Java code as Alan suggested : >> https://bugs.openjdk.java.net/browse/JDK-8224255 >> ???? ???? ???? Webrev: >> http://cr.openjdk.java.net/~dtitov/8214545/webrev.02 >> ???? Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 >> ???? ???? Thanks! >> ???? --Daniil >> ???? ???? ???? ?On 5/19/19, 5:43 PM, "David Holmes" >> wrote: >> ???? ???????? Hi Daniil, >> ???????? ???????? cc: Boris and Erik J. >> ???????? ???????? On 20/05/2019 7:12 am, Daniil Titov wrote: >> ???????? > Please review the change that fixes the failure of >> sun/management/jmxremote/bootstrap JMX tests on Windows platform.? >> While running, these tests invoke revokeall.exe utility and this >> utility hangs. >> ???????? > >> ???????? > The problem here is that invokeall.exe goes into an >> endless loop? while iterating over Access Control Entries (ACE) for a >> given file if it encounters at least one ACE with the type different >> from ACCESS_ALLOWED_ACE_TYPE. >> ???????? > >> ???????? > The change fixes this problem.? It also removes >> revokeall.exe binary from the repository and changes the makefile? to >> get it built instead. >> ???????? > >> ???????? > Tier1, tier2, tier3, jdk_svc, and >> sun/management/jmxremote/bootstrap? tests succeeded? in Mach5. >> ???????? > >> ???????? > Webrev: http://cr.openjdk.java.net/~dtitov/8214545 >> ???????? > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 >> ???????? ???????? I knew this seemed very familiar ... Boris had a >> fix for this a few >> ???????? weeks ago under JDK-8220581. Similar but not identical to >> yours - see >> ???????? below. Though getting rid of the exe from the repo is a good >> idea >> ???????? (thanks Erik!). >> ???????? ???????? A few comments >> test/jdk/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh >> ???????? ???????? Pre-existing: >> ???????? ???????? ! REVOKEALL="$TESTNATIVEPATH/revokeall.exe" >> ??????????????????? if [ ! -f "$REVOKEALL" ] ; then >> ???????? ???????? I would expect a -x test not -f. >> ???????? ???????? --- >> ???????? ???????? test/jdk/sun/management/windows/README >> ???????? ???????? The first copyright year should be 2004. >> ???????? ??????????? 25 This directory contains the source and the >> binary version >> ???????? ???????? Delete "and the binary version". >> ???????? ???????? --- >> ???????? ???????? test/jdk/sun/management/windows/exerevokeall.c >> ???????? ???????? Pre-existing: >> ???????? ?????????? 31? * file - suitable for NT/2000/XP only. >> ???????? ???????? Please delete everything after "file". >> ???????? ???????? ?????????? 355???????????? i++; >> ?????????? 356???????????? count--; >> ???????? ???????? The count-- is obvious as it is the loop counter, >> but it is far from >> ???????? clear to me that i++ is correct. I don't fully understand >> the logic but >> ???????? i is only incremented under very specific conditions. If you >> rewrote the >> ???????? code to avoid the use of the continue then i would not be >> modified >> ???????? except where it currently is. >> ???????? ???????? Thanks, >> ???????? David >> ???????? ----- >> ???????? ???????? > Thanks! >> ???????? > --Daniil >> ???????? > >> ???????? > >> >> From daniel.daugherty at oracle.com Wed May 22 18:50:43 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 22 May 2019 14:50:43 -0400 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: <1f8e83e8-9d11-de48-83c0-032a97ee7b1f@oracle.com> References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> <2d138d94-7b8b-d35d-990b-7d27481a314b@oracle.com> <1f8e83e8-9d11-de48-83c0-032a97ee7b1f@oracle.com> Message-ID: On 5/22/19 1:54 PM, serguei.spitsyn at oracle.com wrote: > > > > On 5/22/19 07:00, Daniel D. Daugherty wrote: >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ >> >> >> >> >> Thumbs up on this version. I did add a historical note to the CSR... > > Good comment. > I've added a note with a small correction/addition. Sorry, I had to correct your correction... :-) Dan > > Thanks, Dan! > Serguei > >> >> Dan >> >> >> On 5/22/19 6:55 AM, serguei.spitsyn at oracle.com wrote: >>> Hi David, >>> >>> >>> On 5/21/19 22:36, David Holmes wrote: >>>> Hi Serguei, >>>> >>>> Apologies for the confusion around this - and double apologies that >>>> you wrote all the below while I was busy going through the history >>>> and updating the CSR request with all the relevant details. >>> >>> >>> No apologies are accepted. :) >>> The topic is confusing for me too. >>> Thank you for checking all this as it is the best way to make it right! >>> I really appreciate it. >>> >>> >>>> As I've finally written in the CSR request your change here is >>>> correct as it fixes an error/confusion introduced by JDK-6328530 >>>> (which itself was confused because of an omission introduced by >>>> JDK-6306942; and that omission was rectified by JDK-8145964.) >>>> >>>> They key end result here is that can_redefine_any_class and >>>> can_retransform_any class should be described in exactly the same >>>> way other than the redefine/retransform part. This means: >>>> >>>> - their usage with IsModifiableClass >>>> - their usage with RedefineClasses/RetransformClasses >>>> - their definitions in the capabilities structure >>>> >>>> You've addressed the first part here, and the second was already >>>> fine, but your change to the third part, while not wrong per-se, >>>> uses a different form. You now have: >>>> >>>> can_redefine_any_class: Can redefine any modifiable class. See >>>> IsModifiableClass. (can_redefine_classes must also be set) >>>> >>>> whereas we already have: >>>> >>>> can_retransform_any_class: RetransformClasses can be called on any >>>> modifiable class. See IsModifiableClass. (can_retransform_classes >>>> must also be set) >>>> >>>> So I recommend instead: >>>> >>>> can_redefine_any_class: RedefineClasses can be called on any >>>> modifiable class. See IsModifiableClass. (can_redefine_classes must >>>> also be set) >>> >>> Agreed, thanks! >>> When looked at the spec again I came to the same conclusion. >>> I've updated the CSR with this suggestion. >>> >>> Also, please, find the latest versions below: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ >>> >>> >>> JVMTI spec: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti.html >>> >>> >>> JVMTI spec diff: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti-specdiff/ >>> >>> >>> Enhancement: >>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>> >>> Related CSR: >>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>> >>> >>> Thanks, >>> Serguei >>> >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>>>> Hi David, >>>>> >>>>> >>>>> On 5/21/19 17:25, David Holmes wrote: >>>>>> Hi Serguei, >>>>>> >>>>>> Sorry but I think this "fix" is inappropriate. The capability may >>>>>> be badly named but the intent was to have it apply to both >>>>>> redefine and retransform. >>>>> >>>>> Not sure, I fully understand you here. >>>>> This intent seemed to be wrong or, at least, it is really >>>>> confusing to everybody. >>>>> >>>>> To understand it better, let's do some analysis first and start >>>>> from what we know. >>>>> >>>>> 1) The JVMTI RedefineClasses is implemented with using a >>>>> VM_RedefineClasses operation. >>>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>>> RedefineClasses call from agent code. >>>>> ??? The capability "can_redefine_classes" has to be possessed to >>>>> call RedefineClasses. >>>>> >>>>> 2) The JVMTI RetransformClasses is also implemented with using a >>>>> VM_RedefineClasses operation. >>>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>>> RetransformClasses call from agent code. >>>>> ??? The capability "can_retransform_classes" has to be possessed >>>>> to call RetransformClasses. >>>>> ??? There is no check (and no intent to check) for the capability >>>>> "can_redefine_classes". >>>>> >>>>> 3) The VM_RedefineClasses starts a chain of CFLH's? (per each >>>>> JvmtiEnv) in both cases above. >>>>> ??? So that the retransformations (with CFLH's) both >>>>> RedefineClasses and RetransformClasses calls. >>>>> ??? If the capability "can_retransform_classes" was not possessed >>>>> the retransformations >>>>> ??? caused by RedefineClasses will be processed without problems. >>>>> ??? It is because both redefine and retransform capabilities are >>>>> not required for CFLH's. >>>>> >>>>> 4) The capability "can_retransform_any_class" was added to allow >>>>> RetransformClasses calls >>>>> ??? for any classes including non-modifiable (if the >>>>> implementation has such a notion). >>>>> ??? It controls RetransformClasses calls only. >>>>> >>>>> 5) As I understand, the capability "can_redefine_any_class" was >>>>> added to allow >>>>> ??? RedefineClasses calls for any classes including non-modifiable >>>>> ??? (if the implementation has such a notion). >>>>> ??? It should control RedefineClasses only. >>>>> ??? I do not see why it has to apply to RetransformClasses as well. >>>>> >>>>> >>>>> Could you, explain, please, what is the advantages to apply it to >>>>> both retransform and redefine? >>>>> >>>>> I see only problems/disadvantages with it: >>>>> >>>>> D1: The terms "retransform" and "redefine" in this context are >>>>> confusing. >>>>> ???? The RetransformClasses is using a VM_RedefineClasses operation. >>>>> ???? Can we treat this VM_RedefineClasses operation as "redefine"? >>>>> ???? My guess is that this was initial motivation to list both >>>>> "retransform" and "redefine" >>>>> ???? for "can_redefine_any_class" capability. >>>>> >>>>> D2: The "can_redefine_classes" and "can_retransform_classes" are >>>>> equal, >>>>> ???? but "can_redefine_any_class" and "can_retransform_any_class" >>>>> are not. >>>>> ???? There is no symmetry here which adds complexity and generates >>>>> confusion. >>>>> >>>>> D3: The RedefineClasses is controlled with can_redefine_classes >>>>> and can_redefine_any_class. >>>>> ???? But the RetransformClasses is controlled with: >>>>> ?????? can_retransform_classes, can_retransform_any_class and >>>>> can_redefine_any_class. >>>>> ???? There is no symmetry here which adds complexity and generates >>>>> confusion. >>>>> >>>>> >>>>>> Further this change should not have been pushed yet as the CSR >>>>>> has not been approved. >>>>> >>>>> Sorry, I confused this bug with another one. >>>>> This was not pushed yet. >>>>> Thank you for pointing it out! >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Dan and David, >>>>>>> >>>>>>> On 5/21/19 15:58, David Holmes wrote: >>>>>>>> Hi Dan, >>>>>>>> >>>>>>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>>>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi guys, >>>>>>>>>> >>>>>>>>>> I've found one more fragment in the IsModifiableClass spec >>>>>>>>>> which has to be fixed. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Updated webrev v2: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> src/hotspot/share/prims/jvmti.xml >>>>>>>>> ???? No comments. >>>>>>>>> >>>>>>>>> Looks like there was a specific update to the spec to allow >>>>>>>>> can_redefine_any_class >>>>>>>>> to include retransform (in addition to redefine): >>>>>>>>> >>>>>>>>> 1.1.82 >>>>>>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class >>>>>>>>> to include retransform. Clarify that exception events cover >>>>>>>>> all Throwables. In GetStackTrace, no test is done for >>>>>>>>> start_depth too big if start_depth is zero, Clarify fields >>>>>>>>> reported in Primitive Field Callback -- static vs instance. >>>>>>>>> Repair confusing names of heap types, including callback >>>>>>>>> names. Require consistent usage of stack depth in the face of >>>>>>>>> thread launch methods. Note incompatibility of JVM TI memory >>>>>>>>> management with other systems. >>>>>>>>> >>>>>>>>> I can't tell if you've chased down that change and why you no >>>>>>>>> longer >>>>>>>>> think that change is necessary. >>>>>>>>> >>>>>>>>> I'm okay with the change, but I think you have more research >>>>>>>>> to do here. >>>>>>>> >>>>>>>> I already chased that down and mentioned it in the CSR. It was >>>>>>>> done under: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>>>>>> >>>>>>>> Unfortunately I misread the original bug description. In >>>>>>>> relation to can_redefine_any_class it states: >>>>>>>> >>>>>>>> A more precise definition would be: >>>>>>>> ?????? Can retransform or redefine any non-primitive non-array >>>>>>>> class. >>>>>>>> >>>>>>>> It appears to me that they did consider can_redefine_any_class >>>>>>>> to be a "super" capability that could be added on top of >>>>>>>> can_redefine_classes to extend it to "any" class; or on top of >>>>>>>> can_retransform_classes to extend it to "any" class. If so the >>>>>>>> name choice was unfortunate. >>>>>>>> >>>>>>>> Further it seems the implementation never checked this anyway. >>>>>>> >>>>>>> Right. >>>>>>> The approach taken for JDK-6328530 is non-symmetrical and >>>>>>> confusing. >>>>>>> But, I think, I understand why this decision was made. :) >>>>>>> >>>>>>> If we ever decide to make some (non-primitive and non-array) >>>>>>> classes to be non-modifiable then >>>>>>> I do not see problems to implement it in a way that >>>>>>> can_redefine_any_class will be checked on >>>>>>> RedefineClasses only and can_retransform_any_class will be >>>>>>> checked on RetransformClasses only. >>>>>>> We will get a symmetry (and so, a simplification as well) in two >>>>>>> dimensions: >>>>>>> ?? - between redefine and retransform capabilities >>>>>>> ?? - between can_redefine_classes and can_redefine_any_class >>>>>>> capabilities >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>>> Specdiff: >>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Enhancement: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>> >>>>>>>>>> Related CSR: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> Thank you for looking at this! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>> >>>>>>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>> Please, review a fix for enhancement: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>>>>> >>>>>>>>>>>>> Related CSR: >>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>>>> >>>>>>>>>>>> I have some comments on the CSR and about this change >>>>>>>>>>>> overall as to me it is not a simple clarification at all, >>>>>>>>>>>> but potentially a significant change in the meaning of the >>>>>>>>>>>> capability. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I've answered your question in the CSR with my comment. >>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You introduced a typo: modifialble >>>>>>>>>>>> >>>>>>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>>>>>> >>>>>>>>>>>> 7444???????? >>>>>>>>>>>> 7445?????????? If possessed then all classes (except >>>>>>>>>>>> primitive, array, and some implementation defined >>>>>>>>>>>> 7446?????????? classes) are modifiable (redefine or >>>>>>>>>>>> retransform). >>>>>>>>>>> >>>>>>>>>>> Good catch, thanks! >>>>>>>>>>> I've updated the webrev in place. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Summary: >>>>>>>>>>>>> >>>>>>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>>>>>> capability spec more inconsistent. >>>>>>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From serguei.spitsyn at oracle.com Thu May 23 08:18:13 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 May 2019 01:18:13 -0700 Subject: RFR (XS): 8046018: JVMTI Spec: can_redefine_any_class capability spec is inconsistent In-Reply-To: References: <4e57dbef-5d9d-c996-32db-240aaa87c1bb@oracle.com> <362b3e8a-6de6-a846-ac92-161cde7e326c@oracle.com> <54bbe6cd-656d-c41b-cd30-e7fdb534e81e@oracle.com> <5dfb3322-c97c-c816-01c0-9822d2a3ef52@oracle.com> <351a16c6-7462-4414-01de-242e8b637854@oracle.com> <0cd8b04b-e970-7169-113f-8167eb3aba69@oracle.com> <0831fb12-ce24-1712-726b-a68d8082fd1e@oracle.com> <2d138d94-7b8b-d35d-990b-7d27481a314b@oracle.com> <1f8e83e8-9d11-de48-83c0-032a97ee7b1f@oracle.com> Message-ID: <068061f2-9a94-371f-9b0d-134939ff518d@oracle.com> On 5/22/19 11:50, Daniel D. Daugherty wrote: > On 5/22/19 1:54 PM, serguei.spitsyn at oracle.com wrote: >> >> >> >> On 5/22/19 07:00, Daniel D. Daugherty wrote: >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ >>> >>> >>> >>> >>> >>> Thumbs up on this version. I did add a historical note to the CSR... >> >> Good comment. >> I've added a note with a small correction/addition. > > Sorry, I had to correct your correction... :-) Okay, thanks! I still hope, Alan will have a chance to look at this CSR and fix. At least, Alan wanted to review it a week ago. Thanks, Serguei > > Dan > > >> >> Thanks, Dan! >> Serguei >> >>> >>> Dan >>> >>> >>> On 5/22/19 6:55 AM, serguei.spitsyn at oracle.com wrote: >>>> Hi David, >>>> >>>> >>>> On 5/21/19 22:36, David Holmes wrote: >>>>> Hi Serguei, >>>>> >>>>> Apologies for the confusion around this - and double apologies >>>>> that you wrote all the below while I was busy going through the >>>>> history and updating the CSR request with all the relevant details. >>>> >>>> >>>> No apologies are accepted. :) >>>> The topic is confusing for me too. >>>> Thank you for checking all this as it is the best way to make it >>>> right! >>>> I really appreciate it. >>>> >>>> >>>>> As I've finally written in the CSR request your change here is >>>>> correct as it fixes an error/confusion introduced by JDK-6328530 >>>>> (which itself was confused because of an omission introduced by >>>>> JDK-6306942; and that omission was rectified by JDK-8145964.) >>>>> >>>>> They key end result here is that can_redefine_any_class and >>>>> can_retransform_any class should be described in exactly the same >>>>> way other than the redefine/retransform part. This means: >>>>> >>>>> - their usage with IsModifiableClass >>>>> - their usage with RedefineClasses/RetransformClasses >>>>> - their definitions in the capabilities structure >>>>> >>>>> You've addressed the first part here, and the second was already >>>>> fine, but your change to the third part, while not wrong per-se, >>>>> uses a different form. You now have: >>>>> >>>>> can_redefine_any_class: Can redefine any modifiable class. See >>>>> IsModifiableClass. (can_redefine_classes must also be set) >>>>> >>>>> whereas we already have: >>>>> >>>>> can_retransform_any_class: RetransformClasses can be called on any >>>>> modifiable class. See IsModifiableClass. (can_retransform_classes >>>>> must also be set) >>>>> >>>>> So I recommend instead: >>>>> >>>>> can_redefine_any_class: RedefineClasses can be called on any >>>>> modifiable class. See IsModifiableClass. (can_redefine_classes >>>>> must also be set) >>>> >>>> Agreed, thanks! >>>> When looked at the spec again I came to the same conclusion. >>>> I've updated the CSR with this suggestion. >>>> >>>> Also, please, find the latest versions below: >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/ >>>> >>>> >>>> JVMTI spec: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti.html >>>> >>>> >>>> JVMTI spec diff: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.3/jvmti-specdiff/ >>>> >>>> >>>> Enhancement: >>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>> >>>> Related CSR: >>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> On 22/05/2019 1:59 pm, serguei.spitsyn at oracle.com wrote: >>>>>> Hi David, >>>>>> >>>>>> >>>>>> On 5/21/19 17:25, David Holmes wrote: >>>>>>> Hi Serguei, >>>>>>> >>>>>>> Sorry but I think this "fix" is inappropriate. The capability >>>>>>> may be badly named but the intent was to have it apply to both >>>>>>> redefine and retransform. >>>>>> >>>>>> Not sure, I fully understand you here. >>>>>> This intent seemed to be wrong or, at least, it is really >>>>>> confusing to everybody. >>>>>> >>>>>> To understand it better, let's do some analysis first and start >>>>>> from what we know. >>>>>> >>>>>> 1) The JVMTI RedefineClasses is implemented with using a >>>>>> VM_RedefineClasses operation. >>>>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>>>> RedefineClasses call from agent code. >>>>>> ??? The capability "can_redefine_classes" has to be possessed to >>>>>> call RedefineClasses. >>>>>> >>>>>> 2) The JVMTI RetransformClasses is also implemented with using a >>>>>> VM_RedefineClasses operation. >>>>>> ??? So, the VM_RedefineClasses is triggered on behave of a >>>>>> RetransformClasses call from agent code. >>>>>> ??? The capability "can_retransform_classes" has to be possessed >>>>>> to call RetransformClasses. >>>>>> ??? There is no check (and no intent to check) for the capability >>>>>> "can_redefine_classes". >>>>>> >>>>>> 3) The VM_RedefineClasses starts a chain of CFLH's? (per each >>>>>> JvmtiEnv) in both cases above. >>>>>> ??? So that the retransformations (with CFLH's) both >>>>>> RedefineClasses and RetransformClasses calls. >>>>>> ??? If the capability "can_retransform_classes" was not possessed >>>>>> the retransformations >>>>>> ??? caused by RedefineClasses will be processed without problems. >>>>>> ??? It is because both redefine and retransform capabilities are >>>>>> not required for CFLH's. >>>>>> >>>>>> 4) The capability "can_retransform_any_class" was added to allow >>>>>> RetransformClasses calls >>>>>> ??? for any classes including non-modifiable (if the >>>>>> implementation has such a notion). >>>>>> ??? It controls RetransformClasses calls only. >>>>>> >>>>>> 5) As I understand, the capability "can_redefine_any_class" was >>>>>> added to allow >>>>>> ??? RedefineClasses calls for any classes including non-modifiable >>>>>> ??? (if the implementation has such a notion). >>>>>> ??? It should control RedefineClasses only. >>>>>> ??? I do not see why it has to apply to RetransformClasses as well. >>>>>> >>>>>> >>>>>> Could you, explain, please, what is the advantages to apply it to >>>>>> both retransform and redefine? >>>>>> >>>>>> I see only problems/disadvantages with it: >>>>>> >>>>>> D1: The terms "retransform" and "redefine" in this context are >>>>>> confusing. >>>>>> ???? The RetransformClasses is using a VM_RedefineClasses operation. >>>>>> ???? Can we treat this VM_RedefineClasses operation as "redefine"? >>>>>> ???? My guess is that this was initial motivation to list both >>>>>> "retransform" and "redefine" >>>>>> ???? for "can_redefine_any_class" capability. >>>>>> >>>>>> D2: The "can_redefine_classes" and "can_retransform_classes" are >>>>>> equal, >>>>>> ???? but "can_redefine_any_class" and "can_retransform_any_class" >>>>>> are not. >>>>>> ???? There is no symmetry here which adds complexity and >>>>>> generates confusion. >>>>>> >>>>>> D3: The RedefineClasses is controlled with can_redefine_classes >>>>>> and can_redefine_any_class. >>>>>> ???? But the RetransformClasses is controlled with: >>>>>> ?????? can_retransform_classes, can_retransform_any_class and >>>>>> can_redefine_any_class. >>>>>> ???? There is no symmetry here which adds complexity and >>>>>> generates confusion. >>>>>> >>>>>> >>>>>>> Further this change should not have been pushed yet as the CSR >>>>>>> has not been approved. >>>>>> >>>>>> Sorry, I confused this bug with another one. >>>>>> This was not pushed yet. >>>>>> Thank you for pointing it out! >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 22/05/2019 9:53 am, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Dan and David, >>>>>>>> >>>>>>>> On 5/21/19 15:58, David Holmes wrote: >>>>>>>>> Hi Dan, >>>>>>>>> >>>>>>>>> On 22/05/2019 2:34 am, Daniel D. Daugherty wrote: >>>>>>>>>> On 5/21/19 2:19 AM, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>> Hi guys, >>>>>>>>>>> >>>>>>>>>>> I've found one more fragment in the IsModifiableClass spec >>>>>>>>>>> which has to be fixed. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Updated webrev v2: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/ >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> src/hotspot/share/prims/jvmti.xml >>>>>>>>>> ???? No comments. >>>>>>>>>> >>>>>>>>>> Looks like there was a specific update to the spec to allow >>>>>>>>>> can_redefine_any_class >>>>>>>>>> to include retransform (in addition to redefine): >>>>>>>>>> >>>>>>>>>> 1.1.82 >>>>>>>>>> 13 February 2006 ??? Doc fixes: update can_redefine_any_class >>>>>>>>>> to include retransform. Clarify that exception events cover >>>>>>>>>> all Throwables. In GetStackTrace, no test is done for >>>>>>>>>> start_depth too big if start_depth is zero, Clarify fields >>>>>>>>>> reported in Primitive Field Callback -- static vs instance. >>>>>>>>>> Repair confusing names of heap types, including callback >>>>>>>>>> names. Require consistent usage of stack depth in the face of >>>>>>>>>> thread launch methods. Note incompatibility of JVM TI memory >>>>>>>>>> management with other systems. >>>>>>>>>> >>>>>>>>>> I can't tell if you've chased down that change and why you no >>>>>>>>>> longer >>>>>>>>>> think that change is necessary. >>>>>>>>>> >>>>>>>>>> I'm okay with the change, but I think you have more research >>>>>>>>>> to do here. >>>>>>>>> >>>>>>>>> I already chased that down and mentioned it in the CSR. It was >>>>>>>>> done under: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6328530 >>>>>>>>> >>>>>>>>> Unfortunately I misread the original bug description. In >>>>>>>>> relation to can_redefine_any_class it states: >>>>>>>>> >>>>>>>>> A more precise definition would be: >>>>>>>>> ?????? Can retransform or redefine any non-primitive non-array >>>>>>>>> class. >>>>>>>>> >>>>>>>>> It appears to me that they did consider can_redefine_any_class >>>>>>>>> to be a "super" capability that could be added on top of >>>>>>>>> can_redefine_classes to extend it to "any" class; or on top of >>>>>>>>> can_retransform_classes to extend it to "any" class. If so the >>>>>>>>> name choice was unfortunate. >>>>>>>>> >>>>>>>>> Further it seems the implementation never checked this anyway. >>>>>>>> >>>>>>>> Right. >>>>>>>> The approach taken for JDK-6328530 is non-symmetrical and >>>>>>>> confusing. >>>>>>>> But, I think, I understand why this decision was made. :) >>>>>>>> >>>>>>>> If we ever decide to make some (non-primitive and non-array) >>>>>>>> classes to be non-modifiable then >>>>>>>> I do not see problems to implement it in a way that >>>>>>>> can_redefine_any_class will be checked on >>>>>>>> RedefineClasses only and can_retransform_any_class will be >>>>>>>> checked on RetransformClasses only. >>>>>>>> We will get a symmetry (and so, a simplification as well) in >>>>>>>> two dimensions: >>>>>>>> ?? - between redefine and retransform capabilities >>>>>>>> ?? - between can_redefine_classes and can_redefine_any_class >>>>>>>> capabilities >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Dan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Specdiff: >>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.2/jvmti-specdiff/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Enhancement: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>>> >>>>>>>>>>> Related CSR: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Serguei >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 5/20/19 21:43, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>> Hi David, >>>>>>>>>>>> >>>>>>>>>>>> Thank you for looking at this! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 5/20/19 20:53, David Holmes wrote: >>>>>>>>>>>>> Hi Serguei, >>>>>>>>>>>>> >>>>>>>>>>>>> On 21/05/2019 4:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>>>>>> Please, review a fix for enhancement: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8046018 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Related CSR: >>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8223915 >>>>>>>>>>>>> >>>>>>>>>>>>> I have some comments on the CSR and about this change >>>>>>>>>>>>> overall as to me it is not a simple clarification at all, >>>>>>>>>>>>> but potentially a significant change in the meaning of the >>>>>>>>>>>>> capability. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I've answered your question in the CSR with my comment. >>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8046018-jvmti-cap-spec.1/ >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> You introduced a typo: modifialble >>>>>>>>>>>>> >>>>>>>>>>>>> Assuming this proceeds a similar change is needed earlier: >>>>>>>>>>>>> >>>>>>>>>>>>> 7444???????? >>>>>>>>>>>>> 7445?????????? If possessed then all classes (except >>>>>>>>>>>>> primitive, array, and some implementation defined >>>>>>>>>>>>> 7446?????????? classes) are modifiable (redefine or >>>>>>>>>>>>> retransform). >>>>>>>>>>>> >>>>>>>>>>>> Good catch, thanks! >>>>>>>>>>>> I've updated the webrev in place. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> ----- >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Summary: >>>>>>>>>>>>>> >>>>>>>>>>>>>> ?? The fix is to make the JVMTI can_redefine_any_class >>>>>>>>>>>>>> capability spec more inconsistent. >>>>>>>>>>>>>> ?? It is just about a couple of lines. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Serguei >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From sakamoto.osamu at nttcom.co.jp Thu May 23 09:34:44 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Thu, 23 May 2019 18:34:44 +0900 Subject: 8223814: SA: jhsdb common help needs to be more detailed Message-ID: Hi all, I've made the patch that was discussed here. This patch fixes the following JBS ticket. I attached the patch to this email. This patch passes serviceability/sa jtreg tests. Could you help? I would like to contribute it. I need a sponsor. (My company has signed to OCA (NTT Comware Corporation)) Thanks, Osamu -------------- next part -------------- A non-text attachment was scrubbed... Name: 8223814.patch Type: text/x-patch Size: 4817 bytes Desc: not available URL: From gary.adams at oracle.com Thu May 23 09:59:55 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Thu, 23 May 2019 05:59:55 -0400 Subject: RFR: JDK-8218701: jdb tests failed with AGENT_ERROR_INVALID_THREAD Message-ID: <3fed4729-b7b3-1866-5ea0-dccdd9365f46@oracle.com> This proposed workaround ensures that the delay between a suspend request passing through the jdwp command queue will not fail due to a no longer running thread. ? Webrev: http://cr.openjdk.java.net/~gadams/8218701/webrev/ ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218701 From chris.plummer at oracle.com Thu May 23 17:23:08 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 23 May 2019 10:23:08 -0700 Subject: RFR: JDK-8218701: jdb tests failed with AGENT_ERROR_INVALID_THREAD In-Reply-To: <3fed4729-b7b3-1866-5ea0-dccdd9365f46@oracle.com> References: <3fed4729-b7b3-1866-5ea0-dccdd9365f46@oracle.com> Message-ID: <5300d20e-dff9-7581-de49-275994ed7354@oracle.com> Hi Gary, So a JVMTI event came in on a valid thread, got processed by the Debug Agent and enqueued to be sent to the Debugger. However, before it was actually sent, the thread became invalid. Am I understanding this issue correctly? thanks, Chris On 5/23/19 2:59 AM, gary.adams at oracle.com wrote: > This proposed workaround ensures that the delay between a suspend request > passing through the jdwp command queue will not fail due to a no longer > running thread. > > ? Webrev: http://cr.openjdk.java.net/~gadams/8218701/webrev/ > ? Issue: https://bugs.openjdk.java.net/browse/JDK-8218701 > From serguei.spitsyn at oracle.com Thu May 23 18:43:33 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 23 May 2019 11:43:33 -0700 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: References: Message-ID: <2fb150f9-89ff-84d1-dfa1-9d8ff3d59806@oracle.com> Hi Osamu, It looks Okay to me. But could you, please, send the output that the help command will print with your fix? Thanks, Serguei On 5/23/19 02:34, Osamu Sakamoto wrote: > Hi all, > > I've made the patch that was discussed here. > > > > This patch fixes the following JBS ticket. > > > I attached the patch to this email. > This patch passes serviceability/sa jtreg tests. > > Could you help? I would like to contribute it. I need a sponsor. > (My company has signed to OCA (NTT Comware Corporation)) > > > Thanks, > Osamu From yasuenag at gmail.com Fri May 24 00:23:54 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 24 May 2019 09:23:54 +0900 Subject: RFR: 8224252: [TESTBUG] hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java is timing out again after fix for JDK-8163805 Message-ID: Hi all, Please review this change. This webrev has passed all tests on submit repo (mach5-one-ysuenaga-JDK-8224252-3-20190523-0532-2647154). JBS: https://bugs.openjdk.java.net/browse/JDK-8224252 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8224252/webrev.00/ JDK-8163805 was suppose to fix a timeout issue with this test and also removed it off the problemlist. However, it still times out on windows-x64 about 1/3 of the time. It passes every time on all the other platforms. Root cause of this is `jhsdb debugd` could not be exited normally. `jhsdb debugd` (internally, DebugServer.java) would detach from debuggee at shutdown hook. So jhsdb process need to be exited normally. `jhsdb debugd` could not exit itself without external operation (e.g. CTRL+C, signals). Thus we use Process::destroy for it. In the case of Windows, Process::destroy calls TerminateProcess() Windows API to terminate process. However it would terminate target process immediately and it would not give a chance to kick shutdown hook. (It is documented on Javadoc of Runtime::addShutdownHook) Thanks, Yasumasa From sakamoto.osamu at nttcom.co.jp Fri May 24 01:11:28 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Fri, 24 May 2019 10:11:28 +0900 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: <2fb150f9-89ff-84d1-dfa1-9d8ff3d59806@oracle.com> References: <2fb150f9-89ff-84d1-dfa1-9d8ff3d59806@oracle.com> Message-ID: Hi Serguei, Thank for reviewing. > But could you, please, send the output that the help command will print > with your fix? I attached all fixed --help outputs(clhsdb/debugd/hsdb/jstack/jmap/jinfo/jsnap) to this email. Thanks, Osamu On 5/24/19 03:43, serguei.spitsyn at oracle.com wrote: > Hi Osamu, > > It looks Okay to me. > But could you, please, send the output that the help command will print > with your fix? > > Thanks, > Serguei > > > On 5/23/19 02:34, Osamu Sakamoto wrote: >> Hi all, >> >> I've made the patch that was discussed here. >> >> >> >> This patch fixes the following JBS ticket. >> >> >> I attached the patch to this email. >> This patch passes serviceability/sa jtreg tests. >> >> Could you help? I would like to contribute it. I need a sponsor. >> (My company has signed to OCA (NTT Comware Corporation)) >> >> >> Thanks, >> Osamu > -------------- next part -------------- $jhsdb clhsdb --help --exe --core --pid --pid and --exe are mutually execlusive, and --core only goes with --exe. Arguments following the --exe and --core can be absolute or relative path. Examples: jhsdb clhsdb --pid or jhsdb clhsdb --exe --core $jhsdb debugd --help --serverid --exe --core --pid --pid and --exe are mutually execlusive, and --core only goes with --exe. Arguments following the --exe and --core can be absolute or relative path. Examples: jhsdb debugd --pid or jhsdb debugd --exe --core $jhsdb hsdb --help --exe --core --pid --pid and --exe are mutually execlusive, and --core only goes with --exe. Arguments following the --exe and --core can be absolute or relative path. Examples: jhsdb hsdb --pid or jhsdb hsdb --exe --core $jhsdb jstack --help --locks --mixed --exe --core --pid --pid and --exe are mutually execlusive, and --core only goes with --exe. Arguments following the --exe and --core can be absolute or relative path. Examples: jhsdb jstack --pid or jhsdb jstack --exe --core $jhsdb jmap --help --heap --binaryheap --dumpfile --histo --clstats --finalizerinfo --exe --core --pid --pid and --exe are mutually execlusive, and --core only goes with --exe. Arguments following the --exe and --core can be absolute or relative path. Examples: jhsdb jmap --pid or jhsdb jmap --exe --core $jhsdb jinfo --help --flags --sysprops --exe --core --pid --pid and --exe are mutually execlusive, and --core only goes with --exe. Arguments following the --exe and --core can be absolute or relative path. Examples: jhsdb jinfo --pid or jhsdb jinfo --exe --core $jhsdb jsnap --help --all --exe --core --pid --pid and --exe are mutually execlusive, and --core only goes with --exe. Arguments following the --exe and --core can be absolute or relative path. Examples: jhsdb jsnap --pid or jhsdb jsnap --exe --core Please review the backport of this fix to JDK 12. The JDK 12 changes applied mostly smoothly, but one hunk in make/test/JtregNativeJdk.gmk didn't apply because of changed context lines. That's the only difference. Webrev: http://cr.openjdk.java.net/~dtitov/backports/jdk12u/8214545/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 Main webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.03 Testing: sun/management/jmxremote/bootstrap, jdk_svc, tier1, tier2 and tier3 tests succeeded. Thanks! --Daniil From david.holmes at oracle.com Fri May 24 02:21:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 May 2019 12:21:02 +1000 Subject: [12u] RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: <7C47A712-8750-4D3D-B6EF-A2605D14B1EB@oracle.com> References: <7C47A712-8750-4D3D-B6EF-A2605D14B1EB@oracle.com> Message-ID: <596bff81-01fb-eb8b-a38a-a7e4866198db@oracle.com> Looks good. Thanks, David On 24/05/2019 11:22 am, Daniil Titov wrote: > Please review the backport of this fix to JDK 12. The JDK 12 changes applied mostly smoothly, but one hunk in make/test/JtregNativeJdk.gmk didn't apply because of changed context lines. That's the only difference. > > Webrev: http://cr.openjdk.java.net/~dtitov/backports/jdk12u/8214545/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > Main webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.03 > > Testing: sun/management/jmxremote/bootstrap, jdk_svc, tier1, tier2 and tier3 tests succeeded. > > Thanks! > --Daniil > > > From serguei.spitsyn at oracle.com Fri May 24 09:44:25 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 May 2019 02:44:25 -0700 Subject: RFR: 8224252: [TESTBUG] hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java is timing out again after fix for JDK-8163805 In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 24 09:55:48 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 May 2019 02:55:48 -0700 Subject: [12u] RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: <7C47A712-8750-4D3D-B6EF-A2605D14B1EB@oracle.com> References: <7C47A712-8750-4D3D-B6EF-A2605D14B1EB@oracle.com> Message-ID: <3d42ce70-852b-7b02-1f40-ff7063a9ec77@oracle.com> Hi Daniil, The fix has been applied cleanly. LGTM++ Thanks, Serguei On 5/23/19 18:22, Daniil Titov wrote: > Please review the backport of this fix to JDK 12. The JDK 12 changes applied mostly smoothly, but one hunk in make/test/JtregNativeJdk.gmk didn't apply because of changed context lines. That's the only difference. > > Webrev: http://cr.openjdk.java.net/~dtitov/backports/jdk12u/8214545/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 > Main webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.03 > > Testing: sun/management/jmxremote/bootstrap, jdk_svc, tier1, tier2 and tier3 tests succeeded. > > Thanks! > --Daniil > > > From yasuenag at gmail.com Fri May 24 10:00:24 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 24 May 2019 19:00:24 +0900 Subject: RFR: 8224252: [TESTBUG] hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java is timing out again after fix for JDK-8163805 In-Reply-To: References: Message-ID: Hi Serguei, Other changes are included to improve reliability of testcase. DebugServer would show "Debugger attached ..." when attach operation is completed. So I change its value. Then the testcase should wait until debugd process is terminated normaly. So I added waitFor() call. Null check of "app" would be done in stopApp(). So I remove it. Thanks, Yasumasa 2019?5?24?(?) 18:44 serguei.spitsyn at oracle.com : > Hi Yasumasa, > > I'm a little bit confused with this fix. > If this test is failed on Windows only then the line: > + * @requires os.family != "windows" > > prevents the test to be run on Windows (which looks Okay to me). > > Then why are there other fixes (excluding the comment with bug numbers)? > Your summary below only tells about problem on Windows. > What was motivation for these changes? > > Thanks, > Serguei > > > On 5/23/19 17:23, Yasumasa Suenaga wrote: > > Hi all, > > Please review this change. > This webrev has passed all tests on submit repo > (mach5-one-ysuenaga-JDK-8224252-3-20190523-0532-2647154). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8224252 > webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8224252/webrev.00/ > > JDK-8163805 was suppose to fix a timeout issue with this test and also > removed it off the problemlist. However, it still times out on > windows-x64 about 1/3 of the time. It passes every time on all the > other platforms. > > Root cause of this is `jhsdb debugd` could not be exited normally. > > `jhsdb debugd` (internally, DebugServer.java) would detach from > debuggee at shutdown hook. So jhsdb process need to be exited > normally. > `jhsdb debugd` could not exit itself without external operation (e.g. > CTRL+C, signals). Thus we use Process::destroy for it. > In the case of Windows, Process::destroy calls TerminateProcess() > Windows API to terminate process. However it would terminate target > process immediately and it would not give a chance to kick shutdown > hook. (It is documented on Javadoc of Runtime::addShutdownHook) > > > Thanks, > > Yasumasa > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.schmelter at sap.com Fri May 24 12:05:24 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Fri, 24 May 2019 12:05:24 +0000 Subject: RFR (S) 8224673: Adjust permission for delayed starting of debugging Message-ID: Please review this small change. It changes the permission needed to delayed start the debugging (when enabled with onjcmd=y) via a diagnostic mbean. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8224673/webrev.0/ bugreport: https://bugs.openjdk.java.net/browse/JDK-8224673 Best regards, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.adams at oracle.com Fri May 24 12:17:44 2019 From: gary.adams at oracle.com (Gary Adams) Date: Fri, 24 May 2019 08:17:44 -0400 Subject: RFR: JDK-8218701: jdb tests failed with AGENT_ERROR_INVALID_THREAD In-Reply-To: <5300d20e-dff9-7581-de49-275994ed7354@oracle.com> References: <3fed4729-b7b3-1866-5ea0-dccdd9365f46@oracle.com> <5300d20e-dff9-7581-de49-275994ed7354@oracle.com> Message-ID: <5CE7E0E8.3050901@oracle.com> I have not tracked down the specific root cause of this failure, yet. It appears that the suspend is being attempted *before* the thread has been recorded in *threadControl*. Adding diagnostic messages is tricky because it changes the timing. Here's a minimal probe to track threadControl addNode and clearThread transactions. See attached log.txt. diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c b/src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c --- a/src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c +++ b/src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c @@ -491,7 +491,9 @@ static void suspendWithInvokeEnabled(jbyte policy, jthread thread) { + /* if (threadControl_getInvokeRequest(thread) != NULL) { */ invoker_enableInvokeRequests(thread); + /* } */ if (policy == JDWP_SUSPEND_POLICY(ALL)) { (void)threadControl_suspendAll(); diff --git a/src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c b/src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c --- a/src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c +++ b/src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c @@ -285,6 +285,7 @@ static void addNode(ThreadList *list, ThreadNode *node) { + printf ("addNode %p \n", node->thread); node->next = NULL; node->prev = NULL; node->list = NULL; @@ -362,6 +363,7 @@ static void clearThread(JNIEnv *env, ThreadNode *node) { + printf("clearThread %p\n", node->thread); if (node->pendingStop != NULL) { tossGlobalRef(env, &(node->pendingStop)); } @@ -1646,6 +1648,8 @@ node = findThread(&runningThreads, thread); if (node != NULL) { request = &node->currentInvoke; + } else { + printf ("threadControl_getInvokeRequest %p\n", thread); } debugMonitorExit(threadLock); The AGENT_ERROR_INVALID_THREAD is reported when invoker_enableInvokeRequest does not find the thread. I added the print out in threadControl_getInvokeRequest when the thread is not found. The workaround bypasses the error and falls through to the threadControl CommonSuspend path where runningThreads is complimented with an otherThreads mechanism to ensure threads that are not between start and end events will be properly resumed later on. On 5/23/19, 1:23 PM, Chris Plummer wrote: > Hi Gary, > > So a JVMTI event came in on a valid thread, got processed by the Debug > Agent and enqueued to be sent to the Debugger. However, before it was > actually sent, the thread became invalid. Am I understanding this > issue correctly? > > thanks, > > Chris > > On 5/23/19 2:59 AM, gary.adams at oracle.com wrote: >> This proposed workaround ensures that the delay between a suspend >> request >> passing through the jdwp command queue will not fail due to a no longer >> running thread. >> >> Webrev: http://cr.openjdk.java.net/~gadams/8218701/webrev/ >> Issue: https://bugs.openjdk.java.net/browse/JDK-8218701 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: log.txt URL: From christoph.langer at sap.com Fri May 24 13:25:05 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 24 May 2019 13:25:05 +0000 Subject: RFR (S) 8224673: Adjust permission for delayed starting of debugging In-Reply-To: References: Message-ID: Hi Ralf, looks good. I think this is the better permission to use here. Best regards Christoph From: serviceability-dev On Behalf Of Schmelter, Ralf Sent: Freitag, 24. Mai 2019 14:05 To: serviceability-dev at openjdk.java.net Subject: [CAUTION] RFR (S) 8224673: Adjust permission for delayed starting of debugging Please review this small change. It changes the permission needed to delayed start the debugging (when enabled with onjcmd=y) via a diagnostic mbean. webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8224673/webrev.0/ bugreport: https://bugs.openjdk.java.net/browse/JDK-8224673 Best regards, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 24 15:35:27 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 May 2019 08:35:27 -0700 Subject: RFR: 8224252: [TESTBUG] hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java is timing out again after fix for JDK-8163805 In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From serguei.spitsyn at oracle.com Fri May 24 18:48:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 24 May 2019 11:48:14 -0700 Subject: RFR (S) 8224673: Adjust permission for delayed starting of debugging In-Reply-To: References: Message-ID: <310f1305-5e37-ed37-0061-0326f864e4d9@oracle.com> An HTML attachment was scrubbed... URL: From alexey.menkov at oracle.com Fri May 24 19:25:52 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Fri, 24 May 2019 12:25:52 -0700 Subject: [12u] RFR: 8214545: sun/management/jmxremote/bootstrap tests hang in revokeall.exe on Windows In-Reply-To: <3d42ce70-852b-7b02-1f40-ff7063a9ec77@oracle.com> References: <7C47A712-8750-4D3D-B6EF-A2605D14B1EB@oracle.com> <3d42ce70-852b-7b02-1f40-ff7063a9ec77@oracle.com> Message-ID: <3f63e2eb-5a9a-9705-39d0-c9a4bf0bd293@oracle.com> +1 --alex On 05/24/2019 02:55, serguei.spitsyn at oracle.com wrote: > Hi Daniil, > > The fix has been applied cleanly. > LGTM++ > > Thanks, > Serguei > > On 5/23/19 18:22, Daniil Titov wrote: >> Please review the backport of this fix to JDK 12. The JDK 12 changes >> applied mostly smoothly, but one hunk in make/test/JtregNativeJdk.gmk >> didn't apply because of changed context lines. That's the only >> difference. >> >> Webrev: >> http://cr.openjdk.java.net/~dtitov/backports/jdk12u/8214545/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8214545 >> Main webrev: http://cr.openjdk.java.net/~dtitov/8214545/webrev.03 >> >> Testing: sun/management/jmxremote/bootstrap, jdk_svc, tier1, tier2 and >> tier3 tests succeeded. >> >> Thanks! >> --Daniil >> >> >> > From chris.plummer at oracle.com Fri May 24 20:33:52 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 May 2019 13:33:52 -0700 Subject: RFR: 8224252: [TESTBUG] hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java is timing out again after fix for JDK-8163805 In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Fri May 24 21:01:18 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 May 2019 14:01:18 -0700 Subject: RFR: JDK-8218701: jdb tests failed with AGENT_ERROR_INVALID_THREAD In-Reply-To: <5CE7E0E8.3050901@oracle.com> References: <3fed4729-b7b3-1866-5ea0-dccdd9365f46@oracle.com> <5300d20e-dff9-7581-de49-275994ed7354@oracle.com> <5CE7E0E8.3050901@oracle.com> Message-ID: <915b5ea3-745f-0bb3-158a-54504c242191@oracle.com> An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri May 24 23:06:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 25 May 2019 09:06:00 +1000 Subject: RFR (S) 8224673: Adjust permission for delayed starting of debugging In-Reply-To: References: Message-ID: <92e308d4-8dbd-b84e-a6f1-1126a6bc25c4@oracle.com> Hi Ralf, This will need a CSR request to change the permission. Thanks, David On 24/05/2019 10:05 pm, Schmelter, Ralf wrote: > Please review this small change. It changes the permission needed to > delayed start the debugging (when enabled with onjcmd=y) via a > diagnostic mbean. > > webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8224673/webrev.0/ > > bugreport: https://bugs.openjdk.java.net/browse/JDK-8224673 > > Best regards, > > Ralf > From yasuenag at gmail.com Fri May 24 23:25:04 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 25 May 2019 08:25:04 +0900 Subject: RFR: 8224252: [TESTBUG] hotspot/test/serviceability/sa/sadebugd/SADebugDTest.java is timing out again after fix for JDK-8163805 In-Reply-To: References: Message-ID: Thanks Serguei and Chris! Yasumasa 2019?5?25?(?) 5:35 Chris Plummer : > +1 > > On 5/24/19 8:35 AM, serguei.spitsyn at oracle.com wrote: > > Hi Yusamasa, > > Thank you for the clarifications! > It looks good to me. > > Thanks, > Serguei > > > On 5/24/19 03:00, Yasumasa Suenaga wrote: > > Hi Serguei, > > Other changes are included to improve reliability of testcase. > > DebugServer would show "Debugger attached ..." when attach operation is > completed. So I change its value. > Then the testcase should wait until debugd process is terminated normaly. > So I added waitFor() call. > > Null check of "app" would be done in stopApp(). So I remove it. > > > Thanks, > > Yasumasa > > 2019?5?24?(?) 18:44 serguei.spitsyn at oracle.com >: > >> Hi Yasumasa, >> >> I'm a little bit confused with this fix. >> If this test is failed on Windows only then the line: >> + * @requires os.family != "windows" >> >> prevents the test to be run on Windows (which looks Okay to me). >> >> Then why are there other fixes (excluding the comment with bug numbers)? >> Your summary below only tells about problem on Windows. >> What was motivation for these changes? >> >> Thanks, >> Serguei >> >> >> On 5/23/19 17:23, Yasumasa Suenaga wrote: >> >> Hi all, >> >> Please review this change. >> This webrev has passed all tests on submit repo >> (mach5-one-ysuenaga-JDK-8224252-3-20190523-0532-2647154). >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8224252 >> webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8224252/webrev.00/ >> >> JDK-8163805 was suppose to fix a timeout issue with this test and also >> removed it off the problemlist. However, it still times out on >> windows-x64 about 1/3 of the time. It passes every time on all the >> other platforms. >> >> Root cause of this is `jhsdb debugd` could not be exited normally. >> >> `jhsdb debugd` (internally, DebugServer.java) would detach from >> debuggee at shutdown hook. So jhsdb process need to be exited >> normally. >> `jhsdb debugd` could not exit itself without external operation (e.g. >> CTRL+C, signals). Thus we use Process::destroy for it. >> In the case of Windows, Process::destroy calls TerminateProcess() >> Windows API to terminate process. However it would terminate target >> process immediately and it would not give a chance to kick shutdown >> hook. (It is documented on Javadoc of Runtime::addShutdownHook) >> >> >> Thanks, >> >> Yasumasa >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.plummer at oracle.com Sat May 25 06:24:32 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 24 May 2019 23:24:32 -0700 Subject: RFR: JDK-8218701: jdb tests failed with AGENT_ERROR_INVALID_THREAD In-Reply-To: <915b5ea3-745f-0bb3-158a-54504c242191@oracle.com> References: <3fed4729-b7b3-1866-5ea0-dccdd9365f46@oracle.com> <5300d20e-dff9-7581-de49-275994ed7354@oracle.com> <5CE7E0E8.3050901@oracle.com> <915b5ea3-745f-0bb3-158a-54504c242191@oracle.com> Message-ID: <19ca0e95-55b0-9e96-d295-268c4c0c648b@oracle.com> An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon May 27 08:24:18 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 May 2019 08:24:18 +0000 Subject: RFR (S) 8224673: Adjust permission for delayed starting of debugging In-Reply-To: <92e308d4-8dbd-b84e-a6f1-1126a6bc25c4@oracle.com> References: <92e308d4-8dbd-b84e-a6f1-1126a6bc25c4@oracle.com> Message-ID: Hi David, ok, as for the general need for a CSR. There's some history here: When the initial change was made for that feature (delayed start of debugging, [0]), we missed going through the CSR process. After Alan had discovered this, Ralf created a CSR [1] to retroactively review this item. However, nothing happened on it yet on the review side. Now Ralf also has a (reviewed) code change regarding an additional jcmd to get the listen address of the debugger [2], [3]. And now there's also this item to update the required permission. I'm wondering whether we should use the CSR 8223456 to discuss all of this context... Do you think that's appropriate? Thanks Christoph [0] https://bugs.openjdk.java.net/browse/JDK-8214892 [1] https://bugs.openjdk.java.net/browse/JDK-8223456 [2] https://bugs.openjdk.java.net/browse/JDK-8223065 [3] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-April/027833.html > -----Original Message----- > From: serviceability-dev On > Behalf Of David Holmes > Sent: Samstag, 25. Mai 2019 01:06 > To: Schmelter, Ralf ; serviceability- > dev at openjdk.java.net > Subject: Re: RFR (S) 8224673: Adjust permission for delayed starting of > debugging > > Hi Ralf, > > This will need a CSR request to change the permission. > > Thanks, > David > > On 24/05/2019 10:05 pm, Schmelter, Ralf wrote: > > Please review this small change. It changes the permission needed to > > delayed start the debugging (when enabled with onjcmd=y) via a > > diagnostic mbean. > > > > webrev: > http://cr.openjdk.java.net/~rschmelter/webrevs/8224673/webrev.0/ > > > > bugreport: https://bugs.openjdk.java.net/browse/JDK-8224673 > > > > Best regards, > > > > Ralf > > From shade at redhat.com Mon May 27 10:36:41 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 May 2019 12:36:41 +0200 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" Message-ID: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8224796 x86_32 tier1 tests time out (actually, fail) because of this. In short, recent change to compile C code with --std=c99 got "i386" undefined. Build system still sets "i586", and we should really use that. I don't want to regress stuff much by globally replacing i386->i586, so the new code handles *both* defines. This is what "handle both x86_64 and amd64" block in LinuxDebuggerLocal.c already does. I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. Fix: http://cr.openjdk.java.net/~shade/8224796/webrev.01/ Testing: {x86_64, x86_32} tier1; jdk-submit (running) -- Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From david.holmes at oracle.com Mon May 27 11:15:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2019 21:15:33 +1000 Subject: RFR (S) 8224673: Adjust permission for delayed starting of debugging In-Reply-To: References: <92e308d4-8dbd-b84e-a6f1-1126a6bc25c4@oracle.com> Message-ID: <2a7b83d2-f5dd-0e14-4c79-3dfced036696@oracle.com> Hi Christoph, On 27/05/2019 6:24 pm, Langer, Christoph wrote: > Hi David, > > ok, as for the general need for a CSR. > > There's some history here: When the initial change was made for that feature (delayed start of debugging, [0]), we missed going through the CSR process. After Alan had discovered this, Ralf created a CSR [1] to retroactively review this item. However, nothing happened on it yet on the review side. Now Ralf also has a (reviewed) code change regarding an additional jcmd to get the listen address of the debugger [2], [3]. And now there's also this item to update the required permission. > > I'm wondering whether we should use the CSR 8223456 to discuss all of this context... Do you think that's appropriate? That's a bit of a mess :( The thing is that this code has been released in 12 and is now being changed in 13 - so that's the compatibility risk I want to see assessed for this issue, not the original enhancement request. So I think the retrospective CSR needs to be handled independently and based on what actually got pushed in 12. Then a separate CSR for this issue. But feel free to raise on csr-discuss at openjdk.java.net David ----- > Thanks > Christoph > > [0] https://bugs.openjdk.java.net/browse/JDK-8214892 > [1] https://bugs.openjdk.java.net/browse/JDK-8223456 > [2] https://bugs.openjdk.java.net/browse/JDK-8223065 > [3] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-April/027833.html > > > >> -----Original Message----- >> From: serviceability-dev On >> Behalf Of David Holmes >> Sent: Samstag, 25. Mai 2019 01:06 >> To: Schmelter, Ralf ; serviceability- >> dev at openjdk.java.net >> Subject: Re: RFR (S) 8224673: Adjust permission for delayed starting of >> debugging >> >> Hi Ralf, >> >> This will need a CSR request to change the permission. >> >> Thanks, >> David >> >> On 24/05/2019 10:05 pm, Schmelter, Ralf wrote: >>> Please review this small change. It changes the permission needed to >>> delayed start the debugging (when enabled with onjcmd=y) via a >>> diagnostic mbean. >>> >>> webrev: >> http://cr.openjdk.java.net/~rschmelter/webrevs/8224673/webrev.0/ >>> >>> bugreport: https://bugs.openjdk.java.net/browse/JDK-8224673 >>> >>> Best regards, >>> >>> Ralf >>> From david.holmes at oracle.com Mon May 27 11:21:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 27 May 2019 21:21:58 +1000 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> Message-ID: <64760841-ed2e-afc5-9d76-80feec62960d@oracle.com> Hi Aleksey, On 27/05/2019 8:36 pm, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224796 > > x86_32 tier1 tests time out (actually, fail) because of this. > > In short, recent change to compile C code with --std=c99 got "i386" undefined. Build system still > sets "i586", and we should really use that. I don't want to regress stuff much by globally replacing > i386->i586, so the new code handles *both* defines. This is what "handle both x86_64 and amd64" > block in LinuxDebuggerLocal.c already does. I think the existing logic in that file is already quite confused. It should be using defines set by the build system only, to identify CPU etc, not compiler specific defines. So I really don't think we need to keep the i386 stuff in that file as it just adds to the confusion. But I won't fight you on it. > I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. There is no 32-bit macOS build AFAIK. Thanks, David > Fix: > http://cr.openjdk.java.net/~shade/8224796/webrev.01/ > > Testing: {x86_64, x86_32} tier1; jdk-submit (running) > From ralf.schmelter at sap.com Mon May 27 13:23:27 2019 From: ralf.schmelter at sap.com (Schmelter, Ralf) Date: Mon, 27 May 2019 13:23:27 +0000 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd Message-ID: I need reviews for the following CSR: https://bugs.openjdk.java.net/browse/JDK-8223456 Note that this CSR is for a feature which already was commited to JDK 12. Best regards, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon May 27 13:44:34 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 27 May 2019 14:44:34 +0100 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: References: Message-ID: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> On 27/05/2019 14:23, Schmelter, Ralf wrote: > > I need reviews for the following CSR: > https://bugs.openjdk.java.net/browse/JDK-8223456 > > Note that this CSR is for a feature which already was commited to JDK 12. > > I think this feature needs to be re-examined, maybe backed out or the onjcmd sub-option hidden from the help output if we can't get agreement before JDK 13 RDP1. It's unfortunate that it was pushed to JDK 12 without a CSR because that would have been the opportunity to ask questions. The problem with this feature is that it ties the debugger agent to a unrelated JDK-specific tool. It feels like it conflates two things.? So I think the "feature" needs to be re-discussed to see whether the scenario is really compelling and to see the list of alternatives that were explored. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon May 27 14:33:59 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 May 2019 14:33:59 +0000 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> References: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> Message-ID: Hi Alan, > On 27/05/2019 14:23, Schmelter, Ralf wrote: > > I need reviews for the following CSR: > https://bugs.openjdk.java.net/browse/JDK-8223456 > Note that this CSR is for a feature which already was commited to JDK 12. > > I think this feature needs to be re-examined, maybe backed out or the > onjcmd sub-option hidden from the help output if we can't get agreement > before JDK 13 RDP1. It's unfortunate that it was pushed to JDK 12 without a > CSR because that would have been the opportunity to ask questions. The > problem with this feature is that it ties the debugger agent to a unrelated > JDK-specific tool. It feels like it conflates two things.? So I think the "feature" > needs to be re-discussed to see whether the scenario is really compelling > and to see the list of alternatives that were explored. I don't fully understand what you are saying, especially the part "it ties the debugger agent to a unrelated JDK-specific tool". The principal feature here is that one wants to be able to "debug on demand". Currently (or before the change that we're discussing was implemented) one had to start the JVM with the JDWP agent activated in case one's planning to debug. The "onjcmd" option gives the possibility to start the JDWP agent in a standby mode and later on activate the actual debugging. The most common way will probably be to use jcmd but there are also other ways using MXBeans to trigger the debugging. So I don't see the tie to a certain JDK-specific tool here. I think the overall story of "debugging on demand" is quite compelling. We've had that for years in SAP's proprietary JVM and it was well received by the users. It gives you the option to connect with the debugger post mortem to analyze issues. Anyway, I have reviewed Ralf's CSR and we've put it to status "Proposed". We're open for discussion, of course, on how to optimally implement this in OpenJDK. E.g. I personally don't think the naming of the option "onjcmd" is a good choice. And there's probably more around this feature which we'd need such as means to get the listen address of the debugger (or to get the JDWP agent's configuration, reconfigure it or disarm it). Maybe this can all be part of the CSR (or an upcoming CSR). Maybe it's even a candidate for a JEP, I don't know. So let's use the CSR to discuss this. By the way, I had asked at the time the change was reviewed, whether we needed a CSR [0] but didn't get a response. Sometimes it's not easy to get people involved and a fruitful discussion started, like the one you are obviously wishing for... Best regards Christoph [0] https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-December/026360.html From shade at redhat.com Mon May 27 17:05:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 27 May 2019 19:05:39 +0200 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <64760841-ed2e-afc5-9d76-80feec62960d@oracle.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> <64760841-ed2e-afc5-9d76-80feec62960d@oracle.com> Message-ID: <866729db-80ad-7d11-d27d-e8e8be7f204d@redhat.com> On 5/27/19 1:21 PM, David Holmes wrote: > I think the existing logic in that file is already quite confused. It should be using defines set by > the build system only, to identify CPU etc, not compiler specific defines. So I really don't think > we need to keep the i386 stuff in that file as it just adds to the confusion. But I won't fight you > on it. Yeah, I was on the fence here too, but don't want to risk more regressions. The "ifs" were rewritten i586 to get the "proper" macro, and the i386 fallback block is just for additional safety. >> I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. > > There is no 32-bit macOS build AFAIK. I don't quite understand the comment here: do you suggest to remove that block, or? I am leaning on capturing i586 everywhere i386 was captured before. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From david.holmes at oracle.com Mon May 27 22:19:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2019 08:19:37 +1000 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: References: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> Message-ID: <73fd1923-e9ba-a1e4-08c1-ac691eb48c30@oracle.com> On 28/05/2019 12:33 am, Langer, Christoph wrote: > Hi Alan, > >> On 27/05/2019 14:23, Schmelter, Ralf wrote: >> >> I need reviews for the following CSR: >> https://bugs.openjdk.java.net/browse/JDK-8223456 >> Note that this CSR is for a feature which already was commited to JDK 12. >> >> I think this feature needs to be re-examined, maybe backed out or the >> onjcmd sub-option hidden from the help output if we can't get agreement >> before JDK 13 RDP1. It's unfortunate that it was pushed to JDK 12 without a >> CSR because that would have been the opportunity to ask questions. The >> problem with this feature is that it ties the debugger agent to a unrelated >> JDK-specific tool. It feels like it conflates two things.? So I think the "feature" >> needs to be re-discussed to see whether the scenario is really compelling >> and to see the list of alternatives that were explored. > > I don't fully understand what you are saying, especially the part "it ties the debugger agent to a unrelated JDK-specific tool". > > The principal feature here is that one wants to be able to "debug on demand". Currently (or before the change that we're discussing was implemented) one had to start the JVM with the JDWP agent activated in case one's planning to debug. The "onjcmd" option gives the possibility to start the JDWP agent in a standby mode and later on activate the actual debugging. The most common way will probably be to use jcmd but there are also other ways using MXBeans to trigger the debugging. So I don't see the tie to a certain JDK-specific tool here. > > I think the overall story of "debugging on demand" is quite compelling. We've had that for years in SAP's proprietary JVM and it was well received by the users. It gives you the option to connect with the debugger post mortem to analyze issues. > > Anyway, I have reviewed Ralf's CSR and we've put it to status "Proposed". We're open for discussion, of course, on how to optimally implement this in OpenJDK. E.g. I personally don't think the naming of the option "onjcmd" is a good choice. And there's probably more around this feature which we'd need such as means to get the listen address of the debugger (or to get the JDWP agent's configuration, reconfigure it or disarm it). Maybe this can all be part of the CSR (or an upcoming CSR). Maybe it's even a candidate for a JEP, I don't know. So let's use the CSR to discuss this. > > By the way, I had asked at the time the change was reviewed, whether we needed a CSR [0] but didn't get a response. Sometimes it's not easy to get people involved and a fruitful discussion started, like the one you are obviously wishing for... I find it frustrating, from a CSR Group member perspective, that people too often need someone else to tell them a CSR is, or is not, needed rather than being able to evaluate that for themselves. Thinking about the need for a CSR request should be on everyone's "checklist" before proposing any new feature or significant change. And yes it should also be part of the reviewer's review criteria. That said the only guaranteed additional exposure a CSR provides is to the CSR Group lead - Joe - who will do the actual approval. Even CSR Group members don't get notified of new CSRs - they are just JBS issues and you have to watch the right component/subcomponent to get notifications. So there is no guarantee that a CSR would have provoked any detailed discussion at the time - unless Joe flagged it for some reason. David ----- > Best regards > Christoph > > [0] https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-December/026360.html > From david.holmes at oracle.com Mon May 27 22:22:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2019 08:22:04 +1000 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <866729db-80ad-7d11-d27d-e8e8be7f204d@redhat.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> <64760841-ed2e-afc5-9d76-80feec62960d@oracle.com> <866729db-80ad-7d11-d27d-e8e8be7f204d@redhat.com> Message-ID: <37308f7c-6db8-85eb-41f5-3528822d28cd@oracle.com> On 28/05/2019 3:05 am, Aleksey Shipilev wrote: > On 5/27/19 1:21 PM, David Holmes wrote: >> I think the existing logic in that file is already quite confused. It should be using defines set by >> the build system only, to identify CPU etc, not compiler specific defines. So I really don't think >> we need to keep the i386 stuff in that file as it just adds to the confusion. But I won't fight you >> on it. > > Yeah, I was on the fence here too, but don't want to risk more regressions. The "ifs" were rewritten > i586 to get the "proper" macro, and the i386 fallback block is just for additional safety. > >>> I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. >> >> There is no 32-bit macOS build AFAIK. > > I don't quite understand the comment here: do you suggest to remove that block, or? I am leaning on > capturing i586 everywhere i386 was captured before. That code is never built for 32-bit so neither i386 or i586 will ever be defined there. You can make the change but nothing will ever test it. Cheers, David > Thanks, > -Aleksey > From yasuenag at gmail.com Mon May 27 22:30:32 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 28 May 2019 07:30:32 +0900 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: References: <2fb150f9-89ff-84d1-dfa1-9d8ff3d59806@oracle.com> Message-ID: <2dff4cfa-a4c5-b6a4-d55d-ab0f083c4a24@gmail.com> Hi Osamu, Your change looks good to me. I will sponsor you. Serguei, do you have any comments to attached help messages? Thanks, Yasumasa On 2019/05/24 10:11, Osamu Sakamoto wrote: > Hi Serguei, > > Thank for reviewing. > > > But could you, please, send the output that the help command will > > print > > with your fix? > I attached all fixed --help > outputs(clhsdb/debugd/hsdb/jstack/jmap/jinfo/jsnap) to this email. > > Thanks, > Osamu > > > > On 5/24/19 03:43, serguei.spitsyn at oracle.com wrote: > > Hi Osamu, > > > > It looks Okay to me. > > But could you, please, send the output that the help command will > > print > > with your fix? > > > > Thanks, > > Serguei > > > > > > On 5/23/19 02:34, Osamu Sakamoto wrote: > >> Hi all, > >> > >> I've made the patch that was discussed here. > >> > >> > >> > >> This patch fixes the following JBS ticket. > >> > >> > >> I attached the patch to this email. > >> This patch passes serviceability/sa jtreg tests. > >> > >> Could you help? I would like to contribute it. I need a sponsor. > >> (My company has signed to OCA (NTT Comware Corporation)) > >> > >> > >> Thanks, > >> Osamu > > > From david.holmes at oracle.com Mon May 27 23:50:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2019 09:50:05 +1000 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: References: Message-ID: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> Hi Osamu, I have a lot of "suggestions" here. Writing good help output is not easy, and the more you try to do things the more you expose existing problems - which is the case here I'm afraid. I didn't fully realize the constraints these commands had in regards to how they operate either on a live process or else using a core file and executable together, so some of my previous guidance was a little mis-guided. Sorry about that. On 23/05/2019 7:34 pm, Osamu Sakamoto wrote: > Hi all, > > I've made the patch that was discussed here. > > > > This patch fixes the following JBS ticket. > > > I attached the patch to this email. > This patch passes serviceability/sa jtreg tests. + System.out.println(""); + System.out.println(" --pid and --exe are mutually execlusive, and --core only goes with --exe."); + System.out.println(" Arguments following the --exe and --core can be absolute or relative path."); This partially captures the intent that the flags are mutually exclusive but its more complex than this. I would suggest: --- The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. --- + System.out.println(" Examples: jhsdb " + mode + " --pid "); + System.out.println(" or jhsdb " + mode + " --exe --core "); As these are examples I would substitute actual values eg: --pid 1234 --core ./core.1234 --exe ./myexe --- The suggestion to use angle brackets has been taken too far - angle brackets delimit an argument to a flag, they do not delimit a description of the option. For example in: $jhsdb jstack --help --locks --mixed --exe --core --pid The: --locks should just be: --locks To print java.util.concurrent locks. The same for --mixed. I suggest turning the descriptions into sentences as shown with initial capitals and final period. But that highlights an inconsistent approach with regards to --exe/--pid/--core as we are not describing the meaning of those flags on the same line. For consistency we should have in this order: --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe This puts the focus on --core where it belongs - the --exe is just something that has to accompany --core. So that putting it all together we would have: $jhsdb jstack --help --locks To print java.util.concurrent locks. --mixed To print both Java and native frames (mixed mode). --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. ---- For: --serverid I suggest --serverid A unique identifier for this debug server. Thanks, David -------- > Could you help? I would like to contribute it. I need a sponsor. > (My company has signed to OCA (NTT Comware Corporation)) > > > Thanks, > Osamu From sakamoto.osamu at nttcom.co.jp Tue May 28 05:56:26 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Tue, 28 May 2019 14:56:26 +0900 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: <2dff4cfa-a4c5-b6a4-d55d-ab0f083c4a24@gmail.com> References: <2fb150f9-89ff-84d1-dfa1-9d8ff3d59806@oracle.com> <2dff4cfa-a4c5-b6a4-d55d-ab0f083c4a24@gmail.com> Message-ID: Hi Yasumasa, Thank you for reviewing and sponsoring. Osamu On 5/28/19 07:30, Yasumasa Suenaga wrote: > Hi Osamu, > > Your change looks good to me. > I will sponsor you. > > Serguei, do you have any comments to attached help messages? > > > Thanks, > > Yasumasa > > > On 2019/05/24 10:11, Osamu Sakamoto wrote: >> ? Hi Serguei, >> >> ? Thank for reviewing. >> >> ?? > But could you, please, send the output that the help command will >> ?? > print >> ??? > with your fix? >> ??? I attached all fixed --help >> ??? outputs(clhsdb/debugd/hsdb/jstack/jmap/jinfo/jsnap) to this email. >> >> ??? Thanks, >> ??? Osamu >> >> >> >> ??? On 5/24/19 03:43, serguei.spitsyn at oracle.com wrote: >> ??? > Hi Osamu, >> ??? > >> ??? > It looks Okay to me. >> ??? > But could you, please, send the output that the help command will >> ??? > print >> ??? > with your fix? >> ??? > >> ??? > Thanks, >> ??? > Serguei >> ??? > >> ??? > >> ??? > On 5/23/19 02:34, Osamu Sakamoto wrote: >> ??? >> Hi all, >> ??? >> >> ??? >> I've made the patch that was discussed here. >> ??? >> >> >> >> ??? >> >> ??? >> >> ??? >> This patch fixes the following JBS ticket. >> ??? >> >> ??? >> >> ??? >> I attached the patch to this email. >> ??? >> This patch passes serviceability/sa jtreg tests. >> ??? >> >> ??? >> Could you help? I would like to contribute it. I need a sponsor. >> ??? >> (My company has signed to OCA (NTT Comware Corporation)) >> ??? >> >> ??? >> >> ??? >> Thanks, >> ??? >> Osamu >> ??? > >> From sakamoto.osamu at nttcom.co.jp Tue May 28 05:57:59 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Tue, 28 May 2019 14:57:59 +0900 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> References: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> Message-ID: <2ff0c38c-9e58-fbe7-6d8e-3df1175f347a@nttcom.co.jp> Hi, David, Thank you for reviewing. I agree with your comment. I fixed the patch and Yasumasa uploaded the webrev for this fixed patch. And I attached fixed --help outputs to this mail(help2.txt). Serugui, In this patch, I added angle brackets only to parameters(--pid/--core/--exe/debugd --severid/jmap --dumpfile), not descriptions of each options. Does this form match your comment in this RFE? Thanks, Osamu On 5/28/19 08:50, David Holmes wrote: > Hi Osamu, > > I have a lot of "suggestions" here. Writing good help output is not > easy, and the more you try to do things the more you expose existing > problems - which is the case here I'm afraid. I didn't fully realize the > constraints these commands had in regards to how they operate either on > a live process or else using a core file and executable together, so > some of my previous guidance was a little mis-guided. Sorry about that. > > On 23/05/2019 7:34 pm, Osamu Sakamoto wrote: >> Hi all, >> >> I've made the patch that was discussed here. >> >> >> >> This patch fixes the following JBS ticket. >> >> >> I attached the patch to this email. >> This patch passes serviceability/sa jtreg tests. > > +??????? System.out.println(""); > +??????? System.out.println("??? --pid and --exe are mutually > execlusive, and --core only goes with --exe."); > +??????? System.out.println("??? Arguments following the --exe and > --core can be absolute or relative path."); > > This? partially captures the intent that the flags are mutually > exclusive but its more complex than this. I would suggest: > > --- > The --core and --exe options must be set together to give the core file, > and associated executable, to operate on. Otherwise the --pid option can > be set to operate on a live process. > The arguments for --exe and --core can use absolute or relative paths. > --- > > +??????? System.out.println("??? Examples: jhsdb " + mode + " --pid > "); > +??????? System.out.println("????????? or? jhsdb " + mode + " --exe > --core "); > > As these are examples I would substitute actual values eg: > > --pid 1234 > --core ./core.1234 --exe ./myexe > > --- > > The suggestion to use angle brackets has been taken too far - angle > brackets delimit an argument to a flag, they do not delimit a > description of the option. For example in: > > $jhsdb jstack --help > ??? --locks???? > ??? --mixed???? > ??? --exe?????? > ??? --core????? > ??? --pid?????? > > The: > > ??? --locks???? > > should just be: > > ??? --locks???? To print java.util.concurrent locks. > > The same for --mixed. > > I suggest turning the descriptions into sentences as shown with initial > capitals and final period. > > But that highlights an inconsistent approach with regards to > --exe/--pid/--core as we are not describing the meaning of those flags > on the same line. For consistency we should have in this order: > > ??? --pid ??????? To attach to and operate on the given live process. > ??? --core ? To operate on a given core file. > ??? --exe > > This puts the focus on --core where it belongs - the --exe is just > something that has to accompany --core. So that putting it all together > we would have: > > $jhsdb jstack --help > ?? --locks???? To print java.util.concurrent locks. > ?? --mixed???? To print both Java and native frames (mixed mode). > ?? --pid To attach to and operate on the given live process. > ?? --core ? To operate on a given core file. > ?? --exe > > ?? The --core and --exe options must be set together to give the core > ?? file, and associated executable, to operate on. Otherwise the --pid > ?? option can be set to operate on a live process. > ?? The arguments for --exe and --core can use absolute or relative paths. > ---- > > For: > > ??? --serverid? > > I suggest > > ??? --serverid? ? A unique identifier for this debug server. > > > Thanks, > David > -------- > > >> Could you help? I would like to contribute it. I need a sponsor. >> (My company has signed to OCA (NTT Comware Corporation)) >> >> >> Thanks, >> Osamu -------------- next part -------------- $jhsdb clhsdb --help --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. Examples: jhsdb clhsdb --pid 1234 or jhsdb clhsdb --core ./core.1234 --exe ./myexe $jhsdb hsdb --help --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. Examples: jhsdb hsdb --pid 1234 or jhsdb hsdb --core ./core.1234 --exe ./myexe $jhsdb debugd --help --serverid A unique identifier for this debug server. --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. Examples: jhsdb debugd --pid 1234 or jhsdb debugd --core ./core.1234 --exe ./myexe $jhsdb jstack --help --locks To print java.util.concurrent locks. --mixed To print both Java and native frames (mixed mode). --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. Examples: jhsdb jstack --pid 1234 or jhsdb jstack --core ./core.1234 --exe ./myexe $jhsdb jmap --help To print same info as Solaris pmap. --heap To print java heap summary. --binaryheap To dump java heap in hprof binary format. --dumpfile A Name of the dump file. --histo To print histogram of java object heap. --clstats To print class loader statistics. --finalizerinfo To print information on objects awaiting finalization. --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. Examples: jhsdb jmap --pid 1234 or jhsdb jmap --core ./core.1234 --exe ./myexe $jhsdb jinfo --help --flags To print VM flags. --sysprops To print Java System properties. To print both of the above. --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. Examples: jhsdb jinfo --pid 1234 or jhsdb jinfo --core ./core.1234 --exe ./myexe $jhsdb jsnap --help --all To print all performance counters. --pid To attach to and operate on the given live process. --core To operate on a given core file. --exe The --core and --exe options must be set together to give the core file, and associated executable, to operate on. Otherwise the --pid option can be set to operate on a live process. The arguments for --exe and --core can use absolute or relative paths. Examples: jhsdb jsnap --pid 1234 or jhsdb jsnap --core ./core.1234 --exe ./myexe From david.holmes at oracle.com Tue May 28 07:39:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 May 2019 17:39:06 +1000 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: <2ff0c38c-9e58-fbe7-6d8e-3df1175f347a@nttcom.co.jp> References: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> <2ff0c38c-9e58-fbe7-6d8e-3df1175f347a@nttcom.co.jp> Message-ID: <77f4ccc2-32d8-3fbc-2e02-684af64b0d56@oracle.com> Hi Osamu, On 28/05/2019 3:57 pm, Osamu Sakamoto wrote: > Hi, > > David, > Thank you for reviewing. > > I agree with your comment. > I fixed the patch and Yasumasa uploaded the webrev for this fixed patch. > > > And I attached fixed --help outputs to this mail(help2.txt). That all looks good to me - thanks. Just one minor correction in one of my suggestions: + System.out.println(" --core \tTo operate on a given core file."); s/a/the/ and one minor correction to yours: + System.out.println(" --dumpfile \tA Name of the dump file."); s/A Name/The name/ Thanks, David ----- > > Serugui, > > In this patch, I added angle brackets only to > parameters(--pid/--core/--exe/debugd --severid/jmap --dumpfile), not > descriptions of each options. > Does this form match your comment in this RFE? > > > > Thanks, > Osamu > > > On 5/28/19 08:50, David Holmes wrote: >> Hi Osamu, >> >> I have a lot of "suggestions" here. Writing good help output is not >> easy, and the more you try to do things the more you expose existing >> problems - which is the case here I'm afraid. I didn't fully realize >> the constraints these commands had in regards to how they operate >> either on a live process or else using a core file and executable >> together, so some of my previous guidance was a little mis-guided. >> Sorry about that. >> >> On 23/05/2019 7:34 pm, Osamu Sakamoto wrote: >>> Hi all, >>> >>> I've made the patch that was discussed here. >>> >>> >>> >>> This patch fixes the following JBS ticket. >>> >>> >>> I attached the patch to this email. >>> This patch passes serviceability/sa jtreg tests. >> >> +??????? System.out.println(""); >> +??????? System.out.println("??? --pid and --exe are mutually >> execlusive, and --core only goes with --exe."); >> +??????? System.out.println("??? Arguments following the --exe and >> --core can be absolute or relative path."); >> >> This? partially captures the intent that the flags are mutually >> exclusive but its more complex than this. I would suggest: >> >> --- >> The --core and --exe options must be set together to give the core >> file, and associated executable, to operate on. Otherwise the --pid >> option can be set to operate on a live process. >> The arguments for --exe and --core can use absolute or relative paths. >> --- >> >> +??????? System.out.println("??? Examples: jhsdb " + mode + " --pid >> "); >> +??????? System.out.println("????????? or? jhsdb " + mode + " --exe >> --core "); >> >> As these are examples I would substitute actual values eg: >> >> --pid 1234 >> --core ./core.1234 --exe ./myexe >> >> --- >> >> The suggestion to use angle brackets has been taken too far - angle >> brackets delimit an argument to a flag, they do not delimit a >> description of the option. For example in: >> >> $jhsdb jstack --help >> ???? --locks???? >> ???? --mixed???? >> ???? --exe?????? >> ???? --core????? >> ???? --pid?????? >> >> The: >> >> ???? --locks???? >> >> should just be: >> >> ???? --locks???? To print java.util.concurrent locks. >> >> The same for --mixed. >> >> I suggest turning the descriptions into sentences as shown with >> initial capitals and final period. >> >> But that highlights an inconsistent approach with regards to >> --exe/--pid/--core as we are not describing the meaning of those flags >> on the same line. For consistency we should have in this order: >> >> ???? --pid ??????? To attach to and operate on the given live >> process. >> ???? --core ? To operate on a given core file. >> ???? --exe >> >> This puts the focus on --core where it belongs - the --exe is just >> something that has to accompany --core. So that putting it all >> together we would have: >> >> $jhsdb jstack --help >> ??? --locks???? To print java.util.concurrent locks. >> ??? --mixed???? To print both Java and native frames (mixed mode). >> ??? --pid To attach to and operate on the given live process. >> ??? --core ? To operate on a given core file. >> ??? --exe >> >> ??? The --core and --exe options must be set together to give the core >> ??? file, and associated executable, to operate on. Otherwise the --pid >> ??? option can be set to operate on a live process. >> ??? The arguments for --exe and --core can use absolute or relative >> paths. >> ---- >> >> For: >> >> ???? --serverid? >> >> I suggest >> >> ???? --serverid? ? A unique identifier for this debug server. >> >> >> Thanks, >> David >> -------- >> >> >>> Could you help? I would like to contribute it. I need a sponsor. >>> (My company has signed to OCA (NTT Comware Corporation)) >>> >>> >>> Thanks, >>> Osamu > > From shade at redhat.com Tue May 28 07:39:43 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 May 2019 09:39:43 +0200 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> Message-ID: <5f452593-87d3-5039-051e-915ec76bf29c@redhat.com> On 5/27/19 12:36 PM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224796 > > x86_32 tier1 tests time out (actually, fail) because of this. > > In short, recent change to compile C code with --std=c99 got "i386" undefined. Build system still > sets "i586", and we should really use that. I don't want to regress stuff much by globally replacing > i386->i586, so the new code handles *both* defines. This is what "handle both x86_64 and amd64" > block in LinuxDebuggerLocal.c already does. > > I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. > > Fix: > http://cr.openjdk.java.net/~shade/8224796/webrev.01/ David had reviewed. More reviews, please? -- Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From christoph.langer at sap.com Tue May 28 07:57:01 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 May 2019 07:57:01 +0000 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: <73fd1923-e9ba-a1e4-08c1-ac691eb48c30@oracle.com> References: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> <73fd1923-e9ba-a1e4-08c1-ac691eb48c30@oracle.com> Message-ID: Hi David, > I find it frustrating, from a CSR Group member perspective, that people > too often need someone else to tell them a CSR is, or is not, needed > rather than being able to evaluate that for themselves. Thinking about > the need for a CSR request should be on everyone's "checklist" before > proposing any new feature or significant change. And yes it should also > be part of the reviewer's review criteria. > > That said the only guaranteed additional exposure a CSR provides is to > the CSR Group lead - Joe - who will do the actual approval. Even CSR > Group members don't get notified of new CSRs - they are just JBS issues > and you have to watch the right component/subcomponent to get > notifications. So there is no guarantee that a CSR would have provoked > any detailed discussion at the time - unless Joe flagged it for some reason. Thanks for the information. Speaking for myself, I guess I now have a better understanding of the CSR process than back in last December and would probably go for a CSR for such a change automatically. /Christoph From thomas.stuefe at gmail.com Tue May 28 08:05:40 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 28 May 2019 10:05:40 +0200 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: <73fd1923-e9ba-a1e4-08c1-ac691eb48c30@oracle.com> References: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> <73fd1923-e9ba-a1e4-08c1-ac691eb48c30@oracle.com> Message-ID: On Tue, May 28, 2019 at 12:19 AM David Holmes wrote: > On 28/05/2019 12:33 am, Langer, Christoph wrote: > > Hi Alan, > > > >> On 27/05/2019 14:23, Schmelter, Ralf wrote: > >> > >> I need reviews for the following CSR: > >> https://bugs.openjdk.java.net/browse/JDK-8223456 > >> Note that this CSR is for a feature which already was commited to JDK > 12. > >> > >> I think this feature needs to be re-examined, maybe backed out or the > >> onjcmd sub-option hidden from the help output if we can't get agreement > >> before JDK 13 RDP1. It's unfortunate that it was pushed to JDK 12 > without a > >> CSR because that would have been the opportunity to ask questions. The > >> problem with this feature is that it ties the debugger agent to a > unrelated > >> JDK-specific tool. It feels like it conflates two things. So I think > the "feature" > >> needs to be re-discussed to see whether the scenario is really > compelling > >> and to see the list of alternatives that were explored. > > > > I don't fully understand what you are saying, especially the part "it > ties the debugger agent to a unrelated JDK-specific tool". > > > > The principal feature here is that one wants to be able to "debug on > demand". Currently (or before the change that we're discussing was > implemented) one had to start the JVM with the JDWP agent activated in case > one's planning to debug. The "onjcmd" option gives the possibility to start > the JDWP agent in a standby mode and later on activate the actual > debugging. The most common way will probably be to use jcmd but there are > also other ways using MXBeans to trigger the debugging. So I don't see the > tie to a certain JDK-specific tool here. > > > > I think the overall story of "debugging on demand" is quite compelling. > We've had that for years in SAP's proprietary JVM and it was well received > by the users. It gives you the option to connect with the debugger post > mortem to analyze issues. > > > > Anyway, I have reviewed Ralf's CSR and we've put it to status > "Proposed". We're open for discussion, of course, on how to optimally > implement this in OpenJDK. E.g. I personally don't think the naming of the > option "onjcmd" is a good choice. And there's probably more around this > feature which we'd need such as means to get the listen address of the > debugger (or to get the JDWP agent's configuration, reconfigure it or > disarm it). Maybe this can all be part of the CSR (or an upcoming CSR). > Maybe it's even a candidate for a JEP, I don't know. So let's use the CSR > to discuss this. > > > > By the way, I had asked at the time the change was reviewed, whether we > needed a CSR [0] but didn't get a response. Sometimes it's not easy to get > people involved and a fruitful discussion started, like the one you are > obviously wishing for... > > I find it frustrating, from a CSR Group member perspective, that people > too often need someone else to tell them a CSR is, or is not, needed > rather than being able to evaluate that for themselves. Thinking about > the need for a CSR request should be on everyone's "checklist" before > proposing any new feature or significant change. And yes it should also > be part of the reviewer's review criteria. > > That said the only guaranteed additional exposure a CSR provides is to > the CSR Group lead - Joe - who will do the actual approval. Even CSR > Group members don't get notified of new CSRs - they are just JBS issues > and you have to watch the right component/subcomponent to get > notifications. So there is no guarantee that a CSR would have provoked > any detailed discussion at the time - unless Joe flagged it for some > reason. > > David > ----- > > Yes, the CSR process is important and needs to be carried by all. Doesn't work any other way. Joe did a good presentation at the last committers workshop in Brussels, maybe he could share the slides (again). Cheers, Thomas > > Best regards > > Christoph > > > > [0] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-December/026360.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Tue May 28 14:29:26 2019 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 28 May 2019 07:29:26 -0700 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <5f452593-87d3-5039-051e-915ec76bf29c@redhat.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> <5f452593-87d3-5039-051e-915ec76bf29c@redhat.com> Message-ID: <0911F8E1-4883-4ECE-A676-8FF37B4FF5F3@oracle.com> Looks good. The if-define-to-code ratio in LinuxDebuggerLocal.c is impressively high, in a bad way. An enhancement to cover cleaning it up sure wouldn?t hurt. Cheers, Mikael > On May 28, 2019, at 12:39 AM, Aleksey Shipilev wrote: > > On 5/27/19 12:36 PM, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8224796 >> >> x86_32 tier1 tests time out (actually, fail) because of this. >> >> In short, recent change to compile C code with --std=c99 got "i386" undefined. Build system still >> sets "i586", and we should really use that. I don't want to regress stuff much by globally replacing >> i386->i586, so the new code handles *both* defines. This is what "handle both x86_64 and amd64" >> block in LinuxDebuggerLocal.c already does. >> >> I have not seen the failures on Mac due to ps_core.c, but it is better to be safe there as well. >> >> Fix: >> http://cr.openjdk.java.net/~shade/8224796/webrev.01/ > > David had reviewed. More reviews, please? > > -- > Thanks, > -Aleksey > From volker.simonis at gmail.com Tue May 28 16:57:05 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 28 May 2019 18:57:05 +0200 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> References: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> Message-ID: Hi Alan, you may be right that the initial submitter and reviewers have missed the need of a CSR, but after all, the change itself has been correctly reviewed on serviceability-dev by your colleague Chris Plummer and my colleague Christoph Langer. I think it is a little exaggerated to claim the backout of a change which has been pushed almost 6 month ago and didn't do any harm until now, just because of a missing CSR. Such mails really demotivate new committers who did their best in order to contribute to OpenJDK. I agree that "onjcmd" may not be an optimal description for the flag. I would suggest to use "ondemand" but we can discuss that on the corresponding CSR thread. In general the change is just a part of our effort to contribute our "Debugging on Demand" feature [1] from SAP JVM to the OpenJDK. We have already contributed some parts [2] and another major part (making Escape Analysis in C2 work together with debugging) is just about to be contributed. For our proprietary SAP JVM we had a special tool called "jvmmon" which is similar to "jcmd" and which could be used to connect to a running VM and start a debugging session at any time. For OpenJDK it seemed naturally to implement this functionality in "jcmd". I don't understand what problem you see when saying that this feature "ties the debugger agent to a unrelated JDK-specific tool". The debugger agent already has quite some implementation and platform specific dependencies like different connectors and transports for example. Moreover the "Debugging on Demand" feature isn't really tied to one specific tool like "jcmd" (although the unfortunate option naming "onjcmd" may suggest that). But if you read "8223456: Delayed starting of debugging via jcmd" [3] carefully, you'll see that other tools like "jconsole" or even another Java program using the DiagnosticCommandMBean can be used just as well. I hope we can all work together in good faith and without threats to bring this feature, which has proved to be extremely useful and popular among our customers, into the OpenJDK. We are of course open for any constructive suggestion which further improve this feature. Best regards, Volker [1] https://help.sap.com/doc/saphelp_nwmobile71/7.1.18/en-US/80/3f7a2244814aad8b4a09e1c2e7629b/content.htm?no_cache=true [2] https://github.com/SAP/SapMachine/wiki/Features-Contributed-by-SAP#debugging-on-demand [3] https://bugs.openjdk.java.net/browse/JDK-8223456 On Mon, May 27, 2019 at 3:45 PM Alan Bateman wrote: > > On 27/05/2019 14:23, Schmelter, Ralf wrote: > > I need reviews for the following CSR: https://bugs.openjdk.java.net/browse/JDK-8223456 > > Note that this CSR is for a feature which already was commited to JDK 12. > > > I think this feature needs to be re-examined, maybe backed out or the onjcmd sub-option hidden from the help output if we can't get agreement before JDK 13 RDP1. It's unfortunate that it was pushed to JDK 12 without a CSR because that would have been the opportunity to ask questions. The problem with this feature is that it ties the debugger agent to a unrelated JDK-specific tool. It feels like it conflates two things. So I think the "feature" needs to be re-discussed to see whether the scenario is really compelling and to see the list of alternatives that were explored. > > -Alan From joe.darcy at oracle.com Tue May 28 17:02:52 2019 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 28 May 2019 10:02:52 -0700 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: References: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> <73fd1923-e9ba-a1e4-08c1-ac691eb48c30@oracle.com> Message-ID: <1e2035e6-0388-eef5-cede-2b7a5c8d3179@oracle.com> Hello, For more information about CSR, see the wiki page: ??? https://wiki.openjdk.java.net/display/csr and the slides from the February 2019 OCW in Brussels: http://cr.openjdk.java.net/~darcy/Presentations/OCW/ocw-CSR-2019-02.pdf The backup slides from the presentation include some information on the logistics of creating and managing a CSR. HTH, -Joe On 5/28/2019 1:05 AM, Thomas St?fe wrote: > > > On Tue, May 28, 2019 at 12:19 AM David Holmes > wrote: > > On 28/05/2019 12:33 am, Langer, Christoph wrote: > > Hi Alan, > > > >> On 27/05/2019 14:23, Schmelter, Ralf wrote: > >> > >> I need reviews for the following CSR: > >> https://bugs.openjdk.java.net/browse/JDK-8223456 > >> Note that this CSR is for a feature which already was commited > to JDK 12. > >> > >> I think this feature needs to be re-examined, maybe backed out > or the > >> onjcmd sub-option hidden from the help output if we can't get > agreement > >> before JDK 13 RDP1. It's unfortunate that it was pushed to JDK > 12 without a > >> CSR because that would have been the opportunity to ask > questions. The > >> problem with this feature is that it ties the debugger agent to > a unrelated > >> JDK-specific tool. It feels like it conflates two things.? So I > think the "feature" > >> needs to be re-discussed to see whether the scenario is really > compelling > >> and to see the list of alternatives that were explored. > > > > I don't fully understand what you are saying, especially the > part "it ties the debugger agent to a unrelated JDK-specific tool". > > > > The principal feature here is that one wants to be able to > "debug on demand". Currently (or before the change that we're > discussing was implemented) one had to start the JVM with the JDWP > agent activated in case one's planning to debug. The "onjcmd" > option gives the possibility to start the JDWP agent in a standby > mode and later on activate the actual debugging. The most common > way will probably be to use jcmd but there are also other ways > using MXBeans to trigger the debugging. So I don't see the tie to > a certain JDK-specific tool here. > > > > I think the overall story of "debugging on demand" is quite > compelling. We've had that for years in SAP's proprietary JVM and > it was well received by the users. It gives you the option to > connect with the debugger post mortem to analyze issues. > > > > Anyway, I have reviewed Ralf's CSR and we've put it to status > "Proposed". We're open for discussion, of course, on how to > optimally implement this in OpenJDK. E.g. I personally don't think > the naming of the option "onjcmd" is a good choice. And there's > probably more around this feature which we'd need such as means to > get the listen address of the debugger (or to get the JDWP agent's > configuration, reconfigure it or disarm it). Maybe this can all be > part of the CSR (or an upcoming CSR). Maybe it's even a candidate > for a JEP, I don't know. So let's use the CSR to discuss this. > > > > By the way, I had asked at the time the change was reviewed, > whether we needed a CSR [0] but didn't get a response. Sometimes > it's not easy to get people involved and a fruitful discussion > started, like the one you are obviously wishing for... > > I find it frustrating, from a CSR Group member perspective, that > people > too often need someone else to tell them a CSR is, or is not, needed > rather than being able to evaluate that for themselves. Thinking > about > the need for a CSR request should be on everyone's "checklist" before > proposing any new feature or significant change. And yes it should > also > be part of the reviewer's review criteria. > > That said the only guaranteed additional exposure a CSR provides > is to > the CSR Group lead - Joe - who will do the actual approval. Even CSR > Group members don't get notified of new CSRs - they are just JBS > issues > and you have to watch the right component/subcomponent to get > notifications. So there is no guarantee that a CSR would have > provoked > any detailed discussion at the time - unless Joe flagged it for > some reason. > > David > ----- > > > Yes, the CSR process is important and needs to be carried by all. > Doesn't work any other way. > > Joe did a good presentation at the last committers workshop > in?Brussels, maybe he could share the slides (again). > > Cheers, Thomas > > > Best regards > > Christoph > > > > [0] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-December/026360.html > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shade at redhat.com Tue May 28 19:29:49 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 May 2019 21:29:49 +0200 Subject: RFR (S) 8224796: C code is not compiled correctly due to undefined "i386" In-Reply-To: <0911F8E1-4883-4ECE-A676-8FF37B4FF5F3@oracle.com> References: <02a4645e-102b-7f72-27ff-7c601d50f08c@redhat.com> <5f452593-87d3-5039-051e-915ec76bf29c@redhat.com> <0911F8E1-4883-4ECE-A676-8FF37B4FF5F3@oracle.com> Message-ID: <904816c0-0726-0a13-9fc8-7379b4a7abe3@redhat.com> On 5/28/19 4:29 PM, Mikael Vidstedt wrote: > Looks good. Thanks. > The if-define-to-code ratio in LinuxDebuggerLocal.c is impressively high, in a bad way. An > enhancement to cover cleaning it up sure wouldn?t hurt. I agree. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From sakamoto.osamu at nttcom.co.jp Wed May 29 00:37:50 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Wed, 29 May 2019 09:37:50 +0900 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: <77f4ccc2-32d8-3fbc-2e02-684af64b0d56@oracle.com> References: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> <2ff0c38c-9e58-fbe7-6d8e-3df1175f347a@nttcom.co.jp> <77f4ccc2-32d8-3fbc-2e02-684af64b0d56@oracle.com> Message-ID: Hi David, Thank you for reviewing. I fixed the patch to include your comment. Yasumasa uploaded new webrev. Thanks, Osamu On 5/28/19 16:39, David Holmes wrote: > Hi Osamu, > > On 28/05/2019 3:57 pm, Osamu Sakamoto wrote: >> Hi, >> >> David, >> Thank you for reviewing. >> >> I agree with your comment. >> I fixed the patch and Yasumasa uploaded the webrev for this fixed patch. >> >> >> And I attached fixed --help outputs to this mail(help2.txt). > > That all looks good to me - thanks. Just one minor correction in one of > my suggestions: > > +??????? System.out.println("??? --core \tTo operate on a > given core file."); > > s/a/the/ > > and one minor correction to yours: > > +??????? System.out.println("??? --dumpfile \tA Name of the dump > file."); > > s/A Name/The name/ > > Thanks, > David > ----- > >> >> Serugui, >> >> In this patch, I added angle brackets only to >> parameters(--pid/--core/--exe/debugd --severid/jmap --dumpfile), not >> descriptions of each options. >> Does this form match your comment in this RFE? >> >> >> >> Thanks, >> Osamu >> >> >> On 5/28/19 08:50, David Holmes wrote: >>> Hi Osamu, >>> >>> I have a lot of "suggestions" here. Writing good help output is not >>> easy, and the more you try to do things the more you expose existing >>> problems - which is the case here I'm afraid. I didn't fully realize >>> the constraints these commands had in regards to how they operate >>> either on a live process or else using a core file and executable >>> together, so some of my previous guidance was a little mis-guided. >>> Sorry about that. >>> >>> On 23/05/2019 7:34 pm, Osamu Sakamoto wrote: >>>> Hi all, >>>> >>>> I've made the patch that was discussed here. >>>> >>>> >>>> >>>> This patch fixes the following JBS ticket. >>>> >>>> >>>> I attached the patch to this email. >>>> This patch passes serviceability/sa jtreg tests. >>> >>> +??????? System.out.println(""); >>> +??????? System.out.println("??? --pid and --exe are mutually >>> execlusive, and --core only goes with --exe."); >>> +??????? System.out.println("??? Arguments following the --exe and >>> --core can be absolute or relative path."); >>> >>> This? partially captures the intent that the flags are mutually >>> exclusive but its more complex than this. I would suggest: >>> >>> --- >>> The --core and --exe options must be set together to give the core >>> file, and associated executable, to operate on. Otherwise the --pid >>> option can be set to operate on a live process. >>> The arguments for --exe and --core can use absolute or relative paths. >>> --- >>> >>> +??????? System.out.println("??? Examples: jhsdb " + mode + " --pid >>> "); >>> +??????? System.out.println("????????? or? jhsdb " + mode + " --exe >>> --core "); >>> >>> As these are examples I would substitute actual values eg: >>> >>> --pid 1234 >>> --core ./core.1234 --exe ./myexe >>> >>> --- >>> >>> The suggestion to use angle brackets has been taken too far - angle >>> brackets delimit an argument to a flag, they do not delimit a >>> description of the option. For example in: >>> >>> $jhsdb jstack --help >>> ???? --locks???? >>> ???? --mixed???? >>> ???? --exe?????? >>> ???? --core????? >>> ???? --pid?????? >>> >>> The: >>> >>> ???? --locks???? >>> >>> should just be: >>> >>> ???? --locks???? To print java.util.concurrent locks. >>> >>> The same for --mixed. >>> >>> I suggest turning the descriptions into sentences as shown with >>> initial capitals and final period. >>> >>> But that highlights an inconsistent approach with regards to >>> --exe/--pid/--core as we are not describing the meaning of those >>> flags on the same line. For consistency we should have in this order: >>> >>> ???? --pid ??????? To attach to and operate on the given live >>> process. >>> ???? --core ? To operate on a given core file. >>> ???? --exe >>> >>> This puts the focus on --core where it belongs - the --exe is just >>> something that has to accompany --core. So that putting it all >>> together we would have: >>> >>> $jhsdb jstack --help >>> ??? --locks???? To print java.util.concurrent locks. >>> ??? --mixed???? To print both Java and native frames (mixed mode). >>> ??? --pid To attach to and operate on the given live process. >>> ??? --core ? To operate on a given core file. >>> ??? --exe >>> >>> ??? The --core and --exe options must be set together to give the core >>> ??? file, and associated executable, to operate on. Otherwise the --pid >>> ??? option can be set to operate on a live process. >>> ??? The arguments for --exe and --core can use absolute or relative >>> paths. >>> ---- >>> >>> For: >>> >>> ???? --serverid? >>> >>> I suggest >>> >>> ???? --serverid? ? A unique identifier for this debug server. >>> >>> >>> Thanks, >>> David >>> -------- >>> >>> >>>> Could you help? I would like to contribute it. I need a sponsor. >>>> (My company has signed to OCA (NTT Comware Corporation)) >>>> >>>> >>>> Thanks, >>>> Osamu >> >> From serguei.spitsyn at oracle.com Wed May 29 03:18:04 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 28 May 2019 20:18:04 -0700 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: References: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> <2ff0c38c-9e58-fbe7-6d8e-3df1175f347a@nttcom.co.jp> <77f4ccc2-32d8-3fbc-2e02-684af64b0d56@oracle.com> Message-ID: Hi Osamu, This update looks good to me. Thanks, Serguei On 5/28/19 17:37, Osamu Sakamoto wrote: > Hi David, > > Thank you for reviewing. > > I fixed the patch to include your comment. > Yasumasa uploaded new webrev. > > > Thanks, > Osamu > > > > On 5/28/19 16:39, David Holmes wrote: >> Hi Osamu, >> >> On 28/05/2019 3:57 pm, Osamu Sakamoto wrote: >>> Hi, >>> >>> David, >>> Thank you for reviewing. >>> >>> I agree with your comment. >>> I fixed the patch and Yasumasa uploaded the webrev for this fixed >>> patch. >>> >>> >>> And I attached fixed --help outputs to this mail(help2.txt). >> >> That all looks good to me - thanks. Just one minor correction in one >> of my suggestions: >> >> +??????? System.out.println("??? --core \tTo operate on a >> given core file."); >> >> s/a/the/ >> >> and one minor correction to yours: >> >> +??????? System.out.println("??? --dumpfile \tA Name of the >> dump file."); >> >> s/A Name/The name/ >> >> Thanks, >> David >> ----- >> >>> >>> Serugui, >>> >>> In this patch, I added angle brackets only to >>> parameters(--pid/--core/--exe/debugd --severid/jmap --dumpfile), not >>> descriptions of each options. >>> Does this form match your comment in this RFE? >>> >>> >>> >>> Thanks, >>> Osamu >>> >>> >>> On 5/28/19 08:50, David Holmes wrote: >>>> Hi Osamu, >>>> >>>> I have a lot of "suggestions" here. Writing good help output is not >>>> easy, and the more you try to do things the more you expose >>>> existing problems - which is the case here I'm afraid. I didn't >>>> fully realize the constraints these commands had in regards to how >>>> they operate either on a live process or else using a core file and >>>> executable together, so some of my previous guidance was a little >>>> mis-guided. Sorry about that. >>>> >>>> On 23/05/2019 7:34 pm, Osamu Sakamoto wrote: >>>>> Hi all, >>>>> >>>>> I've made the patch that was discussed here. >>>>> >>>>> >>>>> >>>>> This patch fixes the following JBS ticket. >>>>> >>>>> >>>>> I attached the patch to this email. >>>>> This patch passes serviceability/sa jtreg tests. >>>> >>>> +??????? System.out.println(""); >>>> +??????? System.out.println("??? --pid and --exe are mutually >>>> execlusive, and --core only goes with --exe."); >>>> +??????? System.out.println("??? Arguments following the --exe and >>>> --core can be absolute or relative path."); >>>> >>>> This? partially captures the intent that the flags are mutually >>>> exclusive but its more complex than this. I would suggest: >>>> >>>> --- >>>> The --core and --exe options must be set together to give the core >>>> file, and associated executable, to operate on. Otherwise the --pid >>>> option can be set to operate on a live process. >>>> The arguments for --exe and --core can use absolute or relative paths. >>>> --- >>>> >>>> +??????? System.out.println("??? Examples: jhsdb " + mode + " --pid >>>> "); >>>> +??????? System.out.println("????????? or? jhsdb " + mode + " --exe >>>> --core "); >>>> >>>> As these are examples I would substitute actual values eg: >>>> >>>> --pid 1234 >>>> --core ./core.1234 --exe ./myexe >>>> >>>> --- >>>> >>>> The suggestion to use angle brackets has been taken too far - angle >>>> brackets delimit an argument to a flag, they do not delimit a >>>> description of the option. For example in: >>>> >>>> $jhsdb jstack --help >>>> ???? --locks???? >>>> ???? --mixed???? >>>> ???? --exe?????? >>>> ???? --core????? >>>> ???? --pid?????? >>>> >>>> The: >>>> >>>> ???? --locks???? >>>> >>>> should just be: >>>> >>>> ???? --locks???? To print java.util.concurrent locks. >>>> >>>> The same for --mixed. >>>> >>>> I suggest turning the descriptions into sentences as shown with >>>> initial capitals and final period. >>>> >>>> But that highlights an inconsistent approach with regards to >>>> --exe/--pid/--core as we are not describing the meaning of those >>>> flags on the same line. For consistency we should have in this order: >>>> >>>> ???? --pid ??????? To attach to and operate on the given live >>>> process. >>>> ???? --core ? To operate on a given core file. >>>> ???? --exe >>>> >>>> This puts the focus on --core where it belongs - the --exe is just >>>> something that has to accompany --core. So that putting it all >>>> together we would have: >>>> >>>> $jhsdb jstack --help >>>> ??? --locks???? To print java.util.concurrent locks. >>>> ??? --mixed???? To print both Java and native frames (mixed mode). >>>> ??? --pid To attach to and operate on the given live process. >>>> ??? --core ? To operate on a given core file. >>>> ??? --exe >>>> >>>> ??? The --core and --exe options must be set together to give the core >>>> ??? file, and associated executable, to operate on. Otherwise the >>>> --pid >>>> ??? option can be set to operate on a live process. >>>> ??? The arguments for --exe and --core can use absolute or relative >>>> paths. >>>> ---- >>>> >>>> For: >>>> >>>> ???? --serverid? >>>> >>>> I suggest >>>> >>>> ???? --serverid? ? A unique identifier for this debug server. >>>> >>>> >>>> Thanks, >>>> David >>>> -------- >>>> >>>> >>>>> Could you help? I would like to contribute it. I need a sponsor. >>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>> >>>>> >>>>> Thanks, >>>>> Osamu >>> >>> From david.holmes at oracle.com Wed May 29 04:24:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 May 2019 14:24:42 +1000 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: References: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> <2ff0c38c-9e58-fbe7-6d8e-3df1175f347a@nttcom.co.jp> <77f4ccc2-32d8-3fbc-2e02-684af64b0d56@oracle.com> Message-ID: <9d921e8c-9312-5da3-1586-9834de0b14b6@oracle.com> Ship it! :) Thanks, David On 29/05/2019 10:37 am, Osamu Sakamoto wrote: > Hi David, > > Thank you for reviewing. > > I fixed the patch to include your comment. > Yasumasa uploaded new webrev. > > > Thanks, > Osamu > > > > On 5/28/19 16:39, David Holmes wrote: >> Hi Osamu, >> >> On 28/05/2019 3:57 pm, Osamu Sakamoto wrote: >>> Hi, >>> >>> David, >>> Thank you for reviewing. >>> >>> I agree with your comment. >>> I fixed the patch and Yasumasa uploaded the webrev for this fixed patch. >>> >>> >>> And I attached fixed --help outputs to this mail(help2.txt). >> >> That all looks good to me - thanks. Just one minor correction in one >> of my suggestions: >> >> +??????? System.out.println("??? --core \tTo operate on a >> given core file."); >> >> s/a/the/ >> >> and one minor correction to yours: >> >> +??????? System.out.println("??? --dumpfile \tA Name of the dump >> file."); >> >> s/A Name/The name/ >> >> Thanks, >> David >> ----- >> >>> >>> Serugui, >>> >>> In this patch, I added angle brackets only to >>> parameters(--pid/--core/--exe/debugd --severid/jmap --dumpfile), not >>> descriptions of each options. >>> Does this form match your comment in this RFE? >>> >>> >>> >>> Thanks, >>> Osamu >>> >>> >>> On 5/28/19 08:50, David Holmes wrote: >>>> Hi Osamu, >>>> >>>> I have a lot of "suggestions" here. Writing good help output is not >>>> easy, and the more you try to do things the more you expose existing >>>> problems - which is the case here I'm afraid. I didn't fully realize >>>> the constraints these commands had in regards to how they operate >>>> either on a live process or else using a core file and executable >>>> together, so some of my previous guidance was a little mis-guided. >>>> Sorry about that. >>>> >>>> On 23/05/2019 7:34 pm, Osamu Sakamoto wrote: >>>>> Hi all, >>>>> >>>>> I've made the patch that was discussed here. >>>>> >>>>> >>>>> >>>>> This patch fixes the following JBS ticket. >>>>> >>>>> >>>>> I attached the patch to this email. >>>>> This patch passes serviceability/sa jtreg tests. >>>> >>>> +??????? System.out.println(""); >>>> +??????? System.out.println("??? --pid and --exe are mutually >>>> execlusive, and --core only goes with --exe."); >>>> +??????? System.out.println("??? Arguments following the --exe and >>>> --core can be absolute or relative path."); >>>> >>>> This? partially captures the intent that the flags are mutually >>>> exclusive but its more complex than this. I would suggest: >>>> >>>> --- >>>> The --core and --exe options must be set together to give the core >>>> file, and associated executable, to operate on. Otherwise the --pid >>>> option can be set to operate on a live process. >>>> The arguments for --exe and --core can use absolute or relative paths. >>>> --- >>>> >>>> +??????? System.out.println("??? Examples: jhsdb " + mode + " --pid >>>> "); >>>> +??????? System.out.println("????????? or? jhsdb " + mode + " --exe >>>> --core "); >>>> >>>> As these are examples I would substitute actual values eg: >>>> >>>> --pid 1234 >>>> --core ./core.1234 --exe ./myexe >>>> >>>> --- >>>> >>>> The suggestion to use angle brackets has been taken too far - angle >>>> brackets delimit an argument to a flag, they do not delimit a >>>> description of the option. For example in: >>>> >>>> $jhsdb jstack --help >>>> ???? --locks???? >>>> ???? --mixed???? >>>> ???? --exe?????? >>>> ???? --core????? >>>> ???? --pid?????? >>>> >>>> The: >>>> >>>> ???? --locks???? >>>> >>>> should just be: >>>> >>>> ???? --locks???? To print java.util.concurrent locks. >>>> >>>> The same for --mixed. >>>> >>>> I suggest turning the descriptions into sentences as shown with >>>> initial capitals and final period. >>>> >>>> But that highlights an inconsistent approach with regards to >>>> --exe/--pid/--core as we are not describing the meaning of those >>>> flags on the same line. For consistency we should have in this order: >>>> >>>> ???? --pid ??????? To attach to and operate on the given live >>>> process. >>>> ???? --core ? To operate on a given core file. >>>> ???? --exe >>>> >>>> This puts the focus on --core where it belongs - the --exe is just >>>> something that has to accompany --core. So that putting it all >>>> together we would have: >>>> >>>> $jhsdb jstack --help >>>> ??? --locks???? To print java.util.concurrent locks. >>>> ??? --mixed???? To print both Java and native frames (mixed mode). >>>> ??? --pid To attach to and operate on the given live process. >>>> ??? --core ? To operate on a given core file. >>>> ??? --exe >>>> >>>> ??? The --core and --exe options must be set together to give the core >>>> ??? file, and associated executable, to operate on. Otherwise the --pid >>>> ??? option can be set to operate on a live process. >>>> ??? The arguments for --exe and --core can use absolute or relative >>>> paths. >>>> ---- >>>> >>>> For: >>>> >>>> ???? --serverid? >>>> >>>> I suggest >>>> >>>> ???? --serverid? ? A unique identifier for this debug server. >>>> >>>> >>>> Thanks, >>>> David >>>> -------- >>>> >>>> >>>>> Could you help? I would like to contribute it. I need a sponsor. >>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>> >>>>> >>>>> Thanks, >>>>> Osamu >>> >>> From sakamoto.osamu at nttcom.co.jp Wed May 29 04:40:37 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Wed, 29 May 2019 13:40:37 +0900 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: References: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> <2ff0c38c-9e58-fbe7-6d8e-3df1175f347a@nttcom.co.jp> <77f4ccc2-32d8-3fbc-2e02-684af64b0d56@oracle.com> Message-ID: <4316d57c-2004-c7cd-09e0-9f132c27073b@nttcom.co.jp> Hi Serguei, Thank you for reviewing. Osamu On 5/29/19 12:18, serguei.spitsyn at oracle.com wrote: > Hi Osamu, > > This update looks good to me. > > Thanks, > Serguei > > > On 5/28/19 17:37, Osamu Sakamoto wrote: >> Hi David, >> >> Thank you for reviewing. >> >> I fixed the patch to include your comment. >> Yasumasa uploaded new webrev. >> >> >> Thanks, >> Osamu >> >> >> >> On 5/28/19 16:39, David Holmes wrote: >>> Hi Osamu, >>> >>> On 28/05/2019 3:57 pm, Osamu Sakamoto wrote: >>>> Hi, >>>> >>>> David, >>>> Thank you for reviewing. >>>> >>>> I agree with your comment. >>>> I fixed the patch and Yasumasa uploaded the webrev for this fixed >>>> patch. >>>> >>>> >>>> And I attached fixed --help outputs to this mail(help2.txt). >>> >>> That all looks good to me - thanks. Just one minor correction in one >>> of my suggestions: >>> >>> +??????? System.out.println("??? --core \tTo operate on a >>> given core file."); >>> >>> s/a/the/ >>> >>> and one minor correction to yours: >>> >>> +??????? System.out.println("??? --dumpfile \tA Name of the >>> dump file."); >>> >>> s/A Name/The name/ >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Serugui, >>>> >>>> In this patch, I added angle brackets only to >>>> parameters(--pid/--core/--exe/debugd --severid/jmap --dumpfile), not >>>> descriptions of each options. >>>> Does this form match your comment in this RFE? >>>> >>>> >>>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/28/19 08:50, David Holmes wrote: >>>>> Hi Osamu, >>>>> >>>>> I have a lot of "suggestions" here. Writing good help output is not >>>>> easy, and the more you try to do things the more you expose >>>>> existing problems - which is the case here I'm afraid. I didn't >>>>> fully realize the constraints these commands had in regards to how >>>>> they operate either on a live process or else using a core file and >>>>> executable together, so some of my previous guidance was a little >>>>> mis-guided. Sorry about that. >>>>> >>>>> On 23/05/2019 7:34 pm, Osamu Sakamoto wrote: >>>>>> Hi all, >>>>>> >>>>>> I've made the patch that was discussed here. >>>>>> >>>>>> >>>>>> >>>>>> This patch fixes the following JBS ticket. >>>>>> >>>>>> >>>>>> I attached the patch to this email. >>>>>> This patch passes serviceability/sa jtreg tests. >>>>> >>>>> +??????? System.out.println(""); >>>>> +??????? System.out.println("??? --pid and --exe are mutually >>>>> execlusive, and --core only goes with --exe."); >>>>> +??????? System.out.println("??? Arguments following the --exe and >>>>> --core can be absolute or relative path."); >>>>> >>>>> This? partially captures the intent that the flags are mutually >>>>> exclusive but its more complex than this. I would suggest: >>>>> >>>>> --- >>>>> The --core and --exe options must be set together to give the core >>>>> file, and associated executable, to operate on. Otherwise the --pid >>>>> option can be set to operate on a live process. >>>>> The arguments for --exe and --core can use absolute or relative paths. >>>>> --- >>>>> >>>>> +??????? System.out.println("??? Examples: jhsdb " + mode + " --pid >>>>> "); >>>>> +??????? System.out.println("????????? or? jhsdb " + mode + " --exe >>>>> --core "); >>>>> >>>>> As these are examples I would substitute actual values eg: >>>>> >>>>> --pid 1234 >>>>> --core ./core.1234 --exe ./myexe >>>>> >>>>> --- >>>>> >>>>> The suggestion to use angle brackets has been taken too far - angle >>>>> brackets delimit an argument to a flag, they do not delimit a >>>>> description of the option. For example in: >>>>> >>>>> $jhsdb jstack --help >>>>> ???? --locks???? >>>>> ???? --mixed???? >>>>> ???? --exe?????? >>>>> ???? --core????? >>>>> ???? --pid?????? >>>>> >>>>> The: >>>>> >>>>> ???? --locks???? >>>>> >>>>> should just be: >>>>> >>>>> ???? --locks???? To print java.util.concurrent locks. >>>>> >>>>> The same for --mixed. >>>>> >>>>> I suggest turning the descriptions into sentences as shown with >>>>> initial capitals and final period. >>>>> >>>>> But that highlights an inconsistent approach with regards to >>>>> --exe/--pid/--core as we are not describing the meaning of those >>>>> flags on the same line. For consistency we should have in this order: >>>>> >>>>> ???? --pid ??????? To attach to and operate on the given live >>>>> process. >>>>> ???? --core ? To operate on a given core file. >>>>> ???? --exe >>>>> >>>>> This puts the focus on --core where it belongs - the --exe is just >>>>> something that has to accompany --core. So that putting it all >>>>> together we would have: >>>>> >>>>> $jhsdb jstack --help >>>>> ??? --locks???? To print java.util.concurrent locks. >>>>> ??? --mixed???? To print both Java and native frames (mixed mode). >>>>> ??? --pid To attach to and operate on the given live process. >>>>> ??? --core ? To operate on a given core file. >>>>> ??? --exe >>>>> >>>>> ??? The --core and --exe options must be set together to give the core >>>>> ??? file, and associated executable, to operate on. Otherwise the >>>>> --pid >>>>> ??? option can be set to operate on a live process. >>>>> ??? The arguments for --exe and --core can use absolute or relative >>>>> paths. >>>>> ---- >>>>> >>>>> For: >>>>> >>>>> ???? --serverid? >>>>> >>>>> I suggest >>>>> >>>>> ???? --serverid? ? A unique identifier for this debug server. >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> -------- >>>>> >>>>> >>>>>> Could you help? I would like to contribute it. I need a sponsor. >>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Osamu >>>> >>>> > From sakamoto.osamu at nttcom.co.jp Wed May 29 04:43:35 2019 From: sakamoto.osamu at nttcom.co.jp (Osamu Sakamoto) Date: Wed, 29 May 2019 13:43:35 +0900 Subject: 8223814: SA: jhsdb common help needs to be more detailed In-Reply-To: <9d921e8c-9312-5da3-1586-9834de0b14b6@oracle.com> References: <0a389ad9-c0e4-1007-0c44-eeeed1a610a5@oracle.com> <2ff0c38c-9e58-fbe7-6d8e-3df1175f347a@nttcom.co.jp> <77f4ccc2-32d8-3fbc-2e02-684af64b0d56@oracle.com> <9d921e8c-9312-5da3-1586-9834de0b14b6@oracle.com> Message-ID: Hi David, Thank you for reviewing. I will request Yasumasa to push the webrev to jdk/jdk . Thanks, Osamu On 5/29/19 13:24, David Holmes wrote: > Ship it! :) > > Thanks, > David > > On 29/05/2019 10:37 am, Osamu Sakamoto wrote: >> Hi David, >> >> Thank you for reviewing. >> >> I fixed the patch to include your comment. >> Yasumasa uploaded new webrev. >> >> >> Thanks, >> Osamu >> >> >> >> On 5/28/19 16:39, David Holmes wrote: >>> Hi Osamu, >>> >>> On 28/05/2019 3:57 pm, Osamu Sakamoto wrote: >>>> Hi, >>>> >>>> David, >>>> Thank you for reviewing. >>>> >>>> I agree with your comment. >>>> I fixed the patch and Yasumasa uploaded the webrev for this fixed >>>> patch. >>>> >>>> >>>> And I attached fixed --help outputs to this mail(help2.txt). >>> >>> That all looks good to me - thanks. Just one minor correction in one >>> of my suggestions: >>> >>> +??????? System.out.println("??? --core \tTo operate on a >>> given core file."); >>> >>> s/a/the/ >>> >>> and one minor correction to yours: >>> >>> +??????? System.out.println("??? --dumpfile \tA Name of the >>> dump file."); >>> >>> s/A Name/The name/ >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Serugui, >>>> >>>> In this patch, I added angle brackets only to >>>> parameters(--pid/--core/--exe/debugd --severid/jmap --dumpfile), not >>>> descriptions of each options. >>>> Does this form match your comment in this RFE? >>>> >>>> >>>> >>>> Thanks, >>>> Osamu >>>> >>>> >>>> On 5/28/19 08:50, David Holmes wrote: >>>>> Hi Osamu, >>>>> >>>>> I have a lot of "suggestions" here. Writing good help output is not >>>>> easy, and the more you try to do things the more you expose >>>>> existing problems - which is the case here I'm afraid. I didn't >>>>> fully realize the constraints these commands had in regards to how >>>>> they operate either on a live process or else using a core file and >>>>> executable together, so some of my previous guidance was a little >>>>> mis-guided. Sorry about that. >>>>> >>>>> On 23/05/2019 7:34 pm, Osamu Sakamoto wrote: >>>>>> Hi all, >>>>>> >>>>>> I've made the patch that was discussed here. >>>>>> >>>>>> >>>>>> >>>>>> This patch fixes the following JBS ticket. >>>>>> >>>>>> >>>>>> I attached the patch to this email. >>>>>> This patch passes serviceability/sa jtreg tests. >>>>> >>>>> +??????? System.out.println(""); >>>>> +??????? System.out.println("??? --pid and --exe are mutually >>>>> execlusive, and --core only goes with --exe."); >>>>> +??????? System.out.println("??? Arguments following the --exe and >>>>> --core can be absolute or relative path."); >>>>> >>>>> This? partially captures the intent that the flags are mutually >>>>> exclusive but its more complex than this. I would suggest: >>>>> >>>>> --- >>>>> The --core and --exe options must be set together to give the core >>>>> file, and associated executable, to operate on. Otherwise the --pid >>>>> option can be set to operate on a live process. >>>>> The arguments for --exe and --core can use absolute or relative paths. >>>>> --- >>>>> >>>>> +??????? System.out.println("??? Examples: jhsdb " + mode + " --pid >>>>> "); >>>>> +??????? System.out.println("????????? or? jhsdb " + mode + " --exe >>>>> --core "); >>>>> >>>>> As these are examples I would substitute actual values eg: >>>>> >>>>> --pid 1234 >>>>> --core ./core.1234 --exe ./myexe >>>>> >>>>> --- >>>>> >>>>> The suggestion to use angle brackets has been taken too far - angle >>>>> brackets delimit an argument to a flag, they do not delimit a >>>>> description of the option. For example in: >>>>> >>>>> $jhsdb jstack --help >>>>> ???? --locks???? >>>>> ???? --mixed???? >>>>> ???? --exe?????? >>>>> ???? --core????? >>>>> ???? --pid?????? >>>>> >>>>> The: >>>>> >>>>> ???? --locks???? >>>>> >>>>> should just be: >>>>> >>>>> ???? --locks???? To print java.util.concurrent locks. >>>>> >>>>> The same for --mixed. >>>>> >>>>> I suggest turning the descriptions into sentences as shown with >>>>> initial capitals and final period. >>>>> >>>>> But that highlights an inconsistent approach with regards to >>>>> --exe/--pid/--core as we are not describing the meaning of those >>>>> flags on the same line. For consistency we should have in this order: >>>>> >>>>> ???? --pid ??????? To attach to and operate on the given live >>>>> process. >>>>> ???? --core ? To operate on a given core file. >>>>> ???? --exe >>>>> >>>>> This puts the focus on --core where it belongs - the --exe is just >>>>> something that has to accompany --core. So that putting it all >>>>> together we would have: >>>>> >>>>> $jhsdb jstack --help >>>>> ??? --locks???? To print java.util.concurrent locks. >>>>> ??? --mixed???? To print both Java and native frames (mixed mode). >>>>> ??? --pid To attach to and operate on the given live process. >>>>> ??? --core ? To operate on a given core file. >>>>> ??? --exe >>>>> >>>>> ??? The --core and --exe options must be set together to give the core >>>>> ??? file, and associated executable, to operate on. Otherwise the >>>>> --pid >>>>> ??? option can be set to operate on a live process. >>>>> ??? The arguments for --exe and --core can use absolute or relative >>>>> paths. >>>>> ---- >>>>> >>>>> For: >>>>> >>>>> ???? --serverid? >>>>> >>>>> I suggest >>>>> >>>>> ???? --serverid? ? A unique identifier for this debug server. >>>>> >>>>> >>>>> Thanks, >>>>> David >>>>> -------- >>>>> >>>>> >>>>>> Could you help? I would like to contribute it. I need a sponsor. >>>>>> (My company has signed to OCA (NTT Comware Corporation)) >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Osamu >>>> >>>> From yasuenag at gmail.com Wed May 29 13:37:01 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 29 May 2019 22:37:01 +0900 Subject: RFR: 8209790: SA tools not providing option to connect to debug server Message-ID: <6e849395-7d8c-2a8f-a3a0-f57c442ba7a7@gmail.com> Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8209790 CSR: https://bugs.openjdk.java.net/browse/JDK-8224979 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.00/ In JDK 8 or earlier, some tools (jstack, jmap, jinfo) can connect to debug server (jsadebugd). However it has not done so since JDK 9 because jhsdb cannot accept the attach request to debug server. So I want to introduce new option `--remote` to connect to debug server. I created CSR for this issue. So please review it together. Thanks, Yasumasa From serguei.spitsyn at oracle.com Wed May 29 22:24:14 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 May 2019 15:24:14 -0700 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed Message-ID: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> Please, review fix for: ? https://bugs.openjdk.java.net/browse/JDK-8223718 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ Summary: ? The JVMTI GetLocal() does not return the error code ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. ? The fix is to always execute the check_slot_type_no_lvt(). ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. Testing: ? Successful execution of the nsk.jvmti tests (release/fastdebug). ? Mach5 run is in progress. Thanks, Serguei From gary.adams at oracle.com Thu May 30 02:04:30 2019 From: gary.adams at oracle.com (gary.adams at oracle.com) Date: Wed, 29 May 2019 22:04:30 -0400 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> Message-ID: Be sure to check copyright dates and line lengths. On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: > Please, review fix for: > ? https://bugs.openjdk.java.net/browse/JDK-8223718 > > Webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ > > > > Summary: > ? The JVMTI GetLocal() does not return the error code > ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. > ? The fix is to always execute the check_slot_type_no_lvt(). > ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated > ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to > ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. > > Testing: > ? Successful execution of the nsk.jvmti tests (release/fastdebug). > ? Mach5 run is in progress. > > Thanks, > Serguei > > From serguei.spitsyn at oracle.com Thu May 30 02:32:35 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 29 May 2019 19:32:35 -0700 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> Message-ID: Thanks, Gary! I've fixed the copyright year in the test and split the updated lines. Also found some inconsistent use of cached local variables and fixed it. The webrev location is the same: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ Thanks, Serguei On 5/29/19 7:04 PM, gary.adams at oracle.com wrote: > Be sure to check copyright dates and line lengths. > > On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: >> Please, review fix for: >> ? https://bugs.openjdk.java.net/browse/JDK-8223718 >> >> Webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >> >> >> >> Summary: >> ? The JVMTI GetLocal() does not return the error code >> ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. >> ? The fix is to always execute the check_slot_type_no_lvt(). >> ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated >> ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to >> ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. >> >> Testing: >> ? Successful execution of the nsk.jvmti tests (release/fastdebug). >> ? Mach5 run is in progress. >> >> Thanks, >> Serguei >> >> > From alexey.menkov at oracle.com Thu May 30 16:39:17 2019 From: alexey.menkov at oracle.com (Alex Menkov) Date: Thu, 30 May 2019 09:39:17 -0700 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> Message-ID: Looks good. --alex On 05/29/2019 19:32, serguei.spitsyn at oracle.com wrote: > Thanks, Gary! > I've fixed the copyright year in the test and split the updated lines. > Also found some inconsistent use of cached local variables and fixed it. > > The webrev location is the same: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ > > Thanks, > Serguei > > > On 5/29/19 7:04 PM, gary.adams at oracle.com wrote: >> Be sure to check copyright dates and line lengths. >> >> On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review fix for: >>> ? https://bugs.openjdk.java.net/browse/JDK-8223718 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>> >>> >>> >>> Summary: >>> ? The JVMTI GetLocal() does not return the error code >>> ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. >>> ? The fix is to always execute the check_slot_type_no_lvt(). >>> ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated >>> ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to >>> ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. >>> >>> Testing: >>> ? Successful execution of the nsk.jvmti tests (release/fastdebug). >>> ? Mach5 run is in progress. >>> >>> Thanks, >>> Serguei >>> >>> >> > From gary.adams at oracle.com Thu May 30 16:52:33 2019 From: gary.adams at oracle.com (Gary Adams) Date: Thu, 30 May 2019 12:52:33 -0400 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> Message-ID: <5CF00A51.7040300@oracle.com> +1 On 5/30/19, 12:39 PM, Alex Menkov wrote: > Looks good. > > --alex > > On 05/29/2019 19:32, serguei.spitsyn at oracle.com wrote: >> Thanks, Gary! >> I've fixed the copyright year in the test and split the updated lines. >> Also found some inconsistent use of cached local variables and fixed it. >> >> The webrev location is the same: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >> >> >> Thanks, >> Serguei >> >> >> On 5/29/19 7:04 PM, gary.adams at oracle.com wrote: >>> Be sure to check copyright dates and line lengths. >>> >>> On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8223718 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>>> >>>> >>>> >>>> Summary: >>>> The JVMTI GetLocal() does not return the error code >>>> JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. >>>> The fix is to always execute the check_slot_type_no_lvt(). >>>> The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated >>>> to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to >>>> the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. >>>> >>>> Testing: >>>> Successful execution of the nsk.jvmti tests (release/fastdebug). >>>> Mach5 run is in progress. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>> >> From vladimir.kozlov at oracle.com Thu May 30 17:05:19 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 May 2019 10:05:19 -0700 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> Message-ID: <8a2c6a23-6986-ebb4-ffb4-014057e18716@oracle.com> Thank you, Serguei, for fixing this. Vladimir K On 5/29/19 7:32 PM, serguei.spitsyn at oracle.com wrote: > Thanks, Gary! > I've fixed the copyright year in the test and split the updated lines. > Also found some inconsistent use of cached local variables and fixed it. > > The webrev location is the same: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ > > Thanks, > Serguei > > > On 5/29/19 7:04 PM, gary.adams at oracle.com wrote: >> Be sure to check copyright dates and line lengths. >> >> On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review fix for: >>> ? https://bugs.openjdk.java.net/browse/JDK-8223718 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>> >>> >>> Summary: >>> ? The JVMTI GetLocal() does not return the error code >>> ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. >>> ? The fix is to always execute the check_slot_type_no_lvt(). >>> ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated >>> ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to >>> ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. >>> >>> Testing: >>> ? Successful execution of the nsk.jvmti tests (release/fastdebug). >>> ? Mach5 run is in progress. >>> >>> Thanks, >>> Serguei >>> >>> >> > From serguei.spitsyn at oracle.com Thu May 30 17:57:57 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 May 2019 10:57:57 -0700 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: <5CF00A51.7040300@oracle.com> References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> <5CF00A51.7040300@oracle.com> Message-ID: <5f83b5b2-4829-a8ac-254d-6ca45ec09641@oracle.com> Thanks a lot, Gary and Alex for reviewing! Serguei On 5/30/19 09:52, Gary Adams wrote: > +1 > > On 5/30/19, 12:39 PM, Alex Menkov wrote: >> Looks good. >> >> --alex >> >> On 05/29/2019 19:32, serguei.spitsyn at oracle.com wrote: >>> Thanks, Gary! >>> I've fixed the copyright year in the test and split the updated lines. >>> Also found some inconsistent use of cached local variables and fixed >>> it. >>> >>> The webrev location is the same: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>> >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/29/19 7:04 PM, gary.adams at oracle.com wrote: >>>> Be sure to check copyright dates and line lengths. >>>> >>>> On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review fix for: >>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223718 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>>>> >>>>> >>>>> >>>>> Summary: >>>>> ? The JVMTI GetLocal() does not return the error code >>>>> ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. >>>>> ? The fix is to always execute the check_slot_type_no_lvt(). >>>>> ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated >>>>> ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to >>>>> ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. >>>>> >>>>> Testing: >>>>> ? Successful execution of the nsk.jvmti tests (release/fastdebug). >>>>> ? Mach5 run is in progress. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>> >>> > From serguei.spitsyn at oracle.com Thu May 30 17:58:57 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 May 2019 10:58:57 -0700 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: <8a2c6a23-6986-ebb4-ffb4-014057e18716@oracle.com> References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> <8a2c6a23-6986-ebb4-ffb4-014057e18716@oracle.com> Message-ID: Hi Vladimir, May I count you as a (R)eviewer? Thanks, Serguei On 5/30/19 10:05, Vladimir Kozlov wrote: > Thank you, Serguei, for fixing this. > > Vladimir K > > On 5/29/19 7:32 PM, serguei.spitsyn at oracle.com wrote: >> Thanks, Gary! >> I've fixed the copyright year in the test and split the updated lines. >> Also found some inconsistent use of cached local variables and fixed it. >> >> The webrev location is the same: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >> >> >> Thanks, >> Serguei >> >> >> On 5/29/19 7:04 PM, gary.adams at oracle.com wrote: >>> Be sure to check copyright dates and line lengths. >>> >>> On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: >>>> Please, review fix for: >>>> ? https://bugs.openjdk.java.net/browse/JDK-8223718 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>>> >>>> >>>> >>>> Summary: >>>> ? The JVMTI GetLocal() does not return the error code >>>> ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. >>>> ? The fix is to always execute the check_slot_type_no_lvt(). >>>> ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated >>>> ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to >>>> ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. >>>> >>>> Testing: >>>> ? Successful execution of the nsk.jvmti tests (release/fastdebug). >>>> ? Mach5 run is in progress. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>> >> From vladimir.kozlov at oracle.com Thu May 30 18:33:10 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 May 2019 11:33:10 -0700 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> <8a2c6a23-6986-ebb4-ffb4-014057e18716@oracle.com> Message-ID: Yes, I looked on it and tested when Tom proposed changes. Vladimir On 5/30/19 10:58 AM, serguei.spitsyn at oracle.com wrote: > Hi Vladimir, > > May I count you as a (R)eviewer? > > Thanks, > Serguei > > > On 5/30/19 10:05, Vladimir Kozlov wrote: >> Thank you, Serguei, for fixing this. >> >> Vladimir K >> >> On 5/29/19 7:32 PM, serguei.spitsyn at oracle.com wrote: >>> Thanks, Gary! >>> I've fixed the copyright year in the test and split the updated lines. >>> Also found some inconsistent use of cached local variables and fixed it. >>> >>> The webrev location is the same: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>> >>> Thanks, >>> Serguei >>> >>> >>> On 5/29/19 7:04 PM, gary.adams at oracle.com wrote: >>>> Be sure to check copyright dates and line lengths. >>>> >>>> On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: >>>>> Please, review fix for: >>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223718 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>>>> >>>>> >>>>> Summary: >>>>> ? The JVMTI GetLocal() does not return the error code >>>>> ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. >>>>> ? The fix is to always execute the check_slot_type_no_lvt(). >>>>> ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated >>>>> ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to >>>>> ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. >>>>> >>>>> Testing: >>>>> ? Successful execution of the nsk.jvmti tests (release/fastdebug). >>>>> ? Mach5 run is in progress. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>> >>> > From Alan.Bateman at oracle.com Thu May 30 18:48:40 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 30 May 2019 19:48:40 +0100 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: References: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> Message-ID: <5219ef3a-bacf-dc1a-e7a4-b7e00c22352c@oracle.com> On 27/05/2019 15:33, Langer, Christoph wrote: > : > The principal feature here is that one wants to be able to "debug on demand". Currently (or before the change that we're discussing was implemented) one had to start the JVM with the JDWP agent activated in case one's planning to debug. The "onjcmd" option gives the possibility to start the JDWP agent in a standby mode and later on activate the actual debugging. The most common way will probably be to use jcmd but there are also other ways using MXBeans to trigger the debugging. So I don't see the tie to a certain JDK-specific tool here. > > I think the overall story of "debugging on demand" is quite compelling. We've had that for years in SAP's proprietary JVM and it was well received by the users. It gives you the option to connect with the debugger post mortem to analyze issues. > "debugging on demand" is a big topic. It would certainly be compelling to allow a developer connect a debugger to a running VM when that VM was not initially started with the JDWP agent (restrictions/security apply of course). Back in the JDK 6 time frame (before OpenJDK) we looked into having the JDWP agent work with a reduced set of JVM TI capabilities (meaning capabilities that could not be obtained in the live phase). We also looked into re-generating the interpreter at runtime with the debugger hooks so that when the debugger agent is loaded it could obtain all the capabilities that is needed. It would good to write up some of the options that have been, or could be, explored. Some of them would likely require significant effort to implement of course. My concern with the feature pushed to JDK 12 is that it went into without sufficient discussion of the alternatives and implications. I'm also concerned about the usability and ad-hocness. As I see it, I need to configure my VM to start with the JDWP agent. Some time later I will use jcmd to trigger the JDWP agent to start its listener and jcmd will reveal the transport endpoint. I then ask my debugger to connect to that endpoint. I am of course familiar with the legacy onuncaught/onthrow options and how they launch the debugger but I don't think there were well thought through very well at the time. So I think this feature needs another look to see if it's the right solution for the JDK. A second look could potentially see if there is a role for the attach API, at least for the same system case, so that there is something equivalent to startManagementAgent that would attach to the VM and trigger the JDWP agent to load its transport and establish the connection. -Alan From serguei.spitsyn at oracle.com Thu May 30 21:10:01 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 30 May 2019 14:10:01 -0700 Subject: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed In-Reply-To: References: <0e0b30cc-5863-1311-2ba0-e55f9eeeebb4@oracle.com> <8a2c6a23-6986-ebb4-ffb4-014057e18716@oracle.com> Message-ID: <70553b1c-2d68-da47-f853-8a28907c22c6@oracle.com> Okay, thanks! Serguei On 5/30/19 11:33, Vladimir Kozlov wrote: > Yes, I looked on it and tested when Tom proposed changes. > > Vladimir > > On 5/30/19 10:58 AM, serguei.spitsyn at oracle.com wrote: >> Hi Vladimir, >> >> May I count you as a (R)eviewer? >> >> Thanks, >> Serguei >> >> >> On 5/30/19 10:05, Vladimir Kozlov wrote: >>> Thank you, Serguei, for fixing this. >>> >>> Vladimir K >>> >>> On 5/29/19 7:32 PM, serguei.spitsyn at oracle.com wrote: >>>> Thanks, Gary! >>>> I've fixed the copyright year in the test and split the updated lines. >>>> Also found some inconsistent use of cached local variables and >>>> fixed it. >>>> >>>> The webrev location is the same: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 5/29/19 7:04 PM, gary.adams at oracle.com wrote: >>>>> Be sure to check copyright dates and line lengths. >>>>> >>>>> On 5/29/19 6:24 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Please, review fix for: >>>>>> ? https://bugs.openjdk.java.net/browse/JDK-8223718 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ >>>>>> >>>>>> >>>>>> >>>>>> Summary: >>>>>> ? The JVMTI GetLocal() does not return the error code >>>>>> ? JVMTI_ERROR_INVALID_SLOT for the T_CONFLICT if the LVT is present. >>>>>> ? The fix is to always execute the check_slot_type_no_lvt(). >>>>>> ? The test nsk/jvmti/unit/GetLocalVariable/getlocal003 is updated >>>>>> ? to expect the error code JVMTI_ERROR_INVALID_SLOT additionally to >>>>>> ? the JVMTI_ERROR_TYPE_MISMATCH in a couple of cases. >>>>>> >>>>>> Testing: >>>>>> ? Successful execution of the nsk.jvmti tests (release/fastdebug). >>>>>> ? Mach5 run is in progress. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>> >>>> >> From jonathan.gibbons at oracle.com Thu May 30 23:53:24 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 30 May 2019 16:53:24 -0700 Subject: RFR: docs/accessibility: JDK-8220251: fix headings in java.management Message-ID: <748b5074-ed79-b0e1-6eb0-c3f3c07ef4c1@oracle.com> Please review a conceptually simple fix to adjust the rank of the headings in the following files in 4 management-related modules: src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html src/java.management/share/classes/java/lang/management/LockInfo.java src/java.management/share/classes/java/lang/management/ManagementFactory.java src/java.management/share/classes/java/lang/management/MemoryMXBean.java src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java src/java.management/share/classes/java/lang/management/MemoryUsage.java src/java.management/share/classes/java/lang/management/MonitorInfo.java src/java.management/share/classes/java/lang/management/ThreadInfo.java src/java.management/share/classes/java/lang/management/ThreadMXBean.java src/java.management/share/classes/java/lang/management/package.html src/java.management/share/classes/javax/management/MXBean.java src/java.management/share/classes/javax/management/NotificationBroadcaster.java src/java.management/share/classes/javax/management/NotificationEmitter.java src/java.management/share/classes/javax/management/remote/package.html src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBean.java src/jdk.management/share/classes/com/sun/management/GcInfo.java In most files, the headings are simply adjusted "up" to close up "gaps" in the sequence of headings. In a couple of files, the headings were inconsistent and have been updated as seems best. To help understand the changes, I've attached the output of a script that shows the lines containing headings before and after the change. -- Jon JBS: https://bugs.openjdk.java.net/browse/JDK-8220251 Webrev: http://cr.openjdk.java.net/~jjg/8220251/webrev.00/webrev/index.html Docs: http://cr.openjdk.java.net/~jjg/8220251/docs/api/index.html -------------- next part -------------- >>> open/src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html BEFORE:

Creating an RMI connector server

Choosing the RMI transport

Connector addresses generated by the server

Connector addresses based on directory entries

Connector server attributes

Creating an RMI connector client

Dynamic code downloading

AFTER:

Creating an RMI connector server

Choosing the RMI transport

Connector addresses generated by the server

Connector addresses based on directory entries

Connector server attributes

Creating an RMI connector client

Dynamic code downloading

>>> open/src/java.management/share/classes/java/lang/management/LockInfo.java BEFORE: *

MXBean Mapping

AFTER: *

MXBean Mapping

>>> open/src/java.management/share/classes/java/lang/management/ManagementFactory.java BEFORE: *

Platform MXBeans

*

1. Direct access to an MXBean interface

*

2. Indirect access to an MXBean interface via MBeanServer

AFTER: *

Platform MXBeans

*

1. Direct access to an MXBean interface

*

2. Indirect access to an MXBean interface via MBeanServer

>>> open/src/java.management/share/classes/java/lang/management/MemoryMXBean.java BEFORE: *

Memory

*

1. Heap

*

2. Non-Heap Memory

*

Memory Pools and Memory Managers

*

Memory Usage Monitoring

*

Notifications

*

NotificationEmitter

AFTER: *

Memory

*

1. Heap

*

2. Non-Heap Memory

*

Memory Pools and Memory Managers

*

Memory Usage Monitoring

*

Notifications

*

NotificationEmitter

>>> open/src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java BEFORE: *

Memory Type

*

Memory Usage Monitoring

*

1. Memory Usage

*

2. Peak Memory Usage

*

3. Usage Threshold

*

4. Collection Usage Threshold

AFTER: *

Memory Type

*

Memory Usage Monitoring

*

1. Memory Usage

*

2. Peak Memory Usage

*

3. Usage Threshold

*

4. Collection Usage Threshold

>>> open/src/java.management/share/classes/java/lang/management/MemoryUsage.java BEFORE: *

MXBean Mapping

AFTER: *

MXBean Mapping

>>> open/src/java.management/share/classes/java/lang/management/MonitorInfo.java BEFORE: *

MXBean Mapping

AFTER: *

MXBean Mapping

>>> open/src/java.management/share/classes/java/lang/management/ThreadInfo.java BEFORE: *

General thread information

*

Execution information

*

Synchronization Statistics

*

MXBean Mapping

AFTER: *

General thread information

*

Execution information

*

Synchronization Statistics

*

MXBean Mapping

>>> open/src/java.management/share/classes/java/lang/management/ThreadMXBean.java BEFORE: *

Thread ID

*

Thread CPU time

*

Thread Contention Monitoring

*

Synchronization Information and Deadlock Detection

AFTER: *

Thread ID

*

Thread CPU time

*

Thread Contention Monitoring

*

Synchronization Information and Deadlock Detection

>>> open/src/java.management/share/classes/java/lang/management/package.html BEFORE:

Platform MXBean

ManagementFactory

Interoperability

Ways to Access MXBeans

Platform Extension

AFTER:

Platform MXBean

ManagementFactory

Interoperability

Ways to Access MXBeans

Platform Extension

>>> open/src/java.management/share/classes/javax/management/MXBean.java BEFORE:

MXBean specification

Standard MBean

MXBean

Standard MBean

MXBean

Standard MBean

MXBean

Standard MBean

MXBean

Standard MBean

MXBean

Standard MBean

MXBean

Definition of an MXBean

Naming conventions

Type mapping rules

Mappings for primitive types

Mappings for collections ({@code List<}E{@code >} etc)

Mappings for maps ({@code Map<}K,V{@code >} etc)

Mappings for MXBean interfaces

Mappings for other types

Reconstructing an instance of Java type J from a {@code CompositeData}

Recursive types

MBeanInfo contents for an MXBean

Type Names

Exceptions

AFTER:

MXBean specification

Standard MBean

MXBean

Standard MBean

MXBean

Standard MBean

MXBean

Standard MBean

MXBean

Standard MBean

MXBean

Standard MBean

MXBean

Definition of an MXBean

Naming conventions

Type mapping rules

Mappings for primitive types

Mappings for collections ({@code List<}E{@code >} etc)

Mappings for maps ({@code Map<}K,V{@code >} etc)

Mappings for MXBean interfaces

Mappings for other types

Reconstructing an instance of Java type J from a {@code CompositeData}

Recursive types

MBeanInfo contents for an MXBean

Type Names

Exceptions

>>> open/src/java.management/share/classes/javax/management/NotificationBroadcaster.java BEFORE: *

Notification dispatch

AFTER: *

Notification dispatch

>>> open/src/java.management/share/classes/javax/management/NotificationEmitter.java BEFORE: *

Notification dispatch

AFTER: *

Notification dispatch

>>> open/src/java.management/share/classes/javax/management/remote/package.html BEFORE:

Connector addresses

Creating a connector server

Creating a connector client

Additional client or server parameters

Connection identifiers

AFTER:

Connector addresses

Creating a connector server

Creating a connector client

Additional client or server parameters

Connection identifiers

>>> open/src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBean.java BEFORE: *

Recording options

AFTER: *

Recording options

>>> open/src/jdk.management/share/classes/com/sun/management/GcInfo.java BEFORE: *

MXBean Mapping

AFTER: *

MXBean Mapping

From lance.andersen at oracle.com Fri May 31 00:14:30 2019 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 30 May 2019 20:14:30 -0400 Subject: RFR: docs/accessibility: JDK-8220251: fix headings in java.management In-Reply-To: <748b5074-ed79-b0e1-6eb0-c3f3c07ef4c1@oracle.com> References: <748b5074-ed79-b0e1-6eb0-c3f3c07ef4c1@oracle.com> Message-ID: <3693FD02-8AEE-4B3E-B56C-035211DE4B2E@oracle.com> looks ok Jon > On May 30, 2019, at 7:53 PM, Jonathan Gibbons wrote: > > Please review a conceptually simple fix to adjust the rank of the headings in the following files in 4 management-related modules: > > src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html > src/java.management/share/classes/java/lang/management/LockInfo.java > src/java.management/share/classes/java/lang/management/ManagementFactory.java > src/java.management/share/classes/java/lang/management/MemoryMXBean.java > src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java > src/java.management/share/classes/java/lang/management/MemoryUsage.java > src/java.management/share/classes/java/lang/management/MonitorInfo.java > src/java.management/share/classes/java/lang/management/ThreadInfo.java > src/java.management/share/classes/java/lang/management/ThreadMXBean.java > src/java.management/share/classes/java/lang/management/package.html > src/java.management/share/classes/javax/management/MXBean.java > src/java.management/share/classes/javax/management/NotificationBroadcaster.java > src/java.management/share/classes/javax/management/NotificationEmitter.java > src/java.management/share/classes/javax/management/remote/package.html > src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBean.java > src/jdk.management/share/classes/com/sun/management/GcInfo.java > > In most files, the headings are simply adjusted "up" to close up "gaps" in the sequence of headings. In a couple of files, the headings were inconsistent and have been updated as seems best. To help understand the changes, I've attached the output of a script that shows the lines containing headings before and after the change. > > -- Jon > > JBS: https://bugs.openjdk.java.net/browse/JDK-8220251 > Webrev: http://cr.openjdk.java.net/~jjg/8220251/webrev.00/webrev/index.html > Docs: http://cr.openjdk.java.net/~jjg/8220251/docs/api/index.html > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: not available URL: From christoph.langer at sap.com Fri May 31 16:01:37 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 31 May 2019 16:01:37 +0000 Subject: RFR (M) 8223456: CSR Delayed starting of debugging via jcmd In-Reply-To: <5219ef3a-bacf-dc1a-e7a4-b7e00c22352c@oracle.com> References: <74b329d6-7584-1961-1a45-b0fb4db39644@oracle.com> <5219ef3a-bacf-dc1a-e7a4-b7e00c22352c@oracle.com> Message-ID: Hi Alan, > > I think the overall story of "debugging on demand" is quite compelling. > We've had that for years in SAP's proprietary JVM and it was well received by > the users. It gives you the option to connect with the debugger post mortem > to analyze issues. > > > "debugging on demand" is a big topic. It would certainly be compelling > to allow a developer connect a debugger to a running VM when that VM was > not initially started with the JDWP agent (restrictions/security apply > of course). > > Back in the JDK 6 time frame (before OpenJDK) we looked into having the > JDWP agent work with a reduced set of JVM TI capabilities (meaning > capabilities that could not be obtained in the live phase). We also > looked into re-generating the interpreter at runtime with the debugger > hooks so that when the debugger agent is loaded it could obtain all the > capabilities that is needed. > > It would good to write up some of the options that have been, or could > be, explored. Some of them would likely require significant effort to > implement of course. I agree that "debugging on demand" is a big topic. I guess it probably merits an own JEP. Since we have (had) some experience with it, in our proprietary SAP JVM derived from the Oracle licensee sources, we were discussing how we could contribute our enhancements to the OpenJDK. We were a bit shy about going the big way involving a JEP because we know that it would certainly involve more than just collecting the single bits and pieces that we have and commit them but we'd probably need to also explore areas where we didn't yet look into yet. The fear was that such a big project is beyond our capacities and hence we decided to try to go the route of trying to bring in small, useful enhancements, such as the onjcmd option for the JDWP agent. But we should probably rethink our strategy here - maybe a JEP will be the right way to go. > My concern with the feature pushed to JDK 12 is that it went into > without sufficient discussion of the alternatives and implications. I'm > also concerned about the usability and ad-hocness. As I see it, I need > to configure my VM to start with the JDWP agent. Some time later I will > use jcmd to trigger the JDWP agent to start its listener and jcmd will > reveal the transport endpoint. I then ask my debugger to connect to that > endpoint. I am of course familiar with the legacy onuncaught/onthrow > options and how they launch the debugger but I don't think there were > well thought through very well at the time. Ok, we must admit that we missed out the CSR process at the time when we brought the enhancement in for review. So, let's do it now. I would really like if we could get to an agreement about the onjcmd feature where we "improve" it rather than back it out. As we've given the input in the CSR, we've moved it to Finalized. Can you please review it and give us some guidance about what's required next? > So I think this feature needs another look to see if it's the right > solution for the JDK. A second look could potentially see if there is a > role for the attach API, at least for the same system case, so that > there is something equivalent to startManagementAgent that would attach > to the VM and trigger the JDWP agent to load its transport and establish > the connection. Ok, that's a thing to look at. However, since I think the JVMTI agent needs to be loaded before the VM is initialized (because of required capabilities), I don't think it's feasible to activate it on a running JVM via an attach API - or at least not without larger modifications. So, please guide us through the review of this feature. Thanks Christoph