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: